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-ти минут.
R>У меня такое ощущение, вы отвечаете не мне, а вашей фрустрации наукой. Ни одно мое сообщение не остается почему-то без вашего внимания. Вы начинаете быть назойливым.
Не преувеличивай, есть масса твоих сообщений, которые я даже не считаю возможным комментировать.
Но вот ты привел ссылку на сравнительный анализ скорости реализаций одной задачи на разных языках. Привел в качестве доказательства того, что C++ -- это не быстрый язык. Я привожу цитату из приведенной тобой ссылки, в которой явно указывается, что самыми быстрыми реализациями были реализации на Scheme и C++.
R>Никто тут про схему не говорил. Кому вообще придет в голову Scheme здесь рассматривать — это динамический язык, а сталин — это игрушка одного человека и некий proof-of-concept. По какому поводу и кому вы здесь возражаете?
Возражаю по поводу:
Он медленный не по сравнению с ассемблером. Он медленный по сравнению с более высокоуровневыми языками, но у которых лучше дизайн и нет всего этого легаси от Си.
Из приведенной тобой ссылки про ray_tracer вообще не видно, чтобы C++ был медленным.
R>Если вы не заметили, вся эта ветка была о другом. R>И никаких проблем со средствами разработки у Окамла нет.
Ok. Я сам не сторонник IDE, но если уж говорить про средства разработки, то покажи, пожалуйста, аналоги для OCaml таких вещей, как Visual Studio, Visual Assist, ReSharper, IDEA?
Есть ли для OCaml средства для работы с РСУБД, с XML, с HTTP, с SOAP, поддержка криптографии? Есть ли, к примеру, аналоги yacc/bison (coco/r, antlr), которые бы генерировали парсеры на OCaml?
Может ли стандартная библиотека OCaml сравниться с .Net Framework или JDK. Или хотя бы с Boost-ом? Или ACE-ом?
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# себе такого не позволяли.
R>Кому это нужно принять во внимание? R>Я рад за них. И за вас. Но здесь обсуждалось не то, сохраняет ли окамл обратную совместимость.
Началось все с того, имеет ли смысл выбрать OCaml вместо C++ (см. C++ vs ???
). А если какой-то язык выбирается для промышленного использования, то обеспечение совместимости с написанным ранее кодом, имеет очень серьезное значение.
R>И кстати в случае с С++ и в случае с его компиляторами далеко не все так гладко. Одна изменение манглинга в gcc 3.0 чего стоило.
Не видел никаких проблем с переносом исходного кода на C++ из gcc 2.95.* в gcc 3 или gcc 4. Так же, как в Visual C++ или с89. Проблемы были только с системно-зависимыми, не стандартными расширениями, вроде __declspec.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
R>>У меня такое ощущение, вы отвечаете не мне, а вашей фрустрации наукой. Ни одно мое сообщение не остается почему-то без вашего внимания. Вы начинаете быть назойливым.
E>Не преувеличивай, есть масса твоих сообщений, которые я даже не считаю возможным комментировать.
Тем не менее, тенденция есть. Никто другой пока что в подобном замечен не был. Так что делайте выводы.
E>Но вот ты привел ссылку на сравнительный анализ скорости реализаций одной задачи на разных языках. Привел в качестве доказательства того, что C++ -- это не быстрый язык. Я привожу цитату из приведенной тобой ссылки, в которой явно указывается, что самыми быстрыми реализациями были реализации на Scheme и C++.
Не нужно вырывать цитаты из контекста — это раз, и не нужно передергивать.
Вопрос был в том, где С++ является медленнее, чем другие языки — я показал. Отметив непосредственно MLTon и O'Caml.
При чем здесь вообще Scheme.
И самое главное — Проблемы с производительностью С++ — это фундаментальные проблемы с его семантикой. Вы, если так гордитесь своим знанием С++, должны их знать и не поднимать вопль каждый раз, когда на них кто-то указывает.
Очень прошу эту тему считать закрытой.
R>>Никто тут про схему не говорил. Кому вообще придет в голову Scheme здесь рассматривать — это динамический язык, а сталин — это игрушка одного человека и некий proof-of-concept. По какому поводу и кому вы здесь возражаете?
E>Возражаю по поводу: E>
E>Он медленный не по сравнению с ассемблером. Он медленный по сравнению с более высокоуровневыми языками, но у которых лучше дизайн и нет всего этого легаси от Си.
А с какой стати вы по этому поводу возражаете?
Или по вашему то, как работает с кучей и стеком окамл и его представление данных по сравнению с С++ не наводят на такую мысль?
И еще куча других деталей поменьше.
Сколько С++ не оптимизируй, всегда будет один и тот же фундаментальный барьер и никуда от этого не денешься.
Устраивая истерики по по этому поводу, вы выставляете себя в странном свете.
E>Из приведенной тобой ссылки про ray_tracer вообще не видно, чтобы C++ был медленным.
Ну посмотрите получше. Желательно не на AMD64 (для которого у окамла и милтона просто нет кодогенератора)
R>>Если вы не заметили, вся эта ветка была о другом. R>>И никаких проблем со средствами разработки у Окамла нет.
E>Ok. Я сам не сторонник IDE, но если уж говорить про средства разработки, то покажи, пожалуйста, аналоги для OCaml таких вещей, как Visual Studio, Visual Assist, ReSharper, IDEA?
Еще раз. Здесь речь _не_о_том_
У него есть. Но я не буду даже называть их. Ищите сами в гугле. Там все в порядке.
E>Есть ли для OCaml средства для работы с РСУБД, с XML, с HTTP, с SOAP, поддержка криптографии? Есть ли, к примеру, аналоги yacc/bison (coco/r, antlr), которые бы генерировали парсеры на OCaml?
Да, есть. Все, что вы назвали в окамле есть. Более чем.
E>Может ли стандартная библиотека OCaml сравниться с .Net Framework или JDK. Или хотя бы с Boost-ом? Или ACE-ом?
Вот это уже просто бешенство. Сходите и посмотрите.
R>>Кому это нужно принять во внимание? R>>Я рад за них. И за вас. Но здесь обсуждалось не то, сохраняет ли окамл обратную совместимость.
E>Началось все с того, имеет ли смысл выбрать OCaml вместо C++ (см. C++ vs ???
). А если какой-то язык выбирается для промышленного использования, то обеспечение совместимости с написанным ранее кодом, имеет очень серьезное значение.
Давайте не будем, ладно?
Идеальную совместимость не обеспечивает никто. Это нормальная и стандартная ситуация. И это хорошо, потому что 100% совместимость в ущерб качеству, это гораздо более губительно для больших и проектов и компаний и всего прочего.
R>>И кстати в случае с С++ и в случае с его компиляторами далеко не все так гладко. Одна изменение манглинга в gcc 3.0 чего стоило.
E>Не видел никаких проблем с переносом исходного кода на C++ из gcc 2.95.* в gcc 3 или gcc 4. Так же, как в Visual C++ или с89. Проблемы были только с системно-зависимыми, не стандартными расширениями, вроде __declspec.
Вы смеетесь видимо.
в gcc 3.0 произошла смена манглинга, это был большой скандал. Слинковать скомпилированный 3.0 модуль с более старым было нельзя.
А я, сейчас, на своем маке постоянно вынужден переключать Gcc 3.3 и 4.0, потому что разные вещи собираются одним и не собираются другим.
А что произошло с Visual Basic при переходе с 6.0 к .NET рассказывать нужно?
Все, для себя я эту тему тоже закрываю, что у вас нет проблем с совместимостью, рассказывайте в детском саду на утреннике.
gear nuke wrote: > > Pzz>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на > Pzz>ассемблерном уровне. > > А не было ли это причиной того, что копмилятор OCaml приводил > рекурсивный вызов к простому циклу?
1. Нет, не сводил
2. GCC тоже умеет превращать хвостовую рекурсию в цикл
Здравствуйте, reductor, Вы писали:
GN>>Вот именно, вопрос в том, _как_сделать_... GN>>на Lisp обработку асинхронных прерываний?
R>Я чего-то не понимаю, видимо. А в чем по-вашему проблема?
Ну, для начала нужно подготовить Interrupt Descriptor Table, запрограммировать APIC, перейти из реального режима в защищённый... Пока даже не затрагиваются вопросы поддержки виртуальной памяти.
R>семантика создает проблемы для как для оптимизирующих компиляторов
Можно небольшой пример?
R>так и для рантайма в виде что работы стека
Не вижу никаких проблем со стеком. Он аппаратно поддерживается процессором.
R>что с кучей
А что с кучей? Её можно совсем не использовать . Можно реализовать _свой_ менеджер. Можно — garbage collector. Ещё, наверное, что-то можно, когда придумают что-то новое.
R>Сложно С++ нормально компилировать.
ИМХО это относится исключительно к коду, написанному левой пяткой. Cкорее всего, это верно для всех языков.
R>Вот и все.
R>Почему вы думаете иначе всякие теоретики все до сих пор на фортране делают.
Да там тьма готового кода, и переучиваться теоретикам не досуг — другие задачи решать надо.
P.S.
Я сам далеко не фанат С++. Просто как-то понял, что есть люди, которые способны реализовать на нём эффективные низкоуровневые операции. Есть те, кто напишет гору шаблонов, что бы симулировать фичи языка XYZ. Кто-то напишет библиотеки на любой вкус. А кто-то способен написать хороший компилятор. Если собрать всё это вместе, получится вполне достойный результат. Причём, собирать можно только то, что нужно для конкретной задачи. Видимо, это и называется "плюсы"
Теперь вижу, есть такой язык OCaml, почти такой же быстрый, как С++, только писать на нём нужно в 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
Здравствуйте, reductor, Вы писали:
R>Знаете, вне зависимости от чего-то еще, никто не мешает переписать тот критический 1% кода, который тормозит хоть на ассемблере, хоть на бейсике. И слинковать вместе с остальным.
С выделенным полностью согласен
Мешает "что":
линковка подразумевает вызов некоторого машинного кода в runtime.
Это довольно дорогая (по времени) операция: нужно передавать параметры через стек/регистры, call и ret далеко не самые быстрые инструкции. Это на поверхности, глубже — нюансы работы кеша, предсказателя переходов и прочая ерунда, о которой программист на ЯВУ не задумывается.
Сами по себе эти задержки не очень полезны в критичных местах и могут быть больше, чем время выполнения полезного кода.
Более того, это сильно мешает whole program optimization.
С++ (а так же, поздний С) не имеет вышеназванных проблем by design.
Другое дело, что проблемы эти иногда не важны.
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
Похоже тесты не очень правильные. Я взял программу ackerman, убрал
оттуда использование стандартной библиотеки С++, использовал PGO для
лучшей оптимизации, и оно стало работать на 20% быстрее в тестах с
небольшим N.
Вероятно в некоторых тестах тут измерялась скорость инициализации
стандартной библиотеки
eao197 wrote:
> Pzz>Вообще говоря, в некоторых случаях тот же Ocaml может обогнать, > Pzz>например, GCC даже на совершенно *простеньких* програмках. > На простеньких программках, да еще в специфических областях, C++ даже > Java обгоняет. Например, на строковых операциях (за счет того, что C++ > код вызывает деструкторы std::string-ов, а Java нет и очищает всю > память при завершении теста).
И даже тут С++ может выиграть, если использовать строки с
custom-аллокатором, который будет чистить память "одним махом".
eao197 wrote: > > Pzz>Вообще говоря, в некоторых случаях тот же Ocaml может обогнать, > Pzz>например, GCC даже на совершенно *простеньких* програмках. > > На простеньких программках, да еще в специфических областях, C++ даже > Java обгоняет. Например, на строковых операциях (за счет того, что C++ > код вызывает деструкторы std::string-ов, а Java нет и очищает всю память > при завершении теста).
Ну кто же этими std::string'ами будет пользоваться там, где скорость
важна?...
> Pzz>Я как-то померил, любопытства ради, скорострельность вычисления ряда > Pzz>Фиббоначи рекурсивным способом на нескольких разных компиляторах. > > Pzz>К моему изумлению, Ocaml обгонял GCC процентов на 20-30. Чего я совсем > Pzz>не ожидал от высокоуровнего языка. > > А какие еще компиляторы участвовали в тестах? > На какой платформе? > Какие результаты?
Я уж всего не помню. Это было так, не тесты, а баловство. Ну, примерно,
Ocaml, C (GCC), Lua, Perl. Кажется, Haskell.
Результаты, в общем-то, вполне предсказуемые. C быстрый, остальные языки
— медленные. Вот Ocaml оказался странным исключением
Здравствуйте, Cyberax, Вы писали:
C>Похоже тесты не очень правильные. Я взял программу ackerman, убрал C>оттуда использование стандартной библиотеки С++, использовал PGO для C>лучшей оптимизации, и оно стало работать на 20% быстрее в тестах с C>небольшим N.
К любым шустрикам можно выкатить массу претензий. Просто этот показателен тем, что:
— в нем участвует большое количество языков и компиляторов;
— он использует актуальные и современные компиляторы.
Т.е. позволяет хоть как-то оценивать производительность современных языков и их современных реализаций.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Не преувеличивай, есть масса твоих сообщений, которые я даже не считаю возможным комментировать.
R>Тем не менее, тенденция есть. Никто другой пока что в подобном замечен не был. Так что делайте выводы.
<offtopic>
Форум окрытый, любой читатель может вмешаться в любую тему. Таковы правила.
И выводы мне делать не зачем. Если я перехожу какие-то нормы этики и правил, то модераторы возвращают все на свои места.
</offtopic>
R>Вопрос был в том, где С++ является медленнее, чем другие языки — я показал. Отметив непосредственно MLTon и O'Caml.
The fastest languages are Stalin-compiled Scheme and C++. OCaml and MLton-compiled SML are slightly slower.
Итак, на вопрос о том, где C++ является медленее, приводится статья, где сказано, что C++ оказался самым быстрым языком.
R>При чем здесь вообще Scheme.
При том, что в указанной тобой статье Scheme был вторым из самых быстрых языков.
R>И самое главное — Проблемы с производительностью С++ — это фундаментальные проблемы с его семантикой. Вы, если так гордитесь своим знанием С++, должны их знать и не поднимать вопль каждый раз, когда на них кто-то указывает.
Вот про проблемы производительности связанные с семантикой хотелось бы услышать подробнее. И если не в виде такого же интересного рассказа про монады, то хотя бы в виде конкретных ссылок (раз уж этот способ тебе наиболее удобен).
Что касается моего знания C++, то я никогда не говорил, что я его знаю очень хорошо. Я говорил, что долго на нем программирую. Т.е. я знаю то, что использую, но использую я далеко не весь спектр возможностей С++. Опять же "13 years of C++ and still learning".
R>>>Никто тут про схему не говорил. Кому вообще придет в голову Scheme здесь рассматривать — это динамический язык, а сталин — это игрушка одного человека и некий proof-of-concept. По какому поводу и кому вы здесь возражаете?
E>>Возражаю по поводу: E>>
E>>Он медленный не по сравнению с ассемблером. Он медленный по сравнению с более высокоуровневыми языками, но у которых лучше дизайн и нет всего этого легаси от Си.
А по поводу того, что если на каких-то тестах C++ проигрывает некоторым экзотическим языкам (типа OCaml или Clean), то это не значит, что он медленный. Максимум, что он медленнее чем OCaml или Clean, но не медленный вообще. Если же еще вспомнить про Java, VB, Smalltalk, Python, Ruby, Perl и пр., то C++ не просто быстрый язык, а очень быстрый язык.
R>>>Если вы не заметили, вся эта ветка была о другом. R>>>И никаких проблем со средствами разработки у Окамла нет.
E>>Ok. Я сам не сторонник IDE, но если уж говорить про средства разработки, то покажи, пожалуйста, аналоги для OCaml таких вещей, как Visual Studio, Visual Assist, ReSharper, IDEA?
R>Еще раз. Здесь речь _не_о_том_ R>У него есть. Но я не буду даже называть их. Ищите сами в гугле. Там все в порядке.
В гугле все в порядке? Не сомневаюсь.
Названия (хотя бы), а лучше точные ссылки, на IDE для OCaml, пожалуйста.
В противном случае утверждение о том, что у OCaml нет проблем со средствами разработки остаются в разряде bla-bla-bla.
<...аналогичный по уровню доказательств фрагмент про библиотеки OCaml пропущен...>
R>Давайте не будем, ладно? R>Идеальную совместимость не обеспечивает никто.
Java?
C#?
Да тот же C++.
R> Это нормальная и стандартная ситуация. И это хорошо, потому что 100% совместимость в ущерб качеству, это гораздо более губительно для больших и проектов и компаний и всего прочего.
Сильно сказано. Даже не знаю, как прокомментировать.
R>>>И кстати в случае с С++ и в случае с его компиляторами далеко не все так гладко. Одна изменение манглинга в gcc 3.0 чего стоило.
E>>Не видел никаких проблем с переносом исходного кода на C++ из gcc 2.95.* в gcc 3 или gcc 4. Так же, как в Visual C++ или с89. Проблемы были только с системно-зависимыми, не стандартными расширениями, вроде __declspec.
R>Вы смеетесь видимо.
Ничуть. Внимательно прочитай мои слова: "с переносом исходного кода на C++". К исходному коду манглинг не имеет никакого отношения.
R>Все, для себя я эту тему тоже закрываю, что у вас нет проблем с совместимостью, рассказывайте в детском саду на утреннике.
Боюсь в детском садике не поймут, раз даже такой специалист, как reductor не понимает.
Приведи, пожалуйста примеры, где исходный код на C++ успешно компилировался на gcc 2.95.*, но не компилировался в gcc 3?
И чтобы проблемы имели отношение именно к языку C++, а не к библиотекам.
Подозреваю, что этот вопрос, как и другие конкретные вопросы от меня и Cyberax-a останется без ответа. Есть у тебя такая привычка -- не отвечать на конкретные вопросы или отделываться ничего не значащими общими фразами.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
reductor wrote:
> И самое главное — Проблемы с производительностью С++ — это > фундаментальные проблемы с его семантикой.
Перечислите их поименно. Я не знаю ни одной фундаментальной проблемы с
производительностью в С++.
> Или по вашему то, как работает с кучей и стеком окамл и его > представление данных по сравнению с С++ не наводят на такую мысль?
Вам уже раз 20 сказали, что в С++ есть не только объекты в куче. Есть
еще автоматические объекты с семантикой value-типов, есть свои
аллокаторы и т.п.
> в gcc 3.0 произошла смена манглинга, это был большой скандал. > Слинковать скомпилированный 3.0 модуль с более старым было нельзя.
И что? Можно было взять исходники и перекомпилировать под новым GCC. В
случае с новым OCaml'ом даже перекомпиляция не поможет.
В качестве backend используется masm, поэтому я смотрел полученный asm листинг.
Все замечания не относятся к качеству трансляции O`Caml -> asm, поскольку я не знаком с языком, сложно делать выводы о оптимальности трансформаций. Буду говорить только касательно качаства самого вывода x86 asm (исключительно субъективная оценка).
На первый взгляд, вывод относительно неплох.
ocamlopt использует передачу параметров не через стек, а в регистрах CPU — более быстрый вариант. Более 2х параметров нигде не передавалось, поэтому непонятно, как будут передаваться дальнейшие. (компиляторы С++ так же позволяют использовать подобную конвенцию или делают тоже самое при whole program optimization)
Используется регистр esp вместо ebp для построения кадров стека — это наиболее быстрый способ, поскольку исключаются лишние команды. Многие старые С++ компиляторы делают наоборот (очевидно, тяжёлое наследие 16 бит). Современные используют аналогичный ocamlopt подход.
Дальнейшее изучение показало, что кадры стека в OCalm совсем не нужны.
Используются вызовы подобные косвенным в С++ через VTable. Кое что из этого настраивается в runtime
Оптимизатор ничего не знает об архитектуре x86, вывод похож на нечто после кросплатформенного кодогенератора. Из всех возможных оптимизаций увидел только использование lea для сложения сразу 2х чисел (будут ли использоваться для умножения на некоторые константы — не ясно).
Никак не учитывается возможность параллельного выполнения.
Нет никакого выравнивания меток для переходов. Это плохо, проблемы с конвеером.
Не используются "новые" команды. Сейчас довольно странно расчитывать на 486 и терять в скорости.
Это первый кусок ассемблера, который вывел ocamlopt:
1. Совершенно не нужное выделение памяти в стеке. (часто встречается)
2. Таким образом сравнивается double с нулём. Сейчас уже есть быстрые команды вроде ficomm.
Очень странно, что подобную небольшую функцию компилятор не заинлайнил.
Оказывается, далее делается так:
mov DWORD PTR [edx],OFFSET _camlRay__fun_209
и вызов происходит косвенно
Ещё несколько пёрлов.
Это всё делается одной командой:
and ah, 69
dec ah
cmp ah, 64
встречается часто.
Многократная загрузка одного и того же значения из памяти:
Подобных последнему мест довольно много — видимо компилятор использует простые шаблоны и не пытается делать какие-то оптимизации.
Напоследок, заключительный кусок ассемблера:
L196:
mov eax, 1
mov eax, 1
add esp, 40
ret
Как в старом анекдоте:
-- ты зачем 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
Поэтому провёл сравнение сам.
Использованы исходники отсюда
С++ компилировался так:
cl ray.cpp /Ox /EHsc /Gr /GS- /GL
получен исполняемый файл размером 139264 байта.
OCaml компилировался так:
ocamlopt -inline 100 ray.ml -o ray
получен исполняемый файл размером 278528 байт.
Размеры файлов в общем-то мало зависят от полезного кода, больше — от runtime библиотек.
Измерения проводились при помощи отладчика (режима ядра, поэтому влияние на системную кучу отсутствует) Soft ICE. Каждая программа запускалась 3 раза так:
ray > out.txt
Измерялось время исполнения кода от точки входа в главную функцию и до точки выхода из неё.
Время инициализации runtime библиотек в полученные цифры не входит.
Тестовая машина:
Athlon XP2000+ (1666MHz) 512Mb DDR (266MHz) XP SP2.
Вне конкурса проходит тот же MSVC с ключиком /clr
Замеры выполнялись "на глаз" — запускался экзешник и секунды смотрелись по часам Windows, пока не закроется окно консоли.
В этом случае неизвестно что измерялось, и точность сомнительна, но результаты интересны.
Время выполнения ~ 28-29 сек.
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>Вне конкурса проходит тот же MSVC с ключиком /clr GN>Замеры выполнялись "на глаз" — запускался экзешник и секунды смотрелись по часам Windows, пока не закроется окно консоли. GN>В этом случае неизвестно что измерялось, и точность сомнительна, но результаты интересны. GN>Время выполнения ~ 28-29 сек.
Да, забыл написать — исполняемый файл 61440 байт (не считая NET FW 2.0)
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
А теперь слегка подправим программу на С++. Вместо порнографии с
самопальным вектором используем Blitz++ (попутно исправив пару ошибок).
Еще добавил версию функции unitise, не создающей лишних временных
переменных. Текст лежит здесь: http://scb.udsu.ru/~cyberax/ray.cpp
Результаты:
cyberax@scblinux:~/tests$ time ./ray >img.pgm
real 0m52.500s
user 0m52.023s
sys 0m0.072s
cyberax@scblinux:~/tests$ time ./ray2 > img2.pgm
real 0m39.509s
user 0m39.326s
sys 0m0.024s
Имеем улучшение в 25%, компилировалось: "gcc -O3 -ffast-math
-fomit-frame-pointer ray.cpp"
Для сравнения, на этой же машине:
cyberax@scblinux:~/tests$ ocamlopt -inline 100 -ffast-math ray.ml -o ray
cyberax@scblinux:~/tests$ time ./ray > img.pgm
Здравствуйте, Cyberax, Вы писали:
C>А теперь слегка подправим программу на С++. Вместо порнографии с C>самопальным вектором используем Blitz++ (попутно исправив пару ошибок). C>Еще добавил версию функции unitise, не создающей лишних временных C>переменных. Текст лежит здесь: http://scb.udsu.ru/~cyberax/ray.cpp
C>Результаты: C>
C>cyberax@scblinux:~/tests$ time ./ray >img.pgm
C>real 0m52.500s
C>user 0m52.023s
C>sys 0m0.072s
C>cyberax@scblinux:~/tests$ time ./ray2 > img2.pgm
C>real 0m39.509s
C>user 0m39.326s
C>sys 0m0.024s
C>Имеем улучшение в 25%, компилировалось: "gcc -O3 -ffast-math C>-fomit-frame-pointer ray.cpp"
А может ли быть такое, что в изначальных теста С++ вариант делался для получения "ожидаемых" результатов? Меня всегда смущала разница в измерениях в 5%
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>А может ли быть такое, что в изначальных теста С++ вариант делался для получения "ожидаемых" результатов? Меня всегда смущала разница в измерениях в 5%
Мда, господа
с удовольствием бы с вами поиграл в этой песочнице и показал что произойдет на PowerPC и после того, как окамлу заменить вектор на CamlG4 например или что-нибудбь еще такое, но как-то не увлекает, знаете ли...
Давайте лучше сразу прямо здесь запишем, что С++ это самый быстрый, разумный, добрый и вечный язык.
А то спам в ящике надоел.
reductor wrote:
> с удовольствием бы с вами поиграл в этой песочнице и показал что > произойдет на PowerPC и после того, как окамлу заменить вектор на > CamlG4 например или что-нибудбь еще такое, но как-то не увлекает, > знаете ли...
А мне ничего менять не надо — Blitz++ поддерживает векторные процессоры.
Для этого надо просто поставить соответствующую реализацию.
> Давайте лучше сразу прямо здесь запишем, что С++ это самый быстрый, > разумный, добрый и вечный язык. > А то спам в ящике надоел.
Ну так отвечайте по существу. А то тут спамом многие считают ваши сообщения.
Здравствуйте, Cyberax, Вы писали:
>> с удовольствием бы с вами поиграл в этой песочнице и показал что >> произойдет на PowerPC и после того, как окамлу заменить вектор на >> CamlG4 например или что-нибудбь еще такое, но как-то не увлекает, >> знаете ли...
C>А мне ничего менять не надо — Blitz++ поддерживает векторные процессоры. C>Для этого надо просто поставить соответствующую реализацию.
Вы к окамлу тоже прикручивали векторную библиотеку?
Не забыли, перед тем как тестировать?
Ах да, я забыл. вы не знаете окамл. Вам сложно.
>> Давайте лучше сразу прямо здесь запишем, что С++ это самый быстрый, >> разумный, добрый и вечный язык. >> А то спам в ящике надоел.
C>Ну так отвечайте по существу. А то тут спамом многие считают ваши сообщения.
На что же я вам должен отвечать?
И если можно поименно этих многих.
. Можно реализовать _свой_ менеджер. Можно — garbage collector. Ещё, наверное, что-то можно, когда придумают что-то новое.
