ты в курсе что NumPy написан на С? 
я же написал, что тест должен сравнивать С++ с питоном, а не С++ с С

вариант "такой-то модуль расширения языка на С\С++\Фортране\еще-каком-то-не-питоне догонит код на С++" - не катит.

Добавлено через 11 минут и 28 секунд

там тема на 6 страниц - все читать лень, 
не нашел там обоснования что основное время работы программ зависит от скорости обработки данных кодом программы, а не скорости чтения\записи файлов ОС.

Что же делать, если и сам интерпретатор пистона написан на "С\С++\Фортране\еще-каком-то-не-питоне"? Тогда вообще сравнивать нечего?

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

Сравни размер обрабатываемого файла и получившееся время. На флопике он лежал, что ли?

Тогда спор лишён смысла.

Void, почему лишен смысла? 
нормальное сравнение ЯП, это когда один и тот же алгоритм реализуется на одном (С++) и на другом языке (питон),
а не на одном языке (С++), и на 99% на третьем (С) - там мы сравниваем другую пару языков

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

http://forum.vingrad.ru/index.php?showtopi...t&p=1403408
там нету единиц измерения времени, я хз, был там флопик или нет. 
в любом случае, если мерять какой-то алгоритм - то не надо мерять время чтения\записи файла.

Это сообщение отредактировал(а) GoldFinch - 7.1.2010, 16:33

GoldFinch, я предлагал сравнивать не синтетические тесты, понятно, что с++ код будет быстрее сортировать массив в памяти. Я предлагал найти задачу, похожую на реальную, в которой есть хоть какая-то сложность, понятно, что простую задачу можно легко оптимизировать на чем угодно. Но если программа взаимодействует с ОС, использует несколько CPU, прилично засирает хип, использует сторонние библиотеки, то все уже не так просто.  

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

Юпитерианские сутки, что же ещё?

А если ввод-вывод идёт вперемежку с вычислениями? А если весь ввод-вывод заключается в печати одной строки? Если ты минимально вчитывался в условие задачи, ты прекрасно себе представляешь соотношение ввода-вывода и прочих затрат при её исполнении, и что time $command — это адекватный способ замера.

Т.е. я правильно делаю, что пытаюсь изучать джаву?

Пока ты тут в очередной раз хоронишь Delphi и С++ (а некоторые утверждают, что это "похороны" длятся уже лет 10), на sql.ru уже на полном серьезе обсудили тему перспективы Java. До конца я не дочитал, но где-то в середине джаву на полном серьезе кто-то пытался хоронить   


Вот тебе практическая задача: перепиши Open Office Calc (он же на java написан?), чтобы он не отставал по производительности от Excel (он же на С написан?) намного более, чем на 25%. Куча благодарных потомков тебе обеспечена. Ну а пока в плане скорости и юзабилити OO - полное УГ.

Нет. На ++. Тут список того, что в OpenOffice.org написано на Java. Не веришь - скачай сорцы.


Вот уж не думаю. Тоже на ++, стоит думать.


Тупой пример. Ты тогда должен написать тулзу по скорости сравнимую с MS Office.

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

Хочешь померяться - ради бога (только Lazin'а найди). А ребят из MS не приплетай. Не о них речь.

Верю. Я в историю вопроса не влезал, просто такое впечатление сложилось, что OO написан на java.

Это не важно, С++ Lazin тоже хоронит.

Я - ни в коем случае не хочу ничем ни с кем меряться. Просто Lazin утверждал, что может писать эффективный код, и просил пример задачи из жизни. Ну вот пусть и уделает M$ на самой что ни на есть жизненной задаче, раз уж ему известны секреты эффективного написания алгоритмов.

Блин, ну нельзя же доводить до абсурда. Группа разработчиков MS Office за 20 лет и море баксов против одного программиста за малое время бесплатно. Смысл?

Поэтому он и предложил "померяться" 1-on-1 на какой-нибудь небольшой задаче. Чтобы решалась за обозримое время.

Если предложение все еще в силе, то вот код, написанный на делфи:



Задача реальная. Хотя и сведена к синтетическому тесту.

Это сообщение отредактировал(а) LamerTM - 12.5.2010, 10:34

LamerTM, в чём заключается реальность задачи? И CopyMemory в 24 строке меня сильно напрягает.

Shaggie, 
Есть функция LoadFile, читающая сжатый файл. При распаковке он превращается в массив структур. Определить размер этого массива заранее нельзя, для этого надо полностью распаковать весь файл. Поэтому по мере распаковки происходит дописывание по одной структуре в массив, а массив при необходимости увеличивается. Все это реализовано в функции, которой передается имя файла, а она возвращает массив распакованных данных.

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

В коде, что я привел выше, внутренний цикл это имитация загрузки файла в массив, а внешний цикл это имитация слияния массивов в один.