Gaperton wrote: > Ой, правда штоли? Что же тогда gear nuke так отмахивается от идеи > использовать такой хороший gcc при сравнениях с окамлом? А, понял — > тогда у нас окамл самый быстрый в мире язык получится. .
Вообще-то, я сравнивал с gcc (лень было ocamlopt ставить на рабочую
машину). Вот результаты: http://rsdn.ru/Forum/?mid=1520744
Здравствуйте, gear nuke, Вы писали:
GN>Тесты делались заинтересоваными людьми.
С чего вы взяли? Люди взяли самый популярный компилятор под Linux, и им было совершненно неинтересно, кто победит в этих тестах. А победил OCaml. Какая реклама получилась!
GN>Мне было совершенно неинтересно, кто победит в моих тестах. Я не фанат С++, но выбрал этот язык исходя из практических его качеств, в которых скорость для меня не последнее место занимает. Победил бы OCaml — кинулся бы его изучать. Какая реклама была! Жалко, что с основами маркетинга не знаком рекламирующий, такое только отталкивает
Действительно — если для вас разница в производительности в 30% на взятой с потолка задаче и компиляторах является поводом бросаться или не бросаться изучать сам язык, то это уж точно победа интеллекта над разумом. Основой маркетинга в данном случае является то, что ни мне, ни reductorу совершенно не интересно заставлять вас учить OCaml. Нам совершенно все равно, броситесь вы его учить, или нет. Воспринимаете вы наши слова как рекламу, или они вас отталкивают. Поймите, все равно, уличных продавцов и торговых агентов здесь нет.
GN>Поймите, что если человек делает 5 утверждений, и одно из них на поверку оказывается неверным, под сомнение ставятся все остальные.
Я ставлю под сомнение вообще все утверждения, которые вижу, и никакой трагедии или взаимных следствий в этом не вижу. Ошибаются все. В вашем случае — похоже, что вы не хотите разбираться в сути этих утверждений, и хотите найти получше повод считать собеседника идиотом, а доводы его — ошибочными.
Суть состоит в том, что в теории ассемблер будет быстрее вашего С++. На практике, однако, получается почему-то наоборот — а фокус в том, что пока программист на ассемблере будет расставлять оптимальным образом регистры, программист на С++ успеет попробовать несколько алгоритмических оптимизаций, которые всегда дают гораздо больший эффект. Т.е. программа, написанная за то же время, будет быстрее.
OCaml на довольно широком классе задач, связанных с обработкой сложных структур данных, дает выигрышь по сравнению с С++ по срокам разработки. При этом, кодогенератор держит паритет с gcc. Та же ситуация — в реальной жизни на длинной и сложной программе у программиста на OCaml останется больше времени на алгоритмические оптимизации, и вас не спасет даже IC++. Так что в реальном проекте при ограниченных сроках OCaml может окажется быстрее. Об этом вам и пытался сказать reductor — тезис известный, на самом деле.
Это объяснение я не для вас пишу — для тех, кому интересно разобраться, что имел в виду reductor. Потому что вам окамл противопоказан — пишите на С++, это лучший и самый быстрый в мире язык. Ваша мысль, что кто-то вам что-то рекламирует — ошибка.
Gaperton wrote: > OCaml на довольно широком классе задач, связанных с обработкой сложных > структур данных, дает выигрышь по сравнению с С++ по срокам разработки.
Дело в том, что класс задач по обработке сложных структур данных сам по
себе недостаточно широк.
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote: >> OCaml на довольно широком классе задач, связанных с обработкой сложных >> структур данных, дает выигрышь по сравнению с С++ по срокам разработки. C>Дело в том, что класс задач по обработке сложных структур данных сам по C>себе недостаточно широк.
Дело в том, что во первых, мы отметаем это утверждение как голословное и лишенное смысла из-за общности и неконкретностии, а во вторых — напоминаем, что класс задач, требующий бешеной производительности — сам по себе узок как танковая смотровая щель. И для таких задач, как это ни прискорбно, чаще всего применяется Fortran.
Gaperton wrote: > Дело в том, что во первых, мы отметаем это утверждение как голословное и > лишенное смысла из-за общности и неконкретностии, а во вторых — > напоминаем, что класс задач, требующий бешеной производительности — сам > по себе узок как танковая смотровая щель.
А вот тут полностью не согласен. Производительность ОЧЕНЬ важна для
многих настольных приложений, игр. Ну и для самой ОС.
> И для таких задач, как это ни прискорбно, чаще всего применяется Fortran.
Не путайте. Fortran применяется для числодробилок, которые далеко не
исчерпывают класс критичных к скорости задач.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Cyberax, Вы писали:
C>>Gaperton wrote: >>> OCaml на довольно широком классе задач, связанных с обработкой сложных >>> структур данных, дает выигрышь по сравнению с С++ по срокам разработки. C>>Дело в том, что класс задач по обработке сложных структур данных сам по C>>себе недостаточно широк.
G>Дело в том, что во первых, мы отметаем это утверждение как голословное и лишенное смысла из-за общности и неконкретностии, а во вторых — напоминаем, что класс задач, требующий бешеной производительности — сам по себе узок как танковая смотровая щель. И для таких задач, как это ни прискорбно, чаще всего применяется Fortran.
Только оказывается что фортарновские библиотеки типа MKL внутри написаны на ассемблере и C.
И кстати вот такой каверзный вопрос. Я не совсем понял, что имеется ввиду под сложными структурами данных? У меня к примеру сейчас основная задача проанализировать несвязанную геометрию (набор поверхностей) и сделать из этого добра замкнутую связанную оболочку. Структуры данных весьма сложные, как ocaml может помочь?
Здравствуйте, reductor, Вы писали:
R>Cons — это в данном случае _конструктор_ тупла 'a * 'a list R>ничего магического в слове нет R>можно написать:
[скипнут код]
Ага, тупл... А говоришь — не агрегат
V>>Кста, еще один важный момент. В моем примере я использовал сложное предствление списков pair<Cell*, Cell*>, с тем, чтобы сделать время конкатенации константным, иначе описанный qsort будет работать медленнее пузырька V>>Т.е., OCalm-овский список — это просто ячейка Cons (указатель на оную)? Без хранения указателя на последний элемент???
R>Поскольку списки, как мы выяснили, специфичны для окамла не больше, чем для C++, то никто не мешает создать тип вида: R>
R>type 'a fastlist = FastList of 'a list * 'a list
R>
R>и хранить там и голову и конец
Понятно, прикольно... Вся фишка в туплах, и мы может строить произвольные по размерности туплы, так?
Просто я рассмтаривал код на OCalm с т.з. своих некоторых давних познаний Лиспа и Пролог. Т.е. записи "[]" и "pivot::rest ->" трактовал весьма однозначно. Хе, тогда все еще прикольнее, если туплы могут иметь произвольную размерность. Наворотить можно нехило
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote: >> Дело в том, что во первых, мы отметаем это утверждение как голословное и >> лишенное смысла из-за общности и неконкретностии, а во вторых — >> напоминаем, что класс задач, требующий бешеной производительности — сам >> по себе узок как танковая смотровая щель. C>А вот тут полностью не согласен. Производительность ОЧЕНЬ важна для C>многих настольных приложений, игр. Ну и для самой ОС.
Хорошо, отвечаю по пунктам.
1) Для подавляющего БОЛЬШИНСТВА настольных приложений жертва в скорости выполнения в два раза будет совершенно незаметна пользователю. У меня дома стоит 1.5ГГц, на работе 3. Разницы я не замечаю.
2) Windows XP работает совершенно одинаково как на моем втором домашнем 750 Duron, так и на моем рабочем 3ГГц пентиум. Так что не надо делать голословные и некорректные суждения — их слишком легко проверить. Производительность ОС, кстати, определяется в основном размером оперативной памяти и дисковой подсистемы.
3) Игры — единственный класс настольных приложений, где это более или менее критично. Тем не менее, при разработке реальной игры сроки разработки сжаты, и времени на алгоритмические оптимизации в случае С++ у вас будет меньше, чем в случае яхыков высокого уровня, таких как OCaml. Так что в реальности, когда у вас есть сроки и бюджет, вы просто не сможете достичь хваленой высокой производительности, видной на микротестах, так как не успеете разработать "умные" алгоритмы. Хотя никто и не предлагает писать на OCaml игры .
4) В реальных приложениях узкие места по производительности локализованы в небольшом проценты кода. Именно по этому разработчики игр активно используют LUA, который чудовищно тормозной. Именно поэтому основной объем кода управляющей программы самого быстрого ATM-свитча AXD301 написан на тормозном Erlang, с небольшой частью на С++. И ничего.
4) Индустрия уже сделала свой выбор и неоднократно давала ответы на тезис "производительность ОЧЕНЬ важна". Это:
— языки высокого уровня против ассемблеров. Те же самые дискуссии велись в конце 70-х, результат известен.
— виртуальная память вместо оверлеев.
— Управляемые среды .NET и Java с жертвой производительности вдвое. На Java и .NET уже пишут игры, для которых, как вы говорите ОЧЕНЬ нужна производительность.
Дальнейшую глупую дискуссию по очевидным вопросам с переливанием из пустого в порожнее со своей стороны закрываю. Мне в этом вопросе — все ясно. И это для меня главное.
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще, все современные компиляторы в чем-то будут лучше других, в Pzz>чем-то будут хуже. Утверждать, что один из них кардинально лучше другого Pzz>в плане кодогенерации было бы наивно.
Что вы, наивности я за собой не припомню. Я вот, например, сейчас утверждаю: Intel C++ кардинально лучше текущей версии gcc в плане кодогенерации на платформе x86. В силу существенно более сложного кодогенератора — у него там полная модель интеловых процов внутри, которая почти все факторы учитывает, с легкостью обходя в этом программиста на ассемблере. Да, я берусь утверждать, что вы не сможете обогнать IC++ при ручном кодировании на ассемблере на более-менее нетривиальном алгоритме — это за пределами человеческих возможностей. Хотите — проверьте сами .
Здравствуйте, Cyberax, Вы писали:
C>А вот тут полностью не согласен. Производительность ОЧЕНЬ важна для C>многих настольных приложений, игр. Ну и для самой ОС.
Для игр по большому счету — нет. ~80% кода современных игр написаны на Lua (и еще ~10% на всяких Python, Javascript etc.) — а как у Луа со скоростью, можете там же взглянуть ( http://shootout.alioth.debian.org/benchmark.php?test=all&lang=gpp&lang2=lua ). Игры давно перешагнули тот порог сложности, когда их имело смысл целиком писать на С++. (Точнее, такого периода в истории игростроения практически не было — сначала писали на чистом ассемблере, а потом, одновременно с переходом на С, начали прикручивать самопальные скрипты)
Кстати, все обходят вниманием то, что ладно скорость приличная, но ведь и памяти Ocaml ест не больше C++, что для языка с GC совершенно нетипично.
z00n wrote: > C>А вот тут полностью не согласен. Производительность ОЧЕНЬ важна для > C>многих настольных приложений, игр. Ну и для самой ОС. > Для игр по большому счету — нет. ~80% кода современных игр написаны на > Lua (и еще ~10% на всяких Python, Javascript etc.) — а как у Луа со > скоростью, можете там же взглянуть
Ну да. Яркий пример — Civilization IV. Большая часть написана на Питоне
и жрет 2Гб памяти.
В современных играх на Lua пишут триггеры, запускающие какие-то
действия. Их получается по объему много, так как приходится много писать
для каждого уровня игры. Но вот по времени они занимают очень небольшую
часть.
Здравствуйте, Cyberax, Вы писали:
C>В современных играх на Lua пишут триггеры, запускающие какие-то C>действия. Их получается по объему много, так как приходится много писать C>для каждого уровня игры. Но вот по времени они занимают очень небольшую C>часть.
По времени исполнения — небольшую часть, а по времени разработки — бОльшую.
Игра это и есть в основном "триггеры" и "картинки", а не то, что называют engine, который да, скорее всего написан на С/С++.
Пример для масштаба (из сметы MMORPG c бюджетом ~30M$):
Программирование:
AI — 3 человека (триггеры)
UI — 3 человека (???)
Server Architechure — 2 человека (специалисты по DB)
Distributed Computing — 2 человека (сервер — это Java на кластере)
Client Team — 3 человека (Lead + 2 Graphics Engine Specialist)
World Building — 19 человек (скрипты)
Картинки: — в совокупности 16 "художников"
Звук: — 1 человек
Eще 20-30 человек Q&A, CS, клерки, пара гейм-дизайнеров.
Т.е из 32-х программистов, С++ используют от силы 6 человек (я оптимистично включил в их число UI ).
C>Ну да. Яркий пример — Civilization IV. Большая часть написана на Питоне
и жрет 2Гб памяти.
На PS2 есть Jax & Daxter, AAA тайтл, написанный на Лиспе (другими словами: GC), который не тормозит на 32Mb. От людей все зависит, а не от языков
Gaperton wrote: > > Pzz>Вообще, все современные компиляторы в чем-то будут лучше других, в > Pzz>чем-то будут хуже. Утверждать, что один из них кардинально лучше другого > Pzz>в плане кодогенерации было бы наивно. > > Что вы, наивности я за собой не припомню. Я вот, например, сейчас > утверждаю: Intel C++ *кардинально *лучше текущей версии gcc в плане > кодогенерации на платформе x86. В силу существенно более сложного > кодогенератора — у него там полная модель интеловых процов внутри, > которая почти все факторы учитывает, с легкостью обходя в этом
Вы можете подкрепить свои общие утверждения какими-то конкретными
фактическими материалами? Если нет, то это как раз демонстрирует
наивность Вашего подхода.
Не забывайте, кстати, что x86'я архитектура, это не только Intel, но и
AMD. И вот на генерацию кода под AMD Интеловским ребятам было, мягко
говоря, наплевать.
> программиста на ассемблере. Да, я берусь утверждать, что вы не сможете > обогнать IC++ при ручном кодировании на ассемблере на более-менее > нетривиальном алгоритме — это за пределами человеческих возможностей.
А что, IC++ боги, что ли, писали? Если они смогли написать хороший
кодогенератор, то и я смогу руками сгенерировать хороший код. Не за 5
минут, конечно Вопрос только, зачем?
> Хотите — проверьте сами .
Здравствуйте, Pzz, Вы писали:
Pzz>Gaperton wrote: >> >> Pzz>Вообще, все современные компиляторы в чем-то будут лучше других, в >> Pzz>чем-то будут хуже. Утверждать, что один из них кардинально лучше другого >> Pzz>в плане кодогенерации было бы наивно. >> >> Что вы, наивности я за собой не припомню. Я вот, например, сейчас >> утверждаю: Intel C++ *кардинально *лучше текущей версии gcc в плане >> кодогенерации на платформе x86. В силу существенно более сложного >> кодогенератора — у него там полная модель интеловых процов внутри, >> которая почти все факторы учитывает, с легкостью обходя в этом
Pzz>Вы можете подкрепить свои общие утверждения какими-то конкретными Pzz>фактическими материалами? Если нет, то это как раз демонстрирует Pzz>наивность Вашего подхода.
1) Если у вас есть знакомые из компании Мирантис, советую связаться с ними и узнать, каким образом применение IC++ позволило им увеличить производительность симуляции процесса литографии на 20% (насколько я помню).
2) Потрудитесь сами взглянуть на тесты IC++. Их несложно найти в интернете — времени уйдет меньше, чем на выяснение степени моей наивности. Для вас, я вижу, последняя проблема имеет больший приоритет .
3) Зайдите в наш форум С++ или на какой-нибудь форум разработчиков игр, и повторите ваши рассуждения. Вам объяснят подробно и на примерах, кто наивен.
4) Так как ваш не наивный подход не предполагает самостоятельный поиск ссылок, даю первое, что нашел — для общего развития:
IC++ рвет MSVC: http://www.ixbt.com/cpu/insidespeccpu2000-compilers.shtml
gcc против IC++ на тесте SPEC2000: http://www.ixbt.com/cpu/insidespeccpu2000-part-h.shtml
IC++, MSVC 6 и 7: http://www.ixbt.com/cpu/insidespeccpu2000-compilers-add1.shtml
Для тех, кто в танке — еще раз: IC++ рвет gcc на кровавые ошметки: http://www.ixbt.com/cpu/insidespeccpu2000-compilers-add2.shtml
Pzz>Не забывайте, кстати, что x86'я архитектура, это не только Intel, но и Pzz>AMD. И вот на генерацию кода под AMD Интеловским ребятам было, мягко Pzz>говоря, наплевать.
>> программиста на ассемблере. Да, я берусь утверждать, что вы не сможете >> обогнать IC++ при ручном кодировании на ассемблере на более-менее >> нетривиальном алгоритме — это за пределами человеческих возможностей.
Pzz>А что, IC++ боги, что ли, писали? Если они смогли написать хороший Pzz>кодогенератор, то и я смогу руками сгенерировать хороший код.
Флаг в руки. У вас или комбинация феноменальной памяти и великолепное знание нюансов устройства современного процессора, или это наглядная демонстрация наивности Вашего подхода. Да, в феноменальную память и умение предсказывать конвейерные и суперскалярные эффекты в уме я не верю.
G> Хотите — проверьте сами . Pzz> Не хочу.
И это правильно. Мешки ворочать — тяжелая физическая работа, недостойная благородного дона. Давайте посмотрим, как с ний справляются другие умудренные жизнью оптимисты, думавшие, что могут обойти кодогенератор IC++. Незнаю как вам — мне было очень весело.
Здравствуйте, Gaperton, Вы писали:
G>> Хотите — проверьте сами . Pzz>> Не хочу.
G>И это правильно. Мешки ворочать — тяжелая физическая работа, недостойная благородного дона. Давайте посмотрим, как с ний справляются другие умудренные жизнью оптимисты, думавшие, что могут обойти кодогенератор IC++. Незнаю как вам — мне было очень весело.
G>http://www.gamedev.ru/forum/?group=2&topic=537&page=6
Презабавнейшее чтиво. Вот, например, один такой оптимист пишет — через пяток попыток обогнать С++. Мы наблюдаем момент просветления, смотрите.
>>А вот поборол ли я Intel Compiler, это мы посмотрим?
>Нет конечно, IntelC победил. 0.160 sec vs. 0.200. К сожалению, очень плохо выравниваются данные в массивe height ( с шагом 257). Это создает пенальти... И я совершенно не представляю, зачем эмулировать двумерные массивы ж-(.
Я конечно понимаю, что производительность кода далеко не в первую очередь зависит от его объема.
Да и особенностей процов слишком много, чтобы одному человеку их все запомнить.
Кстати, от перестановки for(i.. и for(j... результат результат все-таки есть. Я "немного" ошибся. Перестановка (на P-III) дает 5% прироста скорости, если карта высот влазит в кэш, иначе 3-х кратное ускорение??!!!???
НО ПОЧЕМУ INTEL COMPILER сделал более быстрый код. Давай-ка, IronPeter asm+source code, который сгенерировал Intel C. Либо я ничего не понимаю, либо я вообще ничего не понимаю, либо и то и другое, но короче моего asm-кода придумать просто нельзя.
Касательно моей или вашей наивности, уважаемый Pzz — обратите внимание на выделение. Это полезно.
Здравствуйте, Kluev, Вы писали:
C>>>Дело в том, что класс задач по обработке сложных структур данных сам по C>>>себе недостаточно широк.
G>>Дело в том, что во первых, мы отметаем это утверждение как голословное и лишенное смысла из-за общности и неконкретностии, а во вторых — напоминаем, что класс задач, требующий бешеной производительности — сам по себе узок как танковая смотровая щель. И для таких задач, как это ни прискорбно, чаще всего применяется Fortran.
K>Только оказывается что фортарновские библиотеки типа MKL внутри написаны на ассемблере и C.
Фортрановские программы и библиотеки написаны обычно на фортране. Их сохранилось огромное количество с давних времен, плюс — сам фортран как язык дает больше возможностей для агрессивных оптимизаций за счет большей ограниченности, чем С++. Далее — именно фортран являлся и является основным языком для суперкомпьютеров.
K>И кстати вот такой каверзный вопрос. Я не совсем понял, что имеется ввиду под сложными структурами данных? У меня к примеру сейчас основная задача проанализировать несвязанную геометрию (набор поверхностей) и сделать из этого добра замкнутую связанную оболочку. Структуры данных весьма сложные, как ocaml может помочь?
Все просто. Есть три варианта:
1) Берете в руки бубен, и начинаете камлать. При этом надо периодически кричать: О! О! Тут у меня случается просветление, и посредством возникшей между нами ментальной связи я считываю детальную постановку задачи прямо из вашего мозга, пишу программу на OCaml, и пересылаю ее вам.
2) Берете в руки мануал по OCaml или любому другому языку с системой типов Хиндли-Милнера, и разбираетесь, чем именно он может помочь в вашем случае и почему. Я рекомендую Gentle Introduction to Haskell.
3) Можете по крайней мере описать ваши сложные структуры данных и алгоритмы в форуме. Для начала.
Здравствуйте, Pzz, Вы писали:
Pzz>А что, IC++ боги, что ли, писали? Если они смогли написать хороший Pzz>кодогенератор, то и я смогу руками сгенерировать хороший код. Не за 5 Pzz>минут, конечно Вопрос только, зачем?
Писали не боги, но у них есть сведения об архитектуре процессоров, которые вообще говоря NDA и симуляторы процессоров, которые за пределами Intel недоступны.
Если интересуетесь ассемблером, почитайте статью Майкла Абраша в Dr.Dobb's, про то как он писал Pixomatic. Ее нет в свободном доступе, но я процитирую кусочек:
That reminds me of an important lesson we learned while doing Pixomatic: It's almost impossible to know exactly what's going on with the performance of your code nowadays. The out-of-order processing of the Pentium 4 is so complex and the tools available for analyzing performance are so inadequate (alas, VTune has regressed in this respect), that to a large extent all you can do is try a lot of approaches and keep the one that runs fastest.
I mention this in the context of the bilinear filter because that was where that lesson was driven home. You see, I came up with a way to remove a multiply from the filter code—and the filter got slower. Given that multiplication is slower than other MMX instructions, especially in a long dependency chain such as the bilinear filter, and that I had flat-out reduced the instruction count by one multiply, I was completely baffled. In desperation, I contacted Dean Macri at Intel, and he ran processor-level traces on Intel's simulator and sent them to me.
I can't show you those traces, which contain NDA information, but I wish I could because their complexity beautifully illustrates exactly how difficult it is to fully understand the performance of Pentium 4 code under the best of circumstances. Basically, the answer turned out to be that the sequence in which instructions got processed in the reduced multiply case caused a longer critical dependency path—but there's no way you could have known that without having a processor-level simulator, which you can't get unless you work at Intel. Regardless, the simulator wouldn't usually help you anyway because this level of performance is very sensitive to the exact sequence in which instructions are assigned to execution units and executed, and that's highly dependent on the initial state (including caching and memory access) in which the code is entered, which can easily be altered by preceding code and usually varies over time.
Я плохо знаю GCC, но для MSVC могу припомнить довольно много особенностей компилятора, влияющих на производимый код. Грубо говоря, можено что-то записать 2мя способами, в одном из них результат получится гарантированно лучше или хуже. Например, желательно писать const где только возможно, и компилятор скажет спасибо. В своих тестах я ничего не менял, но может быть, кто-то просто при написании оригинального варианта использовал заведомо узкие места GCC? Не будем считать такие действия умышленными, такое возщможно, или же GCC любой код одинаково хорошо компилирует?
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, z00n, Вы писали:
Z>По времени исполнения — небольшую часть, а по времени разработки — бОльшую. Z>Игра это и есть в основном "триггеры" и "картинки", а не то, что называют engine, который да, скорее всего написан на С/С++.
Как-то интересно выкинули основную мысль —
Яркий пример — Civilization IV. Большая часть написана на Питоне и жрет 2Гб памяти.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Люди взяли самый популярный компилятор под Linux, и им было совершненно неинтересно, кто победит в этих тестах. А победил OCaml. Какая реклама получилась! 
Ваша мысль, что кто-то вам что-то рекламирует — ошибка.
.
