Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, bkat, Вы писали:

B>>Но больше всего меня поразило то, что когда в своем тесте я убрал строчку,
B>>которая ставит пиксель нужного цвета на экран, то тест стал выполняться мгновенно.
B>>Т.е. Intel compiler грубо говоря "догадался",
B>>что можно "безболезненно" удалить кусок кода, формирующий фрактал и никуда его не выводящий

VD>Это вроде делают все оптимизаторы. Удаление неработающего кода.

Там было немного сложнее чем обычно.
Он соптимизировал несколько функций...
Оптимизатор от MS не смог в этой же ситуации распознать "неработающий" код.

Здравствуйте, bkat, Вы писали:

B>Там было немного сложнее чем обычно.
B>Он соптимизировал несколько функций...
B>Оптимизатор от MS не смог в этой же ситуации распознать "неработающий" код.

А -Ob2 было включено? Ошибкой многих кто сравнивает компилятор MS и Intel является, то что они не включают в MS опцию автоматической инлайн-подстановки. А это Intel C++ ее автоматом включает. В моих тестах после включении Ob2 в VC7/7.1 на целочисленных вычислениях скорость была не хуже (а порой и лучше) чем у Intel-а.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, bkat, Вы писали:

B>>Там было немного сложнее чем обычно.
B>>Он соптимизировал несколько функций...
B>>Оптимизатор от MS не смог в этой же ситуации распознать "неработающий" код.

VD>А -Ob2 было включено? Ошибкой многих кто сравнивает компилятор MS и Intel является, то что они не включают в MS опцию автоматической инлайн-подстановки. А это Intel C++ ее автоматом включает. В моих тестах после включении Ob2 в VC7/7.1 на целочисленных вычислениях скорость была не хуже (а порой и лучше) чем у Intel-а.

Да, это было сделано.
Мой "эксперимент", на самом деле состоял из 3-х разных тестов.
Нужно было построить фрактал, используя:
— double вычисления,
— GPP
— собственный класс, инкапсулирующий GPP.
Из GPP использовались только арифметика над числами с фиксированной точкой.
Точных результатов у меня сейчас под рукой нет, но результаты были примерно следующими.
Для MS компилятора потребовалось около 50 сек для 1-го теста, меньше 2 сек — для 2-го и 3-го тестов.
В случае с компилятором от Intel потребовалось менее 13 сек для double вычислений,
и те же самые 2 сек в других случаях.

Если исключить инлайн-подстановки, то в случае с MS
1-й и 2-й тесты показали такой же результат как и раньше,
а вот 3-й тест потребовал около 9 сек.
Intel, с отключенной инлайн-подстановкой потребовал около 11 сек на 3-й тест.

Повторюсь, все это было сделано на системе c PXA255 и WinCE.NET 4.1.
Т.е. Intel compiler для Xscale очевидно пораждает лучший код,
но сам компилятор, к сожалению имеет кучу проблем.
Но это уже другая история...

Собственно, сабж.

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

Поэтому надо было равнять Arrays.sort (Java) с std::sort (C++), хотя это и смешно.

Здравствуйте, dextery, Вы писали:

D>Никто не пишет сортировок вручную.

Месье имеет мандат говорить от имени всех?

D> Реализации строк, векторов, иных коллекций и алгоритмов давно написаны и просто обязаны использоваться любым серьезным программистом, не желающим терять свое (не побоюсь слова, драгоценное) время.

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

D>Поэтому надо было равнять Arrays.sort (Java) с std::sort (C++), хотя это и смешно.

Задачей статьи было сравнение по нескольким критериям различных (и серьезно-разлиных) средств разработки/компиляторов. Тест сортировки призван был показать качество генерации кода и оптимальность рабты с большими объемами памяти. Именно для этого алгоритм обязан был быть идентичным во всех языках.

Лирика: Встроенные функции таких языков как Ява или дотнета оптимизированы для встроенных (и не только) типов данных путем банальной реализации алгоритмов на С++, так что такой тест вылился бы в соревнование С++-программистов — писателей стандартных библиотек. К тому же тот же std::sort различается как небо и земля в разных реализациях STL. Ведь хотя поклонники С++ и утверждают, что STL — это стандарт, но на практике стандартом является только интерфейс (кстати тоже редко соблюдаемый на 100%), а реализации отданы на откуп разработчикам. Причем никто не заставляет не только пользоваться библиотекой идущей в поставке компилятора, но и вообще пользоваться STL. А по числу применений скорее всего в С++ на сегодня будет победителем вообще qsort .

VD>Месье имеет мандат говорить от имени всех?
Нет, за всех не распишусь. Есть же люди, которые за рулем кофе пьют и лифтах сексом занимаются.

VD>В первую очередь нужно беречь драгоценное время пользователей. А оно как раз и зависит от качества применяемых алгоритмов. И в том же С++ очень часто прибегают к ручной реализации тех или иных алгоритмов.
Если программист начнет тратить время на сортировку и переписывание контейнеров, то у него останется намного меньше времени на собственно его алгоритмы. К тому же, в Java применяется сортировка Bentley-McIlroy, являющаяся на сегодняшний день самой быстрой, приемлимой по скорости даже на вырожденных массивах.

VD>Задачей статьи было сравнение по нескольким критериям различных (и серьезно-разлиных) средств разработки/компиляторов. Тест сортировки призван был показать качество генерации кода и оптимальность рабты с большими объемами памяти. Именно для этого алгоритм обязан был быть идентичным во всех языках.
Было такое наблюдение, проведенное специалистами Apple — 80% времени программы проводили внутри стандартной библиотеки. А сравнивать по памяти языки со встроенной поддержкой GC и без нее попросту глупо. Равно как и вызовы методов без оптимизаций.

VD>Лирика: Встроенные функции таких языков как Ява или дотнета оптимизированы для встроенных (и не только) типов данных путем банальной реализации алгоритмов на С++, так что такой тест вылился бы в соревнование С++-программистов — писателей стандартных библиотек. К тому же тот же std::sort различается как небо и земля в разных реализациях STL. Ведь хотя поклонники С++ и утверждают, что STL — это стандарт, но на практике стандартом является только интерфейс (кстати тоже редко соблюдаемый на 100%), а реализации отданы на откуп разработчикам. Причем никто не заставляет не только пользоваться библиотекой идущей в поставке компилятора, но и вообще пользоваться STL. А по числу применений скорее всего в С++ на сегодня будет победителем вообще qsort .
Такие личности вектора через индекс итерируют, строки сливают при помощи strcat, а про ostream_iterator не слышали даже от старших товарищей. Это не программисты на С++, это чистые С-шники, которые понятия не имеют ни об ООП, ни о шаблонах проектирования. А по поводу разных реализаций STL могу сказать следующее: SGI STL и gcc STL — одно и то же, а STLport является просто мультиплатформенной переделкой SGI STL. Единственный, кто действительно отличается начинкой (хотя практика свидетельствует, что различия эти некритичны) — это VC STL от Dinkumware. Так что слухи о разности реализаций несколько преувеличены.

Здравствуйте, dextery, Вы писали:

d> по поводу разных реализаций STL могу сказать следующее: SGI STL и gcc
d> STL — одно и то же, а STLport является просто мультиплатформенной
d> переделкой SGI STL. Единственный, кто действительно отличается начинкой
d> (хотя практика свидетельствует, что различия эти некритичны) — это VC STL
d> от Dinkumware.

Еще можно встретить реализацию от Rogue Wave.

Здравствуйте, VladD2, Вы писали:

VD>Кстати, ты бы кинул ссылку на iXbt-ешное тестирование.
Вот..
Тест SPEC CPU2000 Часть 5: компиляторы (C/C++ и Fortran)
Тест SPEC CPU2000: конфигурационные файлы сайта iXBT.com
Тест SPEC CPU2000. Часть 5: компиляторы. Дополнение 1
Тест SPEC CPU2000. Часть 5: компиляторы. Дополнение 2 — результаты работы под операционной системой Linux

Здравствуйте, Владислав Чистяков, Вы писали:

Дык это.. продолжение-то будет?

Хочется узнать:
корректировки в связи с новыми версиями (C#, C++)
VB.NET наконец-то
F#
Delphi.NET
Mono
и последний интел на интеле

Вот... Сорри за наглость

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Еще можно встретить реализацию от Rogue Wave.

И что характерно скорости различных алгоритмов у них у всех разные.

Здравствуйте, dextery, Вы писали:

В общем, спорить с тобой просто неохота. Скажу что хотели то и сравнивали. И результаты интерпретировали соотвественно тому что делали.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>корректировки в связи с новыми версиями (C#, C++)

Эти языки я проверял. Шарп и МС++ несколько ускорились. Обычное С++ не очень. Думается из-за того, что оптимизировали Джит, а не компиляторы.

ВВ>VB.NET наконец-то
ВВ>F#

Не знаю я эти SML-и (или что это там?).

ВВ>Delphi.NET

Нету пока ее у меня.

ВВ>Mono

Моно не тестировал, но по ощищениям он медленнее чем Шарп от МС.

ВВ>и последний интел на интеле

Видимо пора задуматься о Шутрике 4. За одно попытаться исправить те ошибки которые были ранее. И добавить несколько тестов.

Ладно. Будет время попробуем.

Здравствуйте, VladD2, Вы писали:

VD>Да, надо бы. Но похоже разницы с Дельфи 6 особой не будет.

Не буду вдаваться в разборки правильности тестов. Тем не менее, не поленился и сделал тесты для D7 и D8.NET. Тесты проведены на P4/2400 с 533 шиной с 512M памяти. время в миллисекундах

D8 — 7672
d7 — 8000

выставлялись все параметры проекта по умолчанию. Оптимизация включена. и там и там проекты — VCL приложения.

Здравствуйте, VladD2, Вы писали:

ВВ>>Delphi.NET

http://www.rsdn.ru/Forum/Message.aspx?mid=554657&only=1

Автор:
Дата: 01.03.04

VD>В общем, спорить с тобой просто неохота. Скажу что хотели то и сравнивали. И результаты интерпретировали соотвественно тому что делали.

Вот и имеете то, что имеете

Режьте меня на части — не может быть JIT-язык быстрее, чем компилируемый. Ну никак! Иначе я давно бы писал на Java, которую, кстати, очень люблю. Да и C# как брата-близнеца тоже.

Здравствуйте, <Аноним>, Вы писали:

А>Вот и имеете то, что имеете

А>Режьте меня на части — не может быть JIT-язык быстрее, чем компилируемый. Ну никак! Иначе я давно бы писал на Java, которую, кстати, очень люблю. Да и C# как брата-близнеца тоже.

Before MSIL can be executed, it must be converted by a .NET Framework Just In Time (JIT) compiler to native code, which is CPU-specific code that runs on the same computer architecture that the JIT compiler is running on. Because the runtime supplies a JIT compiler for each CPU architecture that the runtime operates on, developers can write a set of MSIL that can be JIT-compiled and executed on computers with different architectures. (If your managed code calls platform-specific native APIs or a class libary that is platform-specific, your code is limited to running on a specific operating system.)

(C)MSDN

WH>

WH>Before MSIL can be executed, it must be converted by a .NET Framework Just In Time (JIT) compiler to native code, which is CPU-specific code that runs on the same computer architecture that the JIT compiler is running on. Because the runtime supplies a JIT compiler for each CPU architecture that the runtime operates on, developers can write a set of MSIL that can be JIT-compiled and executed on computers with different architectures. (If your managed code calls platform-specific native APIs or a class libary that is platform-specific, your code is limited to running on a specific operating system.)

Спасибо! Я-то думал, что это за технология такая — JIT.
Спрошу так — есть разница в скорости между инлайн-функцией и ее виртуальным аналогом? Что может сделать JIT с таким кодом? Второе, C++ только выполняется, а IL еще и компилируется, и профилируется, и границы проверяет. И третье, ну режьте меня — на сегодняшний день нет IL-платформы, которая бы выдержала 2Гб аллокацию с приемлимой производительностью.

Здравствуйте, <Аноним>, Вы писали:

А>Не буду вдаваться в разборки правильности тестов. Тем не менее, не поленился и сделал тесты для D7 и D8.NET. Тесты проведены на P4/2400 с 533 шиной с 512M памяти. время в миллисекундах

А>D8 — 7672
А>d7 — 8000

Не понял... экто какой тест? Может приведешь более полное описание?

Здравствуйте, <Аноним>, Вы писали:

А>Режьте меня на части — не может быть JIT-язык быстрее, чем компилируемый. Ну никак! Иначе я давно бы писал на Java, которую, кстати, очень люблю. Да и C# как брата-близнеца тоже.

А что препятствует? Не, ну, я еще понимаю аргументы о ЖЦ. Но джит? У него даже приемущество есть. Он же может оптимизировать под конкретный процессор. Уже сейчас оптимизация лучше чем у компиляторов С++ 90-ых кодов. И думаю не загорами время когда они сравняются.

Здравствуйте, <Аноним>, Вы писали:

А>Спрошу так — есть разница в скорости между инлайн-функцией и ее виртуальным аналогом?

Дотнет не ява. В нем можно смело делать не виртуальные функции. Да в общем то и Яве можно. Более того. При наличии всего исходного кода (мсила или байткода) можно проанализировать его и сделать спекулятивные предположения о том, что виртуальные вызовы излишни (а это так в 90%) и устранить их. Интересно что Ява 1.4.2 уже делает это в некоторых случаях. Об этом же написано в описании проетка Интела — Star Jit.

А> Что может сделать JIT с таким кодом?

Ответа выше достаточно?

А> Второе, C++ только выполняется, а IL еще и компилируется, и профилируется,

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

А> и границы проверяет.

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

А> И третье, ну режьте меня — на сегодняшний день нет IL-платформы, которая бы выдержала 2Гб аллокацию с приемлимой производительностью.

А в чем проблема то? Поставь 3 гига на машину и дотнет займет тебе 2 как милинький. Блоки такого размера обрабатываются отдельным хипом по правилам близким к стандартым хипам С++ или ОС.