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

Ну формально - 3 канала на ~11gb/sec (DDR3, 1500 гигагерцiв), итого 33, это на чтение. Как прикинуть влияние задержек - понятия не имею.

А по факту - вот сижу и щупаю, сколько можно нагадить в память зараз.

Смысл изначально был в том, что было два слота, один PCI, второй PCIe и нужно было два порта, сотку к ISP, гигабит к рабочей станции (наплатный был занят гигабитом к остальному дому и порты в свитче кончились).

С тех пор однопортовая PT-шка просто есть. Когда она освободилась, я ее ткнул в WS, для сравнения с наплатным реалтеком. Большой разницы не обнаружил, впрочем.

Забавно. У меня net.isr.direct=0 и net.isr.direct_force=0 ровно наоборот делает, минимум 100 Мбит "срезает".
Кстати, iperf и em0:taskq у меня упорно на одно ядро сажались. Разнесение на разные ("cpuset") дало прирость на те же 100 мбит.

P.S. Не очень вижу смысла в покупке однопортовой PT для дома, 32-битного PCI на гигабит всё же хватает, пусть и впритык.

Я развлекался именно с интелом, профайлер хороший имею на винде только.

Выигрыш VS2010/Intel я хорошо помню только для конкретного распаковщика хаффмана, который как раз не параллелится. Процентов 10, кажется. Автовекторизация хотспоты не лечит, не-хотспоты неинтересны.

Что касается OpenCL - да, планирую конечно, но для других мест и не сейчас (и наверное не LibRaw, а другой продукт). Проблема тут в том, что на карту льется гигабайт 5 в секунду и столько же обратно, поэтому нужно там делать сразу здоровый кусок работы, а не хотспоты.

От разрешения генерировать SSE код (что 2, что 4.1) выигрыш какой-то совершенно копеечный, единицы процентов.
Вот от 64-бит - гораздо больше, т.к. куда регистры поюзать компилятор очень быстро находит.
И от смены компилятора с Visual Studio на 12-й интел - тоже заметный выигрыш.

И выигрыш - не на хотспотах. Они, собственно, хотспоты (в большой степени) по той причине, что компилятор там напуган и хороший код сгенерировать не может.

Я пробовал с интеловским компилятором. То, что он делает на хотспотах - мне не нравится, руками можно сильно лучше и с относительно небольшими затратами умственного труда.

Да в-принципе да, может быть и больше можно.

Всякие тесты memory-copy намеривают для DDR3-1600 (трехканальной) в районе 8-9 гигабайт в секунду, это и есть целевое значение.

>> т.е. в ~5.5Gb/sec <<
Это откуда такие данные ?!?
и что это за память такая ?

(или это в битах и для кэша? :-))

Я может щас всем известное напишу или глупость какую.
К jpeg 6b существовал патч, гуглится по "pvrg jpeg ijg". Кусок из его реадме "This software implements JPEG baseline, extended-sequential, progressive
! and lossless compression processes.". Может поможет?
Плюс есть libjpeg-turbo на основе jpeg 6b c simd инструкциями, порченная и под 64 бита тоже. В свое время много юзал его японского прародителя. Давал существенный прирост в скорости против оригинального libjpeg, просто заменой shared библиотек. Но вот хаффмана там по моему не трогали.

В автовекторизацию просто скалярного кода на C - я верю слабо.
И Интел, судя по всему, тоже не особо верит, впихивая повсюду свои библиотеки.

Ну да. Lossles jpeg, да еще и с нетрадиционным layout, только что обсуждали.

И одним куском, DNG с такой же паковкой - побит на tiles (необязательно, но по факту - очень часто) и можно параллелить по процессорам хотя бы.

Кэнон чем-то ресурсоёмким запакован ?

Ого.
Вопрос в том, насколько это ускорит всё преобразование, там же и другие вычисления.

>> тот код что сейчас есть офигачивает ~300Mb/sec,

Те. 300 метров raw данных в секунду ? А на каком преобразовании ?

пардон 8-)
А это сильно ускорит ?
Ну, если можно получить ту же скорость на 2-х ядрах, а не на 4-х, то было бы классно.