Свежие комментарии

Всем привет - это ящик для тазиков реализованых под сервер а не под домашнюю игровую станцию.... Посему там нету пользовательских примочек зато серверный упор выдержан....

У меня не 1600, а 1500 реально. Во всяком случае, оно так пишет про себя при загрузке.

Но, возможно, какие-то другие клоки при этом похуже.

load_pd - это же чтение такое?

Ну да, с префетчем и если регистров хватает, наверное как-то так. 17gb/sec.

Чистое копирование меня интересует постольку-поскольку, хотя вот вместе с конверсией типа, скажем float в short - интересно будет попробовать.

Да, касаемо таблицы, скажем для замены табличным профилям. Там на входе - триада (RGB), в некоторых случаях хочется тетраду (RGBG2). Даже если 10 бит на элемент (что гадски мало даже для линейного лукапа), получается таблица с 2^30-2^40 входов. Как-то многовато.....

Другой вопрос, что точек для оценки/построения табличного профиля берется, в лучшем случае, несколько тысяч - значит это и будут реальные узлы таблицы. А дальше - интерполяция.

а просто таблица с прямым lookup - не?

насколько я слышал (точно не знаю) контроллеры управления двигателями в автомобилях ничего не вычисляют вообще - работают по таблицам значений f(x, y, z) если и не большего к-ва переменных

Хм... Тогда они, вероятно, не слетают, а возвращаются к некоторым дефолтным настройкам. Значит наверное должен быть какой-то метод задания дефолтных настроек, это было бы логично..

Не, ну я то изучал влияние размера интерполяционных таблиц на точность, как только оно стало попадать не в те строки из-за округления, так сразу стало понятно....

похоже это косяк VS. если переменная read only то никаких локов быть не должно. каждое ядро сделает копию в свой L2(L1) и будет её спокойно читать. возможен конфликт за доступ к общей линии L3, но это случится 1 раз, после этого каждый сделает копию себе (в случае private аналогично).
вот если read after write, тогда да, попа.
я стараюсь вообще не пользоваться private, вместо этого просто определяю локальные переменные внутри параллельного блока.

Наиболее чУдным открытием оказался ресет rounding mode внутри OpenMP-потока.

Вот это да - реальная жесть.

Все оказалось куда тупее: http://blog.lexa.ru/2010/12/29/openmp_intel_vs_visual_studio.html

Вы говорите о прямой имплементации, которая на C?
Ну да, в хорошем случае она догонит Intel, если цикл суммет векторизовать, чтобы значит powf считался для 4-х элементов массива сразу.

Впрочем, попробовал. Oi и SSE2 у меня были включены, добавление _set_SSE2_enable(1) ничего не меняет: 7 мегапикселей в секунду для одного потока и 36 для OpenMP.
Это примерно втрое медленнее интеловского варианта т.к. автовекторизации не случилось (втрое а не вчетверо т.к. есть ветвления и векторизатор далек от оптимальности).

С Visual C++ забавнее другое: в один поток SSE-вариант сплайнов быстрее, чем C-шный вариант сплайнов раза в полтора-два (не в четыре, потому что скалярный вариант просто считает, а мой векторный на ~8 операций счета делает еще 8 операций для транспонирования).

А вот с OpenMP - С-шный вариант ускоряется почти вчетверо (и впрямь, чего ему), а SSE - замедляется.

Я на досуге, конечно, попробую оторвать интеллект компилятору, возможно он увидев ассемблерные макросы внутри OpenMP-блока - дуреет и надо их от него попрятать в отдельную функцию в отдельной библиотеке.

Или треды свои самому запускать, по числу ядер....

Разбираться надо, конечно, Visual - гораздо более распространенный компилятор, чем Intel, а у меня опенсорс...

А что там с инвалидацией? Если она идет не по адресу, а по ассоциативному адресу, то даже с не-shared кэшем ядра будут портить малину брату.

Да, местами она странная.

Но конкретно к movaps/movntps претензий нет: т.е. интел додумал в этом месте правильную инструкцию написать, но вообще надо там писать _mm_stream_ps (о чем я теперь знаю из гугла) и сейчас я это дело изучу...

У меня есть ощущение, что все (разумные) смешивающие преобразования в RGB будут несмешивающими в Lab. Нет, ясно, что есть такая штука как Channel mixer делающая любой канал линейной комбинацией других (возможно даже в другом цветовом пространстве!) но часто ли это используют люди (кроме хардкорных последователей старого Маргулиса)? Особенно в фото а не в полиграфии?
Я, в общем, думаю свои мысли применительно к уровню выше RAW -- пост-обработка, заменф фотошопу (толстый)/лайтруму (мне там не хватает некоторых фотошоповых штук). Хотя, конечно, интеграция с RAW должна быть плотнейшая.