reductor wrote: > > J>"Все очень просто. Что на С++ или на ассемблере _можно_ обогнать > O'Caml, я не спорю. Вопрос чего это будет стоить." > J>Хочу услышать: конкретный пример где это будет стоить дорого. > > Во всех случаях, когда количество строк на высокоуровневом языке в > системе переваливает за сотню.
Вообще говоря, в некоторых случаях тот же Ocaml может обогнать,
например, GCC даже на совершенно простеньких програмках.
Я как-то померил, любопытства ради, скорострельность вычисления ряда
Фиббоначи рекурсивным способом на нескольких разных компиляторах.
К моему изумлению, Ocaml обгонял GCC процентов на 20-30. Чего я совсем
не ожидал от высокоуровнего языка.
Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на
ассемблерном уровне.
Здравствуйте, Pzz, Вы писали:
Pzz>К моему изумлению, Ocaml обгонял GCC процентов на 20-30. Чего я совсем Pzz>не ожидал от высокоуровнего языка.
Pzz>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на Pzz>ассемблерном уровне.
И не только вызов функции.
Что особо примечательно, компилятор у окамла почти не оптимизирует ничего, он простой как три рубля.
Если бы еще и оптимизировал...
reductor wrote: > > Pzz>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на > Pzz>ассемблерном уровне. > > И не только вызов функции. > Что особо примечательно, компилятор у окамла почти не оптимизирует > ничего, он простой как три рубля. > Если бы еще и оптимизировал...
Да, мне тоже так показалось моим дилетантским взглядом
Кодогенератор не замысловатый, но аккуратно написан. В том смысле, что
не делает плохо то, что несложно сделать хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>reductor wrote: >> >> Pzz>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на >> Pzz>ассемблерном уровне. >> >> И не только вызов функции. >> Что особо примечательно, компилятор у окамла почти не оптимизирует >> ничего, он простой как три рубля. >> Если бы еще и оптимизировал...
Pzz>Да, мне тоже так показалось моим дилетантским взглядом
Pzz>Кодогенератор не замысловатый, но аккуратно написан. В том смысле, что Pzz>не делает плохо то, что несложно сделать хорошо.
Да. Вообще, если эта тема интересна, могу порекомендовать почитать историю создания камла в "The Zinc Experiment".
А так же ужасающее описание того как GHC компилирует через Си и GCC и что такое Evil Mangler.
Лично у меня в свое время это все чакры открыло.
Здравствуйте, zip_, Вы писали:
_>>>Haskell мне не кажется практичным и готовым к применению в промышленных проектах. Считаю, что это до сих пор академический язык.
R>>Интересно по каким критериям На самом деле уже довольно давно нет. То есть язык сам вообще очень давно, а тот же GHC какое-то время. R>>Его сейчас двигают как раз в массы. Но правда стоит отметить, что по вылизанности GHC от окамла пока отстает.
_>Нет компилятора для ARM,
Ну, тут 3 момента.
1. Не особая проблема получить тот же GHC под ARM, т.к он умеет компилить через GCC (правда потом сам манглит ассемблер на выходе, так что тут есть место для геморроя). Еще они сейчас бэкенд переносят на С-- (Один из разработчиков С-- одновременно является разработчиком GHC)
2. есть два компилятора, которые, видимо, это могут без проблем, но пока не для широкого потребления. yhc: http://www-users.cs.york.ac.uk/~ndm/yhc/ — это байткод-компилятор + рантайм на Си. jhc: http://repetae.net/john/computer/jhc/ — компилит все в Си. Обещает быть еще и суперпроизводительным. Там вообще очень много интересных решений (например, region inference вместо GC).
3. Есть hugs который работает на ARM: http://www.haskell.org/hugs/
_>существующие компиляторы генерируют недостаточно качественный код (нет доверия инструменту).
Не уверен, что понял что имеется в виду. Если тяжелый рантайм у GHC, то, наверное да. Или то, что сложно стабилизировать Си-бекенд, потому что gcc вечно меняет свой подход. Но вообще там бэкенд скоро переделают, да — я там выше написал.
_>Плюс еще ленивость сильно затрудняет отладку и делает поведение программы недетерминированным.
Под хаскель не нужна такая отладка как под С++ %) Просто потому, что там не получится натворить столько дел, большинство ошибок отловится еще при компиляции. Ну и поставить вывод логов в ключевых местах проблемы не составляет.
Про то, что поведение программы недетерминировано — это, конечно, совсем не так Кому бы тогда нужен был язык, который неизвестно что делает. Нет, конечно предсказуемость программы на хаскеле гораздо выше, чем у какого-либо еще языка. Просто недетерминирован порядок вычислений, но это, согласно теореме Черча-Россера и неважно
Здравствуйте, reductor, Вы писали:
R>Самый простейший пример из возможных: http://www.ffconsultancy.com/free/ray_tracer/languages.html R>Пожалуйста, не стоит здесь и сейчас начинать флейм по этому поводу и рассказывать, что вы сможете оптимизировать код на С++ или на чем угодно, чтобы он обгонял MLTon или O'Caml R>Я сам это могу сделать. Правда за время в несколько раз превышающее то, которое ушло бы на то же самое в случае окамла.
Надеюсь, вопрос не будет воспринят как флейм
Возможно ли (в принципе) заоптимизировать код на MLTon или O'Caml до такой степени, что бы _практически_ было раелизовано что-то вроде этого:
(это довольно старый движёк. думаю, не лучший)
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
Здравствуйте, reductor, Вы писали:
R>Давайте так, Haskell — это не совсем тот язык, который стоит здесь рассматривать на тему эффективности. В его случае это не тема, а просто пропасть какая-то.
Признаю свою ошибку — выбрал первое, что попалось под руку, поскольку не понятно, о чём именно шла речь.
R>Просто чтобы догнать тот код, Который генерят некоторые компиляторы на ассемблере, придется потратить во много раз (даже, наверное, десятков раз) больше времени, чем на том языке который они компилируют. R>Все очень просто. Что на С++ или на ассемблере _можно_ обогнать O'Caml, я не спорю. Вопрос чего это будет стоить.
Так, мне похоже становится ясно, что мы говорим о разных вещах. Вы говорите о трудозатратах программиста на написание эффективного кода. С этим полностью согласен, поскольку очевидно, что пока Вася Пупкин будет писать что-то на ассемблере, Петя Иванов успеет потратить деньги, которые он получил за готовый проект на другом языке.
GN>>В самом деле? Давайте возьмём распространённую архитектуру — PC. Как там на Lisp будет выглядеть общение с железом?
R>Как сделать, так и будет.
Вот именно, вопрос в том, _как_сделать_...
на Lisp обработку асинхронных прерываний?
R>Не бывает универсальных языков.
Это в Священные Войны...
R>И С++ не такой быстрый.
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
Здравствуйте, Pzz, Вы писали:
Pzz>Я как-то померил, любопытства ради, скорострельность вычисления ряда Pzz>Фиббоначи рекурсивным способом на нескольких разных компиляторах.
Pzz>К моему изумлению, Ocaml обгонял GCC процентов на 20-30. Чего я совсем Pzz>не ожидал от высокоуровнего языка.
Pzz>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на Pzz>ассемблерном уровне.
А не было ли это причиной того, что копмилятор OCaml приводил рекурсивный вызов к простому циклу?
Даже если в случае с OCaml это было не так, то это всё равно может быть примером почему С++ способен проиграть. Существующие компиляторы плохо умеют оптимизировать такое. Можно, конечно, руками всё делать и выигрывать — ценой читабельности. Вполне разумно, что в языках, где рекурсия одна из основных фич компилятор должен уметь делать такое хорошо.
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
Здравствуйте, reductor,
J>>"Он медленный не по сравнению с ассемблером. Он медленный по сравнению с более высокоуровневыми языками, но у которых лучше дизайн и нет всего этого легаси от Си." J>>Хочу услышать: примеры, пожалуйста.
R>Я уже приводил. Вся эта ветка этому посвящена. R>Но, если вы еще раз хотите, то пожалуйста: R>Standard ML, O'Caml, Cyclone
ИМХО jedi имел ввиду примеры каких-то задач, решая которые на С++ мы получим более медленный исполняемый файл, чем на перечисленных языках (время на разработку примем как не важный критерий, поскольку мы оцениваем именно возможность написания быстрого кода)
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
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще говоря, в некоторых случаях тот же Ocaml может обогнать, Pzz>например, GCC даже на совершенно простеньких програмках.
На простеньких программках, да еще в специфических областях, C++ даже Java обгоняет. Например, на строковых операциях (за счет того, что C++ код вызывает деструкторы std::string-ов, а Java нет и очищает всю память при завершении теста).
Pzz>Я как-то померил, любопытства ради, скорострельность вычисления ряда Pzz>Фиббоначи рекурсивным способом на нескольких разных компиляторах.
Pzz>К моему изумлению, Ocaml обгонял GCC процентов на 20-30. Чего я совсем Pzz>не ожидал от высокоуровнего языка.
А какие еще компиляторы участвовали в тестах?
На какой платформе?
Какие результаты?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jedi, Вы писали:
J>Вот только конкретики в ваших опусах маловато, все больше какие-то общие фразы. Вам есть что сказать по делу? В конце концов здесь J>не религиозный форум, а форум программистов, да и вы претендуете на научный подход. Потрудитесь обосновывать ваши J>утверждения в таком случае. Иначе это флуд.
Очень похоже на то.
Похоже, reductor под медленностью C++ понимает сравнение с OCaml (за которым закрепилась репутация одного из самых быстрых языков вообще).
Но реальных данных не приводит. Придется сделать это за него:
В общем, есть языки, которые на этих тестах выигрывают у GNU C++ и Intel C++ (OCaml и Clean в первую очередь). Но обзывать C++ медленным языком я бы поостерегся.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
R>Еще они сейчас бэкенд переносят на С-- (Один из разработчиков С-- одновременно является разработчиком GHC)
Не подскажете ссылочку на такой С-- ? Все компиляторы, которые мне попадались или умерли в прошлом веке, или :-(
google что-то совсем не понимает C%2d%2d
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
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, reductor, Вы писали:
R>>Самый простейший пример из возможных: http://www.ffconsultancy.com/free/ray_tracer/languages.html R>>Пожалуйста, не стоит здесь и сейчас начинать флейм по этому поводу и рассказывать, что вы сможете оптимизировать код на С++ или на чем угодно, чтобы он обгонял MLTon или O'Caml R>>Я сам это могу сделать. Правда за время в несколько раз превышающее то, которое ушло бы на то же самое в случае окамла.
GN>Надеюсь, вопрос не будет воспринят как флейм GN>Возможно ли (в принципе) заоптимизировать код на MLTon или O'Caml до такой степени, что бы _практически_ было раелизовано что-то вроде этого: GN> GN>(это довольно старый движёк. думаю, не лучший)
По ссылке видно, что O'Caml и особенно MLTon и так быстрее С++ в таких задачах
Так что в чем проблема, непонятно.
Или я как-то не так понял вопрос?
Здравствуйте, gear nuke, Вы писали:
R>>Еще они сейчас бэкенд переносят на С-- (Один из разработчиков С-- одновременно является разработчиком GHC)
GN>Не подскажете ссылочку на такой С-- ? Все компиляторы, которые мне попадались или умерли в прошлом веке, или :-( GN>google что-то совсем не понимает C%2d%2d
GN>Вот именно, вопрос в том, _как_сделать_... GN>на Lisp обработку асинхронных прерываний?
Я чего-то не понимаю, видимо. А в чем по-вашему проблема?
Особенно, если сделать специальный DSL внутри лиспа (для чего лисп в общем и предназначен — создание domain-specific языков) специально для работы с железом.
И маленький транслятор, который все это приведет в нужную форму.
R>>И С++ не такой быстрый.
GN>2й раз вижу эту фразу без обоснования. Если это относитсяя к возможности написания кода, эффективность которого будет мало отличаться от вручную написанного на ассемблере, то это неверно. На С++ можно такой код писать. Для этого достаточно знание асма и несколько часов/дней на изучение основ языка. Вот что бы на нём писать эффективный высокоуровневый код — нужно потратить уже насколько месяцев/лет. Понятное дело, что будут языки у которых порог вхождения значительно ниже.
Ну а что вы хотите услышать. Что его семантика создает проблемы для как для оптимизирующих компиляторов, так и для рантайма в виде что работы стека, что с кучей?
Сложно С++ нормально компилировать. Вот и все.
Почему вы думаете иначе всякие теоретики все до сих пор на фортране делают.
Pzz>>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на Pzz>>ассемблерном уровне.
GN>А не было ли это причиной того, что копмилятор OCaml приводил рекурсивный вызов к простому циклу?
GN>Даже если в случае с OCaml это было не так, то это всё равно может быть примером почему С++ способен проиграть. Существующие компиляторы плохо умеют оптимизировать такое. Можно, конечно, руками всё делать и выигрывать — ценой читабельности. Вполне разумно, что в языках, где рекурсия одна из основных фич компилятор должен уметь делать такое хорошо.
Да даже gcc умеет разворачивать хвостовую рекурсию — это простейшая совершенно оптимизация. Дело не в этом.
Просто откомпилируйте что-нибудь простое на окамле и си++ — увидите в чем разница
Здравствуйте, reductor,
GN>>Возможно ли (в принципе) заоптимизировать код на MLTon или O'Caml до такой степени, что бы _практически_ было раелизовано что-то вроде этого: GN>> GN>>(это довольно старый движёк. думаю, не лучший)
R>По ссылке видно, что O'Caml и особенно MLTon и так быстрее С++ в таких задачах
On a 1.2GHz Athlon Thunderbird Linux box, the two programs can be compiled with (g++ 4.0.1 and ocamlopt 3.08.3)
OCaml is 7% faster than C++.
On a 1.6GHz Athlon 64 (running pure64 Debian Linux), the two programs can be compiled with (g++ 4.0.1 and ocamlopt 3.08.3)
OCaml is 5% slower than C++.
С++ — синий. OCaml — красный.
Прошу обратить внимание на первый график — он заканчивается как раз в том месте, где С++ начинает выигрывать
R>Так что в чем проблема, непонятно. R>Или я как-то не так понял вопрос?
Видимо. Автор движка virtualray утверждает, что там применяется тщательная низкоуровневая оптимизация — именно по этой причине, в игрушку вообще можно играть, а не смотреть слайд-шоу.
Вопрос такой — можно ли произвести оптимизацию подобного уровня на языках, которые "и так быстрее С++ в таких задачах"
R>P.S. R>Quake3-подобный движок на haskell, написанный одним(!!) человеком: http://www.haskell.org/hawiki/Frag
Это совершенно не то. В "Разработка игр" неоднократно обсуждалось использование NET и другого (вместо С++) для написания подобных проектов. Это вполне оправданно, так как программирование в данном случае сводится к вызовам некоторого API, которое всё рисует в конечном счёте аппаратно.
Ray tracing подразумевает, что рендеринг выполняется программно.
Кстати, по поводу 2х восклицательных знаков. Знакомый сейчас пишет on-line RPG на С++ (ИМХО сложность выше). Один (не считая художников и т.п.). Почему был выбран этот язык? Стоимость разработки — скоро состоится запуск сервера, и когда он увидит узкие места (а в этом списке 100% появятся менеджер кучи и STL строчки), будет очень просто найти людей, которые смогут эти узкие места подрихтовать.
R>P.P.S R>Я никогда не занимался программированием 3D, как не занимаюсь им и сейчас. Так что конкретные вопросы по имплементации задавать лучше не мне.
Мой вопрос не касается вопросов имплементации. Он касается возможности использовать низкоуровневые оптимизации в HLL.
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
The fastest languages are Stalin-compiled Scheme and C++. OCaml and MLton-compiled SML are slightly slower.
Да, конечно, сразу можно делать вывод о том, что C++ медленный язык. При том, что время компиляции C++ программы составило 0.75s, а время компиляции Stalin Scheme -- 680s (!), т.е. больше 11-ти минут.
Еще интересный момент:
two of the best optimising compilers, Stalin and MLton, are both whole-program optimising compilers, meaning they can only compile whole (self-contained) programs
если Stalin Scheme компилировал конкретно эту программу 11-ть минут, то что делать с ним в реальных проектах объемом больше 200 тысяч строк? При условии, что компилировать нужно сразу всю программу.
Напротив, про C++ и OCaml сказано:
The C++ and OCaml compilers allow partial recompilation, compile this whole program much more quickly and still achieve very competitive performance.
Что называется, почувствуйте разницу.
В общем, возвращаясь к первоначальному вопросу о выборе языка вместо C++, OCaml выглядит совсем не плохо.
На практике, однако, кроме его скоросных характеристик важную роль еще будут иметь средства разработки, библиотеки, документация и пр. И не факт, что здесь OCaml сможет выигрывать у C++, не говоря уже про Java или .Net/Mono.
А еще нужно принять во внимание:
Unlike SML, the OCaml language is not standardised and continues to evolve. The evolution of OCaml has allowed it to adopt many new programming constructs not found in SML, including polymorphic variants and objects. However, the evolution of the OCaml language sometimes renders old code uncompilable or, worse, different in terms of performance or even correctness.
для языка для промышленного применения такое пренебрежение совместимостью с ранее написанным кодом может стать фатальным, имхо. Ни C++, ни Java, ни C# себе такого не позволяли.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, reductor,
GN>>>Возможно ли (в принципе) заоптимизировать код на MLTon или O'Caml до такой степени, что бы _практически_ было раелизовано что-то вроде этого: GN>>>(это довольно старый движёк. думаю, не лучший)
R>>По ссылке видно, что O'Caml и особенно MLTon и так быстрее С++ в таких задачах
GN>С++ — синий. OCaml — красный. GN>Прошу обратить внимание на первый график — он заканчивается как раз в том месте, где С++ начинает выигрывать
Да что у окамла, что у милтона проблемы с AMD64 кодом. Надеюсь, скоро будут решены.
R>>Так что в чем проблема, непонятно. R>>Или я как-то не так понял вопрос?
GN>Видимо. Автор движка virtualray утверждает, что там применяется тщательная низкоуровневая оптимизация — именно по этой причине, в игрушку вообще можно играть, а не смотреть слайд-шоу. GN>Вопрос такой — можно ли произвести оптимизацию подобного уровня на языках, которые "и так быстрее С++ в таких задачах"
Знаете, вне зависимости от чего-то еще, никто не мешает переписать тот критический 1% кода, который тормозит хоть на ассемблере, хоть на бейсике. И слинковать вместе с остальным.
R>>P.S. R>>Quake3-подобный движок на haskell, написанный одним(!!) человеком: http://www.haskell.org/hawiki/Frag
GN>Это совершенно не то. В "Разработка игр" неоднократно обсуждалось использование NET и другого (вместо С++) для написания подобных проектов. Это вполне оправданно, так как программирование в данном случае сводится к вызовам некоторого API, которое всё рисует в конечном счёте аппаратно.
GN>Ray tracing подразумевает, что рендеринг выполняется программно.
Да я уже понял. Но программно мы имеем то, что имеем. Окамл и SML очень быстрые на большинстве архитектур.
Не знаю правда что там с теми же векторными операциями — не скажу. Но думаю, не проблема, опять же, подвязать их. Все времени уйдет меньше, чем.
GN>Кстати, по поводу 2х восклицательных знаков. Знакомый сейчас пишет on-line RPG на С++ (ИМХО сложность выше). Один (не считая художников и т.п.). Почему был выбран этот язык? Стоимость разработки — скоро состоится запуск сервера, и когда он увидит узкие места (а в этом списке 100% появятся менеджер кучи и STL строчки), будет очень просто найти людей, которые смогут эти узкие места подрихтовать.
Я не думаю, что у людей, достаточно профессиональных, чтобы заниматься такими вещами, были проблемы с окамлом тем же.
А где выше сложность квейк или онлайн рпг, я судить не возьмусь. Я и не пишу игры и не играю в них, так что я пас
GN>Мой вопрос не касается вопросов имплементации. Он касается возможности использовать низкоуровневые оптимизации в HLL.
E>The fastest languages are Stalin-compiled Scheme and C++. OCaml and MLton-compiled SML are slightly slower.
E>Да, конечно, сразу можно делать вывод о том, что C++ медленный язык. При том, что время компиляции C++ программы составило 0.75s, а время компиляции Stalin Scheme -- 680s (!), т.е. больше 11-ти минут.
У меня такое ощущение, вы отвечаете не мне, а вашей фрустрации наукой. Ни одно мое сообщение не остается почему-то без вашего внимания. Вы начинаете быть назойливым.
Никто тут про схему не говорил. Кому вообще придет в голову Scheme здесь рассматривать — это динамический язык, а сталин — это игрушка одного человека и некий proof-of-concept. По какому поводу и кому вы здесь возражаете?
E>Напротив, про C++ и OCaml сказано: E>
E>The C++ and OCaml compilers allow partial recompilation, compile this whole program much more quickly and still achieve very competitive performance.
E>Что называется, почувствуйте разницу.
Вы здесь боретесь с ветряными мельницами.
Хотите рассказать мне какой окамл хороший, а я — теоретик, оторванный от жизни?
E>В общем, возвращаясь к первоначальному вопросу о выборе языка вместо C++, OCaml выглядит совсем не плохо. E>На практике, однако, кроме его скоросных характеристик важную роль еще будут иметь средства разработки, библиотеки, документация и пр. И не факт, что здесь OCaml сможет выигрывать у C++, не говоря уже про Java или .Net/Mono.
Если вы не заметили, вся эта ветка была о другом.
И никаких проблем со средствами разработки у Окамла нет.
E>А еще нужно принять во внимание: E>
E>Unlike SML, the OCaml language is not standardised and continues to evolve. The evolution of OCaml has allowed it to adopt many new programming constructs not found in SML, including polymorphic variants and objects. However, the evolution of the OCaml language sometimes renders old code uncompilable or, worse, different in terms of performance or even correctness.
E>для языка для промышленного применения такое пренебрежение совместимостью с ранее написанным кодом может стать фатальным, имхо. Ни C++, ни Java, ни C# себе такого не позволяли.
Кому это нужно принять во внимание?
Я рад за них. И за вас. Но здесь обсуждалось не то, сохраняет ли окамл обратную совместимость.
И кстати в случае с С++ и в случае с его компиляторами далеко не все так гладко. Одна изменение манглинга в gcc 3.0 чего стоило.
Бессодержательность ваших ответов меня начинает пугать.
:-(
