Opera of the Phantom или сказание о канделябре

452_1.jpg Вся эта история с PhantomOS интересна тем, что будучи еще vapourware оно всколыхнуло в людях пласты и позволило заглянуть в многочисленные бездны. Ссылок на дискуссии не даю, кому интересно - уже все видели.

Вместе с тем, dz продолжает утверждать, что всякий JIT на виртуальной машине рулит примерно не хуже, чем макроассемблер, известный нам под именем C/C++.

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

Да, действительно, судя по этим бенчмаркам Java временами рулит. Но что мы можем сказать про эти бенчмарки:

  1. Они старые, 2003-й год, updated в 2004. Конечно, JIT за это время мог развиться на неимоверные высоты, однако и процессоростроители на месте не стояли, в i7, как я слышал, уже 3 SSE-юнита на ядро, а нормальное программирование SSE - это никакая не автовекторизация компилятором, а натурально фигурное выпиливание прямо на его ассемблере.
  2. Что это за бенчмарки - мне с первого взгляда ясно не стало. Если это обращение матрицы 100x100, которая влезает в кэш L1 - это одно. Если это относительно большие данные, то плохие (не cache-aware) алгоритмы будут одинаково плохи, ибо cache miss будет стоить гораздо дороже, чем эффективность или неэффективность JIT. И, соответственно, выигрыши-провалы на тех графиках - это косвенное указание на то, попали или не попали в кэш.

Вместе с тем, быстрое пользование гуглом навело на реальную имплементацию FFT и реальные бенчмарки в сравнении не с каким-то левым sample/микробенчмаркой, а с кодом, который действительно доводится годами и считается оптимальным или близким к этому.

JTransforms s the first, open source, multithreaded FFT library written in pure Java.

На странице проекта есть бенчмарки для всех типов данных (1D, 2D, 3D, размерность кратная и некратная степени двойки). Сравнивается Java-реализация с FFTW 3.1.2 (не самая новая), до кучи туда же доложили CUDA (CuFFT и Java-интерфейс туда же), но результаты CUDA я рекомендую игнорировать, ибо родная имплементация в CUDA 1.x не очень хорошая и смотреть надо на Волковский 'my speedy fft' (не знаю, вошла ли она в CUDA 2.1).

Что мы видим:

  • Из 48 тестов нашлось 9, где Java-реализация обгоняет С-шную (хотя бы чуть-чуть). Из них вариант 3D разложения данных 5x5x5 скорее курьезный, на таких размерах что-то мерять неинтересно, а остальные 8 - действительно интересны.
  • Остальные 39 - fftw несколько быстрее на маленьких данных, а на больших - быстрее в 2-3 раза.
  • Случаи, когда Java быстрее - это когда во входных данных порядка миллиона значений, что наводит нас на мысль о кэше второго уровня.

Автор JTransforms пишет, что пускал бенчмарку на Xeon с 12 мегабайтами кэша L2 и использовал одинарную точность и бенчмарку встроенную в JTransforms. Я оные исходники глянул, точность действительно одинарная. Однако вот в FFTW стандартный комплексный тип - это вовсе double[2], а приводимая автором бенчмарка использует именно стандартный тип fftw_complex. Таким образом, миллион элементов входных данных у JTransform - это 8 мегабайт (влезает в L2), а у fftw - 16 мегабайт (не влезает). Оттого и провалы.

Итого я имею смелость утверждать, что поймал автора JTransforms за руку:

  • Естественно, если его тестовый сет влезает в L2 cache, а у оппонента реальный объем данных вдвое больше, отчего он жрет cache misses, то тут и реализация на бейсике может выиграть, если повезет.
  • Беру на себя смелость утверждать, что на реальных одинаковых данных FFTW будет быстрее не в 2-3, а в 4-6 раз просто исходя из того, как работает SSE. Не исключаю, что выигрыш будет и еще большим т.к. мы уравняем объемы пересылаемых данных. Надо просто взять JTransforms в double-варианте.

Мораль

  1. Известия о выигрыше Java перед макроассемблером в случае аккуратно написанных cache-aware приложениях никак нельзя считать подтвержденными.
  2. Рассматривая бенчмарки - потрудитесь понять, что они реально меряют и насколько меряется одно и то же.
  3. Piotr Wendykier, автор JTransforms и обсуждаемых бенчмарок, заслуживает всякой похвалы за JTransforms и канделябра за бенчмарки.

Если добрые люди вызовут сюда дух Завалишина, я буду только рад. У меня хотя бы капчи нет.

Comments

<i>нормальное программирование SSE - это никакая не автовекторизация компилятором, а натурально фигурное выпиливание прямо на его ассемблере.</i>

Причем очень травматичное выпиливание. Просто написание программы на SSE ассемблере дает результаты близкие или худшие чем у компилятора. А написание "как правильно" со всеми префетчами и параллельной обработкой приводит к тяжелой закрытой черепно-мозговой травме. И читать это потом невозможно вовсе.

<i>Если добрые люди вызовут сюда дух Завалишина, я буду только рад.</i>

И будет обычное фанатство, как всегда. Давайте позовем болельщиков Спартака и обсудим с ними а не чемпион ли ЦСКА.

И вообще, как известно, "Перл медленный, потому что интерпретируемый".

Вместе с тем, это выпиливание очень компактное, ну пусть травма, ну пирацетамчика пополам с прозаком попьешь, отпустит. Но зато кисть дает, это же натурально может быть, например, переход от 5 fps к 25 (скажем, для распаковки видео), что сразу делает левел ап.

Ну как сказать, компактное. Я писал строк 600 на ассемблере в сумме недели две чистого рабочего времени. И написал за это время по сути несколько специализаций одной функции, которая на С реализуется в полтора десятка строк максимум.
И вдобавок это невозможно документировать. SSE ассемблер это такой Kansas City shuffle для программистов. Смотрим налево, а байты бегут направо.

Но ты получил при этом ключевое преимущество перед бангалорцами?

Вот именно.

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

Re: натурально фигурное выпиливание прямо на его ассемб
Нет, разница существенно более принципиальная. На "физической" машине я могу или сам написать или библиотеку позвать. Из той же Java вполне можно звать fftw, если написать небольшой враппер.

Но мы на самом деле про фантом, который дает юзерленду байткод и виртуальную машину. В которой способа сделать что-то SIMD явно нету, вся надежда только на компилятор. Ну-ну.

Понятно, что оный фантом может дать некий SSE/SIMD extension. Но пока это остается задачей ОС - разработчики упарятся делать расширения на всякий чих. А как только в юзерленде появится доступ к настоящему железу - прощай простая стратегия защиты.

Re: натурально фигурное выпиливание прямо на его ассемб
Ах, так это про сферического фантома в вакууме...

Ну так есть куча разновидностей устройств, которым возможность добраться до железа из юзерленда серпом по фаберже, а якобы получаемые пользователем за счёт доступа к железу суперпроизводительность (по большей части мифическая) и мегафан (куда менее мифический, но для крайне узкой группы) совершенно по барабану.

Опять же, после трёх десятков лет торжества закона Мура нужда в выжимании "последней капли" проявляется всё реже и реже. Те же писишные игры взять: уже давно никто не пишет напрямую в видеопамять и вроде ничего.

Людей "старой закалки" от такого разврата, понятно, бросает в дрожь. Но тут уж никуда не денешься, типа прогресс.

Re: натурально фигурное выпиливание прямо на его ассемб
Да, это про фантома, прямо в заголовке написано.

Меж тем, писишные игры - тот самый случай, когда и такты считают (преимущественно в шейдерах, конечно) и от темплейтов отказываются. Чтение форумов-блогов геймдевов - истинное наслаждение, рекомендую.

Еще подобные места - всякая мультимудия, кодирование видео (и звука на всяких мелких устройствах). Ну и обработка больших объемов данных вообще, но это действительно ощущает очень узкая группа на себе (а пользователи - миллионами голов)

А так, естественно, подавляющее большинство этой супер-оптимизации запрятано в библиотеки-кодеки. Но эти библиотеки-кодеки не запрятаны в ядре ОС, что и является кардинальным отличием.

Re: натурально фигурное выпиливание прямо на его ассемб
Кстати, про геймдевелоперов: я еще лет 6 тому назад, когда начал заниматься вычислениями на своем радеоне, стал читать геймдевелоперов. И меня просто поразило, насколько среди них высок процент вменяемых людей. Это при том что область деятельности - прямо скажем, не матметоды в химии по части привлекательности, а у каждого второго прыщавого восьмиклассника есть мечта что вот он подучит немножко бейсик и напишет игру круче чем варкрафт.

Re: натурально фигурное выпиливание прямо на его ассемб
А в геймдеве, похоже, построен конвейер, по выбору именно вменяемых. Т.е. чтобы получить бабло - нужно, натурально, что-то разумное исполнить руками, иначе ничего не дадут.

Re: натурально фигурное выпиливание прямо на его ассемб
Слушай, ну а что, в вебдевелопменте бабки дают за так?

Спасибо за ссылку на роем про фантом. Я получил близкое, а местами и превосходящее.

Re: натурально фигурное выпиливание прямо на его ассемб
>Слушай, ну а что, в вебдевелопменте бабки дают за так?

Зачастую - да. Те же госденьги или, не к ночи будь помянут, торч-торч.

А ты хоть раз слышал, чтобы в играх пилили мегабабло?

Re: натурально фигурное выпиливание прямо на его ассемб
Конечно. Есть специальный распилочный сегмент рынка, называется "игра по фильму". Унылое говно, которое делает какая-то невменяемая студия из ниоткуда.
Про госденьги я знаю только American Army, но там и игра получилась выдающаяся :-)

Наверное, на самом деле фактор трудоемкости играет роль. Сайт на самом деле можно наговнякать за пару тыщ, а в игромире за эти деньги разве что тетрис, и то простой.

Re: натурально фигурное выпиливание прямо на его ассемб
Я, кажется, нашел еще отличие.

Говенную игру легко распознает неспециалист. Вот не цепляет и все.

А развлекательный говносайт, вроде того же торч-торча, внешне от настоящего может ничем не отличаться.

Re: натурально фигурное выпиливание прямо на его ассемб
А чем торторч не настоящий? Я имею в виду с точки зрения технической. Вряд ли конечно это стоит 15М, но по-любому дорого и работы много.

Re: натурально фигурное выпиливание прямо на его ассемб
Я бы сказал, скорее технико-политическое (в смысле технической политики) - флэш-онли, требование новой версии плейера. Ну и утечка аккаунтов (емейлов, плюс выяснилось что celebrity заведены с одинаковыми паролями, а логин подсмотреть несложно) - прям на старте проекта.

> Если добрые люди вызовут сюда дух Завалишина
Alex, а что, неужели так трудно самому вбить эту капчу с позывом , или, в конце-концов, http://www.livejournal.com/inbox/compose.bml?user=dz

?

Re: > Если добрые люди вызовут сюда дух Завалишина
Нетрудно. Но не хочу.

Re: > Если добрые люди вызовут сюда дух Завалишина
я думаю что капча на зареганых юзеров - это мания величия и моветон.

Учитывая обилие в последнее время желудочных баллонов, понять причины можно. Но, конечно, это практически исключает сколь-нибудь продолжительные дискуссии с нефрендами.

Re: > Если добрые люди вызовут сюда дух Завалишина
На зареганых юзеров - безусловно. А вот на зареганых ботов - самое оно.

<i>Вся эта история с PhantomOS интересна тем, что будучи еще vapourware</i>

Я посмотрел http://www.dz.ru/ru/solutions/phantom/ - это что, hoax какой-то первоапрельский?

<i>всякий JIT на виртуальной машине рулит примерно не хуже, чем макроассемблер, известный нам под именем C/C++</i>

Мой опыт (у меня нет бенчмарков, которые я тут могу привести) говорит, что JIT может, наверное, сделать код, быстрее чем компилятор с C++ и даже можно найти задачи на которых Java получается быстрее, но в общем когда отдельные куски соберут вместе, система получается жирнее, memory footprint гораздо больше, отчего в cache влезает меньше и в результате все равно получается плохо

Ну там трудно разделить где эта разница от того, что в Java все "слегка хуже", а где от разницы в стилях, ну, грубо говоря в C++ сделают long a[4] в стеке, а в Java - ArrayList<Long>

>Я посмотрел http://www.dz.ru/ru/solutions/phantom/ - это что, hoax какой-то первоапрельский?
Проще всего процитировать в ответ самого Завалишина:
<i>Сегодня, кстати, исследовательская группа из Стендфорда написала, что они занимаются персистенсом, и что хотят фантом. До соплей обидно, что нечего пока послать.</i>

>общем когда отдельные куски соберут вместе, система получается жирнее, memory footprint гораздо больше, отчего в cache влезает меньше и в результате все равно получается плохо

Ага. И общее впечатление от Java-программ всегда какое-то странное. У меня их не так и много в округе, но тошноту в-среднем вызывают.

Но несмотря на это, во-первых пишут и действительно много (может оттого и плохо), во-вторых современный C++ дает не меньше средств написать плохо (справедливости ради, без этих средств вообще бы не написали ничего), в-третьих есть вот бенчмарки, очень похожие на настоящие и чтобы понять за что фигачить канделябром - надо минут 20 потратить.

Как известно, программу на Фортране можно написать на любом языке программирования. Главное побольше бангалорцев к этому языку подпустить. Ну и бангалорцы тоже бывают любой национальности.

<i>современный C++ дает не меньше средств написать плохо</i>

Современный C++ также дает средства написать хорошо, средне, приемлимо и даже выбрать как конкретно ты хочешь писать

Ну пример из реальной жизни - нам надо было писать некоторые куски так, чтобы там было минимальное число malloc (точнее, минимальное число syscalls). В принципе, средний программист C++ легко понимает эту концепцию, перечитывает главу "new" в книжке, пишет там свой аллокатор, контролируемые контейнеры и т.п.

Но вот как добиться контролируемости от Java и ее контейнеров? Я абсолютно не представляю и не представляю где бы мы взяли людей, которые бы это знали.

При этом, я очень хорошо отношусь к Java, продвигаю ее там где имеет смысл. Я даже почту читаю в eclipse ;-)

> Но вот как добиться контролируемости от Java и ее контейнеров?
> Я абсолютно не представляю и не представляю где бы мы взяли людей,
> которые бы это знали.

Могу дать reference ;)
Делается почти также, как в Це - выделяется большой массив и в этом массиве всё живёт.
Причём они данные в этом массиве даже паковали дефлэйтом (т.к. данных было слишком дофига) - всё равно получалось лучше, чем много миллионов объектов в работе у мусоросборщика.

<b>>> Делается почти также, как в Це - выделяется большой массив и в этом массиве всё живёт. <<</b>

Это не вполне так - в джаве нет понятия "массив объектов" (это будет массив _указателей_ с кучей объектов), но выигрыш (по производительности) будет - в джаве (за ким-то хреном) _безумно_ дорогой конструктор... т.е. выгодней завести пул объектов с полиси init/dispose. В ситуациях, когда порождается bunch кортокоживущих объектов (напр. DOM или всяческие "ивенты"), такая стратегия приносит ощутимый выигрыш по производительности (в том же xml-to-DOM иногда до 20% _кумулятивного_ времени).

Не.
Я нигде не писал про массив объектов.
Массив байтовый.
В этом массиве упакованные сессии (серверный софт).
Когда приходит новый запрос, то сессия распаковывается из массива в постоянно живущий объект, запрос обрабатывается и измененная сессия упаковывается обратно в массив.
Оказалось так быстрее, чем позволять сборщику мусора перелопачивать миллионы объектов.

Ну вот тут описана некоторая замысловатая конструкция, для изготовления которой нужны специальные люди, получаемые через reference. Причем, это все равно только часть задачи.

А на C++ это задачка для интервью на entry level

Случай уж очень специфический.
В большинстве задач нет многих тысяч параллельно живущих сессий и одновременного требования high system responsiveness.

Необходимость что-то делать с low latency может и специфический случай, но очень распространенный. На кажом компутере нынче чего только нет - и VPN, и VoIP и всякие файрволы

Вах! - "закат Солнца вручную" как в старом добром Си :-)

идею (и область применимости) понял, спасибо за пояснения.
...отчасти идея знакомая - те же АйБиЭм-еры проводили декомпозицию объекта в набор массивов с последующей "сборкой on demand"...
"есть многое на свете, друг Горацио..." - век живи, век учись :-)

Да не за что ;)
Там ещё куча деталей, про которые я сам слушал в пол уха.
Так что если нужно будет - обращайтесь. Этот человек консалтингом занимается в данный момент ;)

Я, кстати, вообще что-то не могу припомнить ни одного "кросс-языкового" бенчмарка, который вызывал бы доверие. Именно из-за разницы в идеологиях. Где-то связанный список строится malloc()ом на каждый элемент, а где-то это ядро рантайма и работа со списками вылизана до зеркального блеска. И поди, сравни это.
Имеет, наверное, смысл сравнивать решения одной и той же достаточно большой задачи, написанной независимо на разных языках и вылизанные до максимума. Но в больших задачах очень трудно изолировать слабые и сильные места.
dz прав в том, что задачи нынче редко упираются в процессор, и если упираются, то не имеет смысла пилить там надфилем ассемблер, а имеет смысл распараллелить и насовать побольше ядер. То есть он-то прав конечно, но мне вот вечно попадаются задачи, которые этот посыл опровергают, да и Лехе вон, тоже :-)

FFT в этом смысле - отличная бенчмарка. Простая, но вылизывать можно вечно.

Что же касается процессора - на роем я повозил dz об задачу, которая упирается в диск, а вовсе не в CPU. И хрен ты ее распараллелишь "просто"

Лёшик - у тебя всё в жизни окей, я надеюсь? Не кризис среднего возраста, ничего?
А то я вот как представлю, что я написал у себя в ЖЖ, что я кого-то повозил об задачу, так и дар речи теряю. Ты, прости за непосредственность, не опизденел чуток?

Я уж молчу о том, что я дал на твой умозрительный пример умозрительный же ответ, который (умозрительно) решает задачу не хуже, чем умозрительный пример.

Что вызвало у тебя возражения, что, мол, мой пример - умозрительный.

Но тон твой меня просто впечатляет. Прям вижу, как ты завтракаешь на олимпе с богами и покидываешь молнии в людишек.

А ты действительно не понимаешь, почему рандомизированный аллокатор не подойдет к обсуждавшейся задаче?

Ты так упорно держишься за рандомизированный потому, что первый совсем никак нельзя упрекнуть, или есть другая причина?

Ой, ты не ушел? Радость какая!

Первый вариант не описан достаточно, чтобы его можно было всерьез обсуждать.

Вдогонку.

Если можно - воздержись от мата, тут приличное общество.

Это вы льстите себе, увы. В приличном обществе нельзя услышать фразу "я повозил его об".

>> задачу, которая упирается в диск, а вовсе не в CPU. И хрен ты ее распараллелишь "просто" <<

Справедливости ради стоит заметить, что "почти распараллелить" удаётся сравнительно просто аппаратными средствами (SCSI). Да, мы понимаем, что это не распараллеливание, а "оптимизация очереди запросов", но сравнение "сказёвой" машины с каким-нить "убогим лаптопом" выглядит так, будто сказя "параллелят" запросы (ничуть не дискриминируя их на "системные" и "прикладные").

Ну и, в ряде случаев, такие операции могут параллелиться _буквально_ (почему, в частности, sys, temp/swap & app имеет смысл разнести не просто по разным "разделам", но по разным "спинам").

...ну и, конечно, дисковый кэш тоже никто не отменял (да, fault tolerance понижается... "но это уже совсем другая история" (с) АБС)

.

На сказях оно действительно портится несколько позже в смысле параллельности.

Ну и за счет того, что скази-диски меньше по емкости, на один и тот же объем достанется больше шпинделей, что тоже украшает жизнь.

Но правильно написанная сортировка упирается именно в линейное чтение с диска (а сиков - нет вообще в практическом смысле) и тут SATA никоим образом не хуже.

...эмммм...
Понятно, что к "завалишину" с его древней игрушкой (осподя! - "я помню, как всё начиналось" и остался чрезвычайно удивлён тем, что он до сих пор мусолит свой "фантом" :-))) это не имеет никакого отношения, но вообще-то упираться в мантру "дисковые I/O не параллелятся" просто опасно... "гугель учит нас" (просто самый "одиозный" пример), что сеть нынче _быстрее_ дисковых операций. Соотв. если уж задача упёрлась в диск, то её нужно "параллелить" на кластере (десяток/сотня "посредственных" машин с "потребительскими" винтами и "мощной" сеткой) + "мажоритарная система" (т.е. "избыточность")... заодно, кстати, позволяет бороться с "непредсказуемостью" БД.

для "локальных" приложений зачастую хорошо работают подходы а ля "кусочно-непрерывная сортировка". Т.е. "заглотили_кусок-обработали-выплюнули... повторить" с последующей "сшивкой" результатов. Если I/O неблокирующие, то это хорошо "параллелится" (главное - уравнять затраты "вычислительной" части и I/O).

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

Что же касается параллелинга I/O, то вот я на пальцах прикинул.
Представим себе, что у нас максимальный io request size = 64k, длина очереди - пусть 32. Это такие типичные значения. Т.е. в очереди - 2 мегабайта данных.
Если у нас один поток данных в смежную область, то это все выполнится со скоростью линейной записи, для современных дисков примерно за 20 миллисекунд (исходя из 100Mb/sec)
Если у нас два потока и в очереди оказались запросы для двух областей, то нужно прибавить average seek (пусть 4ms) и время полуоборота (еще 2ms) - итого 26 миллисекунд.
И для каждой новой смежной области, попавшей в очередь - добавляем эти 6ms.

Понятно, что если I/O size больше, очередь длиннее.... то в результате мы таки придем к полной сериализации, которая и есть идеал в данном случае.

По приведённому отношению величин (20/4/2) видно, что если диск у нас "умный" и "бегать" приходится не далеко и не часто, то лимитирующей стадией у нас является трансфёр хост-2-хост. Т.е. при собственном буфере в ~8MB для нас "сик-2-сик" виртуально исчезает - он выполняется на фоне, пока хост заглатывает очередную "двухмегабайтную" порцию данных.

возможно поэтому кэш на борту дисков такой "маленький" - всё равно больше <s>по каналу</s> "в глотку" ему и не пропихнёшь.

.

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

Диски, как я понял, пока на одном гигабите (по пропускной способности хост-2-хост) сидят, пока не устраиваешь "дуал ченнел"... с "поверхности", в пике плотности, снимают до гигабита. Т.е. в принципе, как я понимаю, "на пике" мы уже вполне способны различить "сик-2-сик" latency. Ну и, конечно, в терминах инициации операции "латентность" никуда не исчезает по любому - на то буфера "с отложенной записью" (либо напротив - "префетч") и существуют, чтобы "прятать" её.

но это всё трюизмы.
Я по другому поводу ,-) - надо бы снять канделябр с автора JTransforms, он сравнение провёл честно (если не считать, что в сях можно было бы и "маллоком" обойтись вместо "каллока", но это мелочи на уровне долей долей процента от процента ,-)) - hint: посмотри на имя "тест кейса" (fftwf_benchmark.c) и загляни внутрь его (там "неонка", причём весьма "прозрачная" ,-)).

PS: по поводу этих бенчмарков лично я, честно говоря, вообще не понимаю "поинта" - джава _не_ вычислительная платформа _и_ с/с++ _не_ вычислительная платформа. Чего их сравнивать на этой области ?!! - они одиноково "[не]эффективны" :-))

PPS: FFTW_MEASURE (2) сливает с учётом "planning phase", т.е. где-то там баааальшой косяк по алгоритмике лежит

#if defined(FFTW_SINGLE) || defined(FFTW_LDOUBLE)
#error "SSE2 only works in double precision"
#endif

семидесятипятирублируйте (с)
???
"Что это было, Бэрримор?"

впрочем, могу ответить таким же "телеграфным стилем":
-+-
<b>FFTW_DEFINE_API(FFTW_MANGLE_FLOAT, float, fftwf_complex)

#define FFTW_DEFINE_API(X, R, C) \
\
FFTW_DEFINE_COMPLEX(R, C); \
...
#define FFTW_DEFINE_COMPLEX(R, C) typedef R C[2]</b>
-+-

а на словах добавлю, что fftw3.h (тем самым) определяет тип fftwf_complex как float[2], а "тесткейс" fftwf_benchmark.c, в свою очередь, оперирует исключительно fftwf_* типами и айпиаем.

<i>задачи нынче редко упираются в процессор, и если упираются, то не имеет смысла пилить там надфилем ассемблер</i>

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

Ну почему ж. Мои любимые киношные программы так весело и писались. Ставим три барракуды в страйп и упираемся в процессор. Переписываем процессор на два потока и на видеокарту, упираемся в барракуды, ставим 8 барракуд в страйп, и т.д. Почти гигабайт в секунду с диска я лично видел.
Как и с тестированием языков - все зависит от структур данных и паттерна. Линейное чтение у дисков разгоняется очень хорошо и масштабируемостью и научно-техническим прогрессом.

К сожалению, при девелопменте для commodity железа так не выходит. Какие там "добавим 8 барракуд", у нас вот две любых версии вместе должны влезать на флэш любому нашему дивайсу, который еще стоит у консьюмеров в поле. Вот и программируй, хошь на джаве, хошь на смолтолке, все равно кроме C++ ничего не влезет ;-)

Если уперся в память или диск, то это повод подумать об алгоритмах.

И часто помогает.

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

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

Но общий вектор, конечно, верный.

Есть одна смешная вещь, которая меня удивляет из года в год. Вернее - уже из десятилетия в десятилетие.

Когда я говорил, что плёночной фотографии пиздец, такие люди как ты, Лёша (а может и ты тоже, не помню), пренебрежительно объясняли мне (ибо очевидно же, что они велики в фотографии, а я - лох), что я тупой, и что вонючий мегапиксель цифровика никогда не сравнится.

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

Они видят, что цифра - 1 мегапиксель, а плёнка - 10. И делают вывод - плёнка будет жить вечно.

А вот кривую роста разрешения цифрового фотоаппарата они не видят. И когда показываешь - видеть не хотят. Не царское это. Олимп, нектар, какой-такой павлин - отвянь. Кушаем.

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

А ещё есть другой параметр - стоимость производства кода. Который ты тоже, о свет моих очей, не видишь, потому что любишь задачи, в которых он не критичен.

И если не забыть выставить сравниваемое в СОВСЕМ равные условия, то нужно будет и стоимость производства сделать равной. И тогда график будет помногомерней, и вывод будет посложней.

Например, такой: "при затратах до $xxx ява и си сопоставимы с точностью до 10%". Или такой: "си даёт выигрыш более 10% при условии, что затраты на разработку на си в 10 раз больше и массив влезает в L2" - видишь, как интересно стали сокращаться поля побед? Я, правда, не знаю, как его сделать, но, впрочем, мне и не нужно.

Я могу взять FPGA и сделать FFT в железе, и чморить си. Только СОВЕРШЕННО не понимаю, зачем. Есть разные инструменты, разные задачи, и РАЗНАЯ СТОИМОСТЬ их решения. Ява и JIT на 90% задач дают отличное быстродействие - и слава богу. А что есть несколько задач, которые требуют детальной оптимизации - так я в курсе.

Ну - спокойнЕЕ надо. Есть вещи, которые и ты, о великий воин оптимального программирования, не видишь.

На сём прощаюсь. Извини, но ты ведёшь себя неожиданно по-хамски.

>Я могу взять FPGA и сделать FFT в железе, и чморить си.

Не можешь.

Ах. (Стреляется.)

Было б нехрен делать - предложил бы спор на 2x цены FFT IP core (подходящие к моим любимым FPGA FFT тут: http://www.dilloneng.com/fft_ip ). Залить недолго, но его ещё клеить к интерфейсу надо, а это гемор.

Языком почесать - можешь, в этом я не сомневался.

Давай почешем. Какой перформанс ты планируешь получить на размере данных порядка гигабайта? Ну там типа 2D, 8192x8192, complex
Какая себестоимость будет у платки? Интерфейс какой?

А то тут одни выпускали акселератор для N-body задач, тоже наверное чувствовали себя крутыми, чморили С.

Вот-вот.

Этой цели я и хотел достичь. Ты задумался не только о быстродействии, но и о цене его достижения.

"Так вот, сын - у птичек то же самое". В смысле - программирование на си тоже имеет цену и область применения - только там ты, отчего-то, об этом не задумываешься.

А насчёт "не можешь" - так FPGA вот рядом в ящике, и несколько экспериментов я с ней вполне делал. Хотя, конечно, я никогда не выпущу ничего продуктового в этой области. Но если мне будет нужно - применю.

Все-таки ты прощаещься и не уходишь. Ну давай тогда исходный поинт обсуждать, раз уж получается какой-то конструктив.

Вот смотри, ты уже ушел от первоначального утверждения (на которое я ссылаюсь наверху в посте) "С и Java - один хрен, они по-очереди быстрее друг друга". Потому что как только дело доходит до вылизанного С (и даже с ассемблером внутри), то шансов оказывается нет. А за предъявленные якобы шансы померяться в районе 8 мегабайт данных - надо фигачить канделябром до полного осознания ошибок.

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

Но тут выше в разных видах писали про хот-споты, библиотеки и кодеки.
В текущей мировой парадигме понятно - есть программа на С#, а когда ей нужно что-то, что бангалорец не может, он вызывает библиотеку, сделанную белым господином из Калифорнии, она фигачит по-настоящему на настоящем процессоре или каком-то акселераторе и делает те самые 90% работы в смысле времени выполнения.

Теперь, собственно, вопрос по существу: получается, что все подобные библиотеки обязаны быть частью (Phantom) ОС? Ибо приложению никакого доступа к физическому железу вы вроде как не даете, только байт-код.
Принести с собой 30 строчек на ассемблере не получится?

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

"Вот смотри, ты уже ушел от первоначального утверждения (на которое я ссылаюсь наверху в посте) "С и Java - один хрен, они по-очереди быстрее друг друга"."

Ссылку на цитату?

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

Ссылку на цитату?

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

В лёгком шоке. Пытаюсь вспомнить, где именно я тебя так сильно обидел.

>>"Вот смотри, ты уже ушел от первоначального утверждения (на которое я ссылаюсь наверху в посте) "С и Java - один хрен, они по-очереди быстрее друг друга"."
>Ссылку на цитату?
==
Отличный текст и бенчмарки Java vs. C++ - рекомендую посмотреть внизу график, на котором, в зависимости от объёма данных, один и тот же алгоритм работает быстрее ВДВОЕ то на яве, то на си.
==
По второму вопросу
===
Q: Мне сказали, что Фантом будет работать очень медленно, так как основан на интерпретируемом коде.

A: 90 % сегодняшнего профессионального ПО основано на интерпретируемом коде.
... далее про JIT и байткод...
===
Ну и в документации - про байткод.

1. Я просил ссылку на утверждение "С и Java - один хрен, они по-очереди быстрее друг друга". У меня в посте написан совсем другой текст.

2. где именно написано о запрете или неподдержке нативного кода? и не слабо ли было посмотреть на internal classes, и прикинуть, что они, вообще-то, несложно делаются загружаемыми?

Откуда это жуткое фидошное желание делать мудаков из людей? Чего в жизни не хватает? ЧЕГО, блин?

Ну ПИЗДЕЦ же, Тутубалин, реально!

Ты вложил мне в уста слова мудака, чтобы потом встать с указкой и показать, какой ты умный. Нарисовался перед сосками? Штырит? Я фигею.

>где именно написано о запрете или неподдержке нативного кода?

Мы же тут с высшим образованием, если про вопрос про интерпретатор есть ответ "нет, вы можете загрузить native-код" (с указателями, да?), это один ответ. А если "ну, почти весь код сейчас - интерпретируемый" - это другой ответ.
А если вы отвечая вторым способом имели в виду первый, то ясность изложения - подкупает.

Ну, увидим какой-то релиз, будет еще понятнее.

Ну, всё же нативный код в фантоме рушит идею. Проблемы с SSE решаются другими способами явно :)

http://blog.lexa.ru/2009/02/14/opera_of_the_phantom_ili_skazanie_o_kande...

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

Но альтернатива возможности реюза нативного кода - волшебный JIT, который будет векторизовать сам. А этого тоже нет. И что, в первые несколько лет эта махарайка будет жить без мультимедии? Ну-ну.

вы правы в том, что стоимость разработки, время и надежность это тоже важные параметры, не менее важные, чем производительность. но нужно разделять общий код и hot spot код, который вызывают часто и его время 90% программы, такой код обычно идёт в библиотеки. так вот, я считаю, что такой код нужно писать по-уму, и если нужно даже на ассемблере.

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

нужно искать баланс и адекватные инструменты для своих задач, раз Java, С и asm существуют, значит это кому-то нужно. здесь я с вами снова соглашусь.

пусть цветут сто цветов - это вообще очень удачная схема завершения сложного спора. :) Более того - я с этой позицией категорически согласен. :)

Но - два комментария.

1. Софт с каждым днём жрёт больше процессора на "единицу функциональности", и будет жрать В РАЗЫ больше. И это хорошо. Я скажу коротко, почему: потому что причина этому - индиректность. Со временем реализации всё более индиректны, менее жёстко связаны внутри и всё более параметризуемы. Цена этому - быстродействие, и человечество эту цену активно платит. И - есть за что.

2. Конечно, масштабируемость мало зависит от оптимизированности реализации, а порой зависимость обратная - неоптимальный код может параллелиться куда лучше. Более того - есть схемы, которые СИЛЬНО СНИЖАЮТ быстродействие, повышая параллелимость.

<i>Софт с каждым днём жрёт больше процессора на "единицу функциональности", и будет жрать В РАЗЫ больше. И это хорошо. Я скажу коротко, почему: потому что причина этому - индиректность. Со временем реализации всё более индиректны, менее жёстко связаны внутри и всё более параметризуемы. Цена этому - быстродействие, и человечество эту цену активно платит. И - есть за что.</i>

Дима, а что ты делал последние 20 лет? В смысле, каков твой кругозор кроме С, С++ и Явы? Мне просто интересно, какой надо иметь background, чтобы заявить это в 2009ом году.

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

А что угадывать? Я задал простой вопрос, мне на самом деле интересно. Я не собираюсь ничего аргументировать, и упаси боже, с тобой спорить. Я не собираюсь над тобой насмехаться что ты не знаешь X или не слышал об Y. Тут не хабрахабр, если ты еще не заметил.

"Тут не хабрахабр, если ты еще не заметил." - не знаю, не знаю.

Кирилл, у тебя моя фраза вызвала какую-то нестыковку. Изложи.

Единственное что тут общего с хабром - это ты. Не хватает только Готовцева.

Фраза вызывала нестыковку, потому что она даже не то чтобы не верна от начала и до конца, она просто описывает несуществующее физическое явление. То есть слово есть, а жопы нету.

А что, тебе стыдно признаться что-ли? В моем-то возрасте уже поздно пиписьками меряться, а ты постарше. Ты в каждом N-ном постинге пишешь про свой невероятный экспириенс и что ты типа "в индустрии" уже десятки лет. Мне и хочется узнать, использование какого инструментария тебя навело на мысль что жопы нет, фигурально выражаясь. Я как-то не предполагал что это потребует треда из 6-ти комментариев. Ты либо бы проигнорировал вопрос, либо послал меня нахуй, либо ответил. А ты прячешь личико в шарфик (под шляпку) и хихикаешь оттуда.

Знаешь - на мой взгляд общее с хабром - это вы с Лёшей. И могу обосновать. Я не могу припомнить, чтобы Я начал обсуждать ТВОЙ или ЛЁШИН проект, рассказывая людям, какие вы долбоёбы и пиздоболы. И не могу даже ПРЕДСТАВИТЬ себе такое поведение. А вам - нормально.

Это ТЫ говоришь, что явление не существует - ТЫ и обоснуй. Охуеть - я тут буду жизнеописание тебе выкладывать, чтобы пообсуждать его. Выложи своё, давай его пообсуждаем. (Правда, без меня - нахрен оно мне упёрлось.)

Есть чего сказать - говори. Нет - ну, молчи, наверное.

Мы с Кириллом стараемся не пиарить несуществующих вещей.

А вы с другим Кириллом - пиарите. А попытка покопать ваши утверждения вглубь (продукта нет, остается изучать ваш пиар) - вызывает кидание <s>перчатками</s> какашками.

Был бы продукт - было бы другое обсуждение. Пока же обсуждаем концепцию в тех деталях, которые вы раскрыли.

При этом, я вполне допускаю, что у вас есть какие-то цели, которые вы решаете пиаром vapourware. То что Готовцев (и в меньшей степени - ты) продолжает набрасывать говно на вентилятор, данную гипотезу скорее подтверждает. Ну тогда скажите нам спасибо.

Мы просто занимаемся интересными вещами. и люди о них говорят. бесплатно. Мы не пиарим.

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

Ну, знаешь, Готовцев даже до ежелиста добежал с анонсом. Не пиарим, my ass.

Если перестать докапываться к словам и требовать цитаты из вас же - можно конструктивно поговорить. Про тот же native-код, например.

<b>>> Мы просто занимаемся интересными вещами. и люди о них говорят. бесплатно. Мы не пиарим. <<</b>

Дима, а давай будем _предметными_
(цЫтирую источник без малого десятилетней давности): <i>"Концепции, сплавленные здесь, отчасти рождены коллективом программистов (Завалишин, Никонов, Положинцев) в 1990-м году, отчасти придуманы мной за последующие десять лет, отчасти взяты из гениального творения Intel по имени i432, отчасти - из таких разработок, как ОС Spring, Graal и Plan 9, OS/2 SOM/DSOM и OS/400."</i>

...wayback machine хранит "первое упоминание" об http://phantom.forums.psychology.ru/ (т.е. как бы переходу от "идей" к "началу воплощения") датированное 1-ым октябрём 2001-ого... т.е. двадцатилетняя история "развития идеи" и восьмилетняя история "имплементации", но при этом у вас нет даже "пилотного прототипа", который можно было бы "потрогать руками" (твою досаду по этому поводу уже где-то тут цитировали)

так чем же вы занимались все эти восемь лет ?... - "интересными вещами", или "интересным трёпом" и самообольщениями ?
что же у вас за душой, кроме фидошных приёмов полемики и невнятного бубнежа про "десятилетний экспириенс" ? - "тындекс гуру" сдох, так толком и не родившись, а "Фантом" продолжает агонизировать, что твой псис Фе<s>л</s>никс, да ? ,-)

извини, но если судить "по делам его" и по "портфолио" dz.ru, то ничего, кроме "веб-сайтов" и "веб-шопов", вы не сделали и уже вряд ли сделаете... а все эти "Фантомы" - они как фантомные боли в ампутированной ноге - чешется, и будет чесаться до конца дней твоих, но исключительно как воспоминание и повод к флейму (в духе "когда я был помоложе, я тоже имел коня" (c) ,-))

.

<i>Знаешь - на мой взгляд общее с хабром - это вы с Лёшей. И могу обосновать. Я не могу припомнить, чтобы Я начал обсуждать ТВОЙ или ЛЁШИН проект, рассказывая людям, какие вы долбоёбы и пиздоболы. И не могу даже ПРЕДСТАВИТЬ себе такое поведение. А вам - нормально.</i>

Слышь, хамло подзаборное, а за базар ты ответить в состоянии? Покажи пожалуйста мне ссылочку, где я бы рассказывал людям какой ты долбоеб и пиздобол? При том что я тебя, безусловно, считаю и тем и другим. И сейчас ты сделаешь тоже самое что делал много раз до этого - когда тебя припрут к стенке и попросят ответить за базар - сделаешь вид что ничего не было и смертельно обидишься.

Все что я написал - я написал что тебя сюда звать бессмысленно ибо начнется обычное бесполезное фанатство. Что, собственно, и произошло.

Это обещанный "фидонет с гиперссылками"? :-)

Да, в этом фидонете Диме существенно менее уютно. Тут ссылки есть! А в настоящем пiдо, пойди найди ссылку - "база уже попуржилась".

Хммм... "какие нервные лица - быть беде" (с)

а почему такая реакция, как будто застали в общественном туалете типа "очко" за занятием постыдным и унизительным (типа выдавливания застарелого геморроя) ?

мне, например, тоже интересно, почему "фантомные" идеи, уже давно реализованные в других языках/метасистемах, вдруг преподносятся как нечто инновационное и ранее невиданное, но которое непременно принесёт "щастье всем даром, и путь никто не уйдёт..." (с)

или, например, реплики в духе - <i>"Сегодня заменить спеллчекер в ворде - это можно, но непросто, а завтра будет неприлично - просто неприлично - выпускать софт, в котором выраженные функциональные компоненты незаменяемы. Не самый удачный, но иллюстративно приемлемый пример."</i> - это _действительно_ означает, что кроме винды и "полуоса" Дима Завалишин ничего не видел и не знает, или он просто так "утрирует", ориентируясь на определённый сегмент "аудитории" ?

.

Когда я говорил, что плёночной фотографии пиздец, такие люди как ты, Лёша (а может и ты тоже, не помню)
....

А я еще помню того dz, который говорил, что цифра - говно, но имеет killer app в виде домашнего порно :), потом - что цифра рулит, потому что позволяет привезти 10000 фото из поездки и т.д.

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

Но пленке массовой - пипец, да. Не потому, что цифра ее уделала, а потому что пиплу глубоко начхать на то, уделала л иона ее, а достаточно того, что она проще в обращении. Так что на вектор развития что смотри, что не смотри - толку мало :)

<b>>> Когда я говорил, что плёночной фотографии пиздец, такие люди как ты, Лёша (а может и ты тоже, не помню), пренебрежительно объясняли мне (ибо очевидно же, что они велики в фотографии, а я - лох), что я тупой, и что вонючий мегапиксель цифровика никогда не сравнится. <<</b>

Ну, "я помню как всё начиналось" и даже сам поучаствовал. В то время ты трындел, что твоя agfa, помещающаяся "в задний карман брюк", уже поставила крест на слайде а "года через три он (слайд, бишь) сдохнет окончательно"... прошло десять лет, но слайд продолжает жЫть, что характерно... и сравнивать цветопередачу слайда и CMOS/CCD по-прежнему смешно.
и до сих пор можно пойти и купить "плёночник" и плёнок к нему - рынок цветёт и пахнет.

... но это всё "художественная лирика".
Интересней другое - наш дядя Дима с "более десяти лет экспириенса в индустрии" сумеет _внятно_ объяснить чем же "Фантом" (с педальным приводом ,-)) так _кардинально_ отличается от того же SmallTalk ? (и гугель ему, дяде Диме, в помощь... на склоне "десяти лет экспириенса в индустрии" ,-))

<b>>> А ещё есть другой параметр - стоимость производства кода. Который ты тоже, о свет моих очей, не видишь, потому что любишь задачи, в которых он не критичен. <<</b>
хм,
а дядя Дима что-нибудь слышал про "Objective-C" и ту жопу (да-да, не "задницу", а именно "жопу"), в которую его вогнали всё те же стивы джобсы вместе со "стоимостью производства кода" ?.. а это оч.поучительная притча, объясняющая почему "презренная джава" преуспела, а Obj-C оказался... эммм... "маргинальным" что твой asm в *nix.

...по поводу "у нас нет файлов" тоже смешно... это примерно как заявлять, что "вместо файлов у нас registry" - те, кто не знает что такое registry, поверят (они вообще чему угодно поверят ,-)), остальные - улыбнуться ("по-доброму, как деды наши любили" (с) ,-))

-+-
<b>>> Ну - спокойнЕЕ надо. Есть вещи, которые и ты, о великий воин оптимального программирования, не видишь. <<</b>

Дядя Дима, а давай _спокойно_ обсудим implications, которые привносит с собой в "дот-нет"/"ждава" такой "прозрачный", с виду, GC... а _потом_ обсудим implications твоего "imaginary" "персистент вейвера"... не слабо-то, после "десяти лет в индустрии" ? ,-)

.

про слайд -- смешно. Да, он жив, четрые с половиной марки, да им пользуются (сам пользуюсь, широким), да, да, да и виниловые пластинки мой отец до сих пор покупает (новые!), и есть бытовые ламповые усилители. Но это всё МЕРТВО. Потому что, даже при очень высокой цене экземпляра, объём этого рынка СМЕХОТВОРЕН.

вечная тема... :-) на самом деле сложный это вопрос.

для относительно простых (алгоритмически) вычислительных задач вроде умножения матриц Java и C# будут медленнее, т.к. реально вручную написать оптимальный код на ассемблере (хотя для этого нужно время и высокая квалификация).

с другой стороны, очевидно, что ассемблер ограничен сложностью программы, написать на нём ОС уже очень и очень трудно из-за кол-ва человекочасов, и главное, из-за сложности (трудно писать надежный код, нет механизмов защиты, сложно тестировать и тд). поэтому он применяется локально для hot spot, а итоговая программа лишь вызывает такие kernel. с этим подходом возникают следующие проблемы:
1) не всегда имеющиеся kernelы подходят для нашей задачи. пример - надо умножить вещественную матрицу на комплексную - во многих библиотеках такой функции нет.
2) нет нужной гибкости. хороший пример - ленивое программирование, пусть нужно провести некую последовательность вычислений, суть в том, что зная всю последовательность заранее можно применить некие формулы и упростить выражение, тем самым избежав лишних вычислений. при этом может быть важен какой-то нестандартный доступ к данным, который не реализуется через имеющиеся kernel.
3) самое главное - с выходом каждого нового процессора нужно переписывать весь код (огромная работа), а пока код не переписан выигрыша от новых SIMD и пр. нет.

лично я считаю, что единственный способ писать быстро, надежно и при этом получать эффективный код - использовать некий абстрактный язык, достаточно высокоуровневый и позволяющий выражать внутренний параллелизм алгоритма. далее есть компилятор в любую архитектуру. переписывать такой код нужно только при переходе на новый алгоритм (относительно редко). к сожалению, на данный момент такого языка нет. наиболее близкое из имеющегося - Sh, Сt.

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

Если говорить именно про вычисления - да, есть интересные надежды на OpenCL, хотя довольно очевидно, что навеян он существующим железом, а если OpenCL пойдет, то затем железо будут делать под OpenCL.

Конечно, если заставить программиста выражаться параллельно, то параллелить будет проще.

>Конечно, если заставить программиста выражаться параллельно, то параллелить будет проще.

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

новый суперкомпьютер-кластер IBM будет иметь около миллиона CPU. для него задача балансировки нагрузки намного важнее, чем выжать всё из отдельного CPU.

P.S. про Intel i7. вроде 3 SSE юнита есть начиная с P4 (add/mul/IO). насколько я знаю, существенных изменений в SSE юнитах у i7 относительно Core 2 нет (кроме поддержки SSE4.2).

Так проблема с параллельностью (как и с этой мифической "индиректностью", которая доступна уже десятки лет за копейки и про которую трепло в шляпе только что услышало) - либо в алгоритме, либо в побочных эффектах. С алгоритмом как таковым ничего не сделаешь, если он не параллелится в принципе (шаг N+1 зависит от результатов шага N), а с побочными эффектами давно научились бороться функциональные языки.
Берем например Эрланг и получаем и параллельность, и "индиректность" и самодеплоймент на распределенные системы. Старый, промышленный язык.
Проблема-то на самом деле в другом. Проблема в том, что система на том же Эрланге попадает в руки вот такому вот индусу в шляпе, который весь мир вокруг видит через <s>прицел</s> книжку про J2EE. И он ее переписывает на яве, потому что ну как же так, треды без контекст свичей. Непорядок. Надо все сделать вручную, чтобы борьба с контекст свичами была бы видна невооруженным глазом. И когда <lj user="lionet"> продаст <a href="http://js-kit.com">свою компанию</a>, то покупатели перепишут его серверсайд на С++, питоне или яве. Как это произошло с Грэмом и Viaweb. Поэтому продукт на "непонятном языке" становится отрицательным фактором в борьбе за джекпот, и многие предпочитают пожертвовать скоростью разработки, перформансом и прочим ради чистогана. Мир населен индусами, в шляпах или без, и с этим приходится считаться.

много букв :-) я не понял по какому именно вопросу вы пишите. я не веду философский спор, а лишь высказался по теме "asm vs Java" для вычислений.

<i>именно. это ключевая идея. пусть оптимальный код это никогда не даст, но зато даст надежный, масштабируемый код и позволит сконцетрироваться на алгоритмах.</i>

Именно эту задачу (в частности) и решают функциональные языки. И, заодно, многие из них очень эффективно компилируются.

с этим никто и не спорит. вы наверное подумали, что я за Java? - это не так. точнее, не для вычислений она.

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

я работаю в сфере вычислительных методов, решаем матфизику конечными элементами. так вот, самые мощные и гибкие пакеты конечных элементов написаны на С++. многие были переписаны из С, т.к. это ко всему прочему увеличивает производительность (в каком-то смысле это удивительно). объекты не всегда зло, просто их нужно умело применять.

прямо удивительно. C++ позволил ускорить программу? Объекты помогли?
кроме фокусов александреску с темплейтами и метапрограммированием объективных причин вроде нет?

Какая причина может заставить программу на C, которая использует vtable работать быстрее программы на C без vtable?

видимо ускорение получили благодаря тому что алгоритмы подправили?
Рефакторинг он полезен в не зависимости от языка. Вы, похоже, провели рефакторинг и заодно добавили фишки плюсов.

>> но в общем когда отдельные куски соберут вместе, система получается жирнее, memory footprint гораздо больше, отчего в cache влезает меньше и в результате все равно получается плохо <<

А это отдельная "лебединая песТня".
Напр. два обстоятельства:
*: Garbage Collection (GC)
*: в упрочь не оптимизирующий javac ("Буратино был тупой.. тупой... тупой, как дрова" (с) Псой Короленко - )

во-первых, GC периодически ставит на уши весь "пейджинг"... ну работа у него такая - ходить и "всё трогать руками".
во-вторых, GC более менее эффективно работает до тех пор, пока "хип" приложения не превосходит половины физич. RAM (т.е. пока "хип" более менее не свопится)
в-третьих, больно смотреть на GC, когда он вынужден перейти со стратегии mark-sweep на mark-compact - производительность всей системы (апликухи) падает на _порядки_ (причём в "аналогичной" ситуации "прямолинейные аллокаторы" в стиле С/С++ продолжают работать без заметной деградации по производительности).

в-четвёртых, у GC обнаруживаются трудности с "распознаванием" и "деаллокацией" сложных развесистых структур (напр. достаточно глубокого и пЫшного графа), в результате "мусор" может жить _оч. долго_ и собираться только когда апликуха угодит в idle (и у GC, соотв., появляется время для более скрупулёзного анализа всех этих связей и путей "ричибилити")... справедливо для jdk up to 1.4 inclusive (для последнего jvm, i.e. jdk1.5+, не проверял).

в-пятых, с учётом тупости компилятора (что справедливо как минимум для javac вплоть до 1.6+), возможны протечки памяти по абсолютно примитивной схеме - чего-то нааллокировали на локальную переменную, поработали с этим и ушли "навечно" в какой-нибудь метод (не покинув, разумеется, текущий... характерный пример - рекурсия или обработка большого массива данных с "препроцессингом"). Т.е. "переменная" (жЫрный вспомогательный класс-"препроцессор") больше не используется, но сцЫлка на него держится, что не позволяет GC собрать объект как мусор.
Оптимизирующий компилятор мог бы понять (и С/С++ компиляторы умеют это делать), что "[здесь] переменная далее не используется" и, хотя бы, занулить ссылку. Однако - "фигвам" - такие вещи приходится делать руками, чего, разумеется, никто не делает.

...ну и, конечно, "underlying library" (jdk, например) тоже поражают воображение в самую пятку. Напр. реализацию какого-нить ByteArrayOutputStream эти уроды сделали через примитивный врапер вокруг byte[], который тупо реаллокируют "по мере надобности" (причём по-простецки - "вдвое")... и это для объекта с "последовательным доступом" без операций типа "insert"/"delete".

в общем, всё плохо в датском королевстве, и все эти "кэш-промахи" даже не верхушка айсберга, а так - "музЫкальная пауза" для "лохов с пейджером" :-(

Ой! какую прелесть нарыл:
Кирилл Готовцев - <i>"Поскольку концепция сильно визионерская, то тексты, которые мы публикуем предполагают некоторое специальное состояние мозгов..."</i> (см.тут - http://roem.ru/2009/02/10/addednews9576/)

унтер-офицерской вдове, что сама себя высекла, остаётся только локти кусать в бессильной зависти :-))

Блин, потратил полчаса жизни на это чтение ... Much ado about nothing.

:-)
Ну, говорят - "смех жизнь продлевает",
так что может "то на это" и вышло (и может даже с "дивидендами").
Хотя смех, конечно, "брутальный" получается (серьёзных вопросов Завалишину так и не было задано, а с другой стороны - задавать серьёзные вопросы Завалишину, само по себе несерьёзно... catch22, однако ,-))

Блин. Как грустно на это смотреть :(((

и про SSE. Это же решается на раз-два.
Класс (системный) cpu, в нём методы -- по всем командам sse, что есть сейчас (запустились на другом CPU -- другие), JIT про него (класс) знает и инлайнит методы в 1 команду, мы имеем все приемущества аллокатора/планировщика регистров JIT'а в дополнение к прямому доступу к SSE... Всё.

Кстати, гуру ассемблера, как у вас с планированием команд на исполнительные устройства вручную для современных процессоров? Почему все эффективные кодеки есть отдельно под core2 и под phenom? Потому что статически скомпилированы, а команды там хоть по сути и одни и те же, но в разном порядке надо выполнять, что бы достичь максимума производительности. JIT это сделает за вас не хуже топового статического компилятора.

Не надо JIT недооценивать -- в конечном итоге тот же Intel C/C++ даёт лучшую производительность при PGO, а JIT -- он гораздо больше приспособлен к PGO, чем статический компилятор.

Лев, проблема не в доступе к SSE per se. Проблема в том, что для эффективного использования недостаточно (хотя и необходимо) знать, как данные в памяти разлеглись, а надо на это разлегание влиять. А никакой JIT не повлияет, уже поздно, все разложили.

JIT вполне может повлиять. Уже сейчас JIT у Java (HotSpot) учитывает особенности кешей именно того процессора, на котором сейчас запущено, при генерации кода. NUMA уже учитывается при аллокации (на Solaris в полнос объёме, на Linux с ограничениями из-за ограничений информации, предоставляемой ядром Линукса). Следующий шаг -- именно анализ структур данных...