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

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

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

Это видно и без конвертора. В том смысле, что сразу после распаковки, без какой-то обработки. При этом распаковка - по строкам.

А может глюк конвертора? Или просто шутка первоапрельская.

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

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

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

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

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

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

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

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

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

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

Я печатаю на обычной бумаге (фотобумаге для принтера), а монтирую на двусторонней самоклейке. Self-wound mount film, там выше все написано..

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

?

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

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

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

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

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

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

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

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

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

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

Ну какой он реалистический.
Вот в среднем тоне R/G/B=120/146/156

Сделай файл с такой заливкой, подывысь.