Речь о Delphi

http://forum.vingrad.ru/index.php?showtopi...t&p=1293909

У меня примерно 25 минут на все уходит.



Хуже всего почему-то первый тест проходит. Причем значительно хуже остальных =/

Это сообщение отредактировал(а) k0rvin - 12.5.2013, 21:29

Это логично, но тогда надо и в .NET через конкатенацию делать. Собственно смысл тестирования-то в выполнении одинакового кода, а не реализаций, а с этим проблема.

Ну делайте, в чем проблема?

http://forum.ru-board.com/topic.cgi?forum=...mit=1&m=1#1

Ну так это Атари надо заставить меня полюбить шарп.

По поводу for на while, то написано на Delphi Kingdom, что это из-за бага из D7 Upd1, который вроде как заявлено, что прибили в 2005, но в 2006 все равно торчит. Дальше не знаю, но я сегодня вот смотрел асмовый код теста выше, сравнивал, что генерят Delphi и Билдер, цикл там реализован вполне себе очевидно, инкремент, сравнение с пределом, переход.

А сейчас я буду вас смешить, в общем берем мой тестик на перемножение\деление, переделываем его в C#:



Запускаем его не под отладчиком, оптимизация включена, предпочить 32-бит, впрочем, битность не влияет, итог супер, 2.5 сек. Сделаем одно маленькое изменение, раскомментируем  //label2.Text = a.ToString(); Запускаем снова и результат 7.1 сек! Получается, что студия просто надула нас, выбросив часть работы, причем я даже не понимаю, какую именно часть, что-то же она 2,5 сек. делала. Кстати, билдер на вычисление в пустоту тоже реагирует неадекватно. Что касается Delphi XE3, то есть подозрение на ошибку в 32-хбитном компиляторе, т. к. Debug-версия при запуске без отладчика выдает значение а весьма далекое от 1.

@Beltar


Тебе надо привыкать к нормальным компиляторам -- они выкидывают ненужный код. Обычно сишные компиляторы очень хорошо с этим справляются. 2.5 секунды, видимо, булево поле дёргалось. Если поэкспериментировать с какими-нибудь интеловскими плюсовыми компиляторами, то цикл может быть вообще выкинут, даже если значение используется (значение можно предсказать, не прогоняя цикл).

Добавлено через 5 минут и 4 секунды
@Akella


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

Логично блин, но в тестах неприемлемо. Хотя и логичность можно оспорить, если код не вызывается, или его результат never used, то это надо не код оптимизировать, а программиста, т. к. код явно неправильный. Кстати, сразу встает вопрос о предыдущем тесте с матрицами, где никакого вывода этих матриц не делалось, но дебажные версии .NET работали мегатормозно, ускоряясь в разы в релизе, что у Delphi с Лазарусом не наблюдалось. Пока получается, что в 64-хбитном матане .NET не быстрее 32-хбитного билдера и вчистую сливает даже Delphi 64 тормозной по сравнению с LLVM нового билдера.
Кстати, Лазарус на умножении\делении показал катастрофическое снижение скорости при включеной оптимизации, без нее же ЕМНИП 7.5 сек. Вообще я уже слышал такой совет, чтобы оптимизацию не включать, повод задуматься, или использовать директивы компилятора для тормозных мест по фактическому тестированию.

warning`и же есть. Сообщения компилятора, то бишь.

Добавлено через 1 минуту и 9 секунд
Ну и куча решений проверки качества кода. (Особенно актуально для С++).
Кстати, грит о самом языку очень красноречиво. ;)

Что-то в web`е на firemonkey замутили http://www.cybelesoft.com/webfmx/ 

M LSD

Beltar, если ты не можешь удержаться от того чтобы оскорблять своих оппонентов, то просто не заходи в эту тему. А если не можешь сам сдержаться от того чтобы не заходить сюда, то я сделаю это за тебя.

FastMM неспроста свое название получил, будет дрюкать и на последних тестах

Вот результаты оригинального Delphi-кода (медленнее, чем на инфографике в "стартовом" посте)
Вот результаты конкатенации с нормальным циклом и без стрингбилдера (зачастую быстрее, чем у дотнетов на инфографике)

Хотелось бы заметить, что вменяемый delphi-программер не станет использовать стрингбилдер для складывания тупо строк. А умный - не станет использовать в сильно загруженном месте цикл for in, тем более - для строк.
Поэтому для меня тест выглядит как-то так: "Посоны, мы с корешом нашли 2 класса с одинаковыми названиями в NET и Delphi. Похоже, делают они то же самое и мы решили их сравнить. Так... копирнем типичный быдлокод из нета в делфи, ого! скомпилировалось. Запустим... Ну и тормоза. Delphi сосет!!1"

Если есть желание потешить свое ЧСВ - сравнивать надо более реальные вещи, а не тупое складывание строк с помощью подкапотных классов или бесполезное деление чисел. При этом писать оптимальный код для каждой платформы (а тут мозги будут нужны, ага). Например, тест целочисленной арифметики: взять 10 mpx фотку (24/32 бита или даже 8/16) и вручную рассчитать гистограмму для всех цветов по ней (выбросив из замеров загрузку и распаковку картиники в массив битов). Тест вещественных чисел - ту же картинку повернуть на некратный угол, скажем, 23.83 градуса. Тест строк - разобрать 100 МБ файл по строкам без применения стандартных классов типа StringList (по той простой причине, что в .NET эти классы вполне могут быть написаны не на дотнете))).

А так - сравнили вылизанный стрингбилдер из .NET и аналогичное убожество из Delphi. То, что последний - сплошной тормоз, никто и не спорит (интереса ради попробуйте в оригинальном коде добавлять в билдер пустую строку на каждой итерации - время снизится несильно))). Как и с тем, что можно написать нормальный. Хотя, зачем?..

Это сообщение отредактировал(а) fd00ch - 13.5.2013, 14:16

@fd00ch


Медленнее на маленьких строках. На больших -- быстрее. Любопытно.

Проц, память? Версия дельфи, FastMM? Расход памяти (Max Private Bytes)?


Создание билдера и append заменены на присваивание пустой строки и оператор сложения? (Вообще, с нормальным форком на гитхабе было бы удобнее.)

Попробовал на дотнете без билдера -- получилось, как я предсказывал: быстро на мелких строках, смерть на длинных.


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


Тащемта, реализация "старого" билдера дотнета и современного билдера дельфи -- идентичны. Если посмотреть код, то там практически копипаста.


На стадии оптимизации кода возникают интересные нюансы. Например, в шарпе есть возможность писать "небезопасный" код на указателях, в котором не будет проверок на выход за границу массива и прочего. Если понадобится оптимальный код, причём непременно на шарпе, то можно опуститься до указателей. Это будет "честно"?

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


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


Белтар уже "писал" конкатенацию простых строк, "натестировались".  

Код привел выше Akella - это мой вариант. Вот чуть более быстрый:

i5-2500, мозги какой-то лоукост. D2010, FastMM оттуда же. Расход не мерил. Тот "перерасход" на 99% связан с честным созданием новой строки в Delphi (с копированием в нее буфера) и финтом .NET, который тупо возвращает буфер

кидай этот код, посмотрим

Обсуждаемый вопрос. Я не в курсе, что такое unsafe код - значит, может не работать на другой платформе, под которой фреймворка все равно нету?))

Ну тогда не надо в конце кричать "смотрите, как наш управляемый код с JIT, GC и прочими умными буквами уделывает ваш убогий нативный", т.к. управляемый код там, по факту, и не работает

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

прочитай процитированный кусок еще раз, ты его не понял