выбирайте правильно средства под задачу (ответ на тему «g++ sucks»)

Ну всё! Профессор В.С.Лугоффский с его "подхвостовой рекурсией" сделан. Навеки и окончательно.

Я конечно, прошу простить за мою шалость, шутка была не самая удачная. Прошу модераторов поправить пост, убрав все эти "sucks" (кроме того, что в названии).

Чему был посвящен пост? А тому, что

1. Часто люди выбирают рабочий инструмент не только по скорости сгенеренного кода.

2. Отставание компилятора от Интел выглядит весьма подозрительно, вероятнее всего, код специально оптимизировался под MS студию.

> Профессор В.С.Лугоффский с его "подхвостовой рекурсией" сделан. Навеки и окончательно.

Не совсем Вы правы. Код на С написан _после_ кода на Схеме. Я, конечно, программист тот ещё, но не решился бы писать С-шный код "сходу". Всё-таки выразительная мощь лиспоподобных языков велика, да и над программой размышляешь совсем по-другому.

> Всё-таки выразительная мощь лиспоподобных языков велика

ну если вон те краказябры сверху называть "великой выразительной мощью"...

// wbr

> ну если вон те краказябры сверху называть "великой выразительной мощью"...

Умные люди ведь смотрят на суть, а не на форму, правда? :)

С другой стороны посмотрим на код внимательно: в С-шном присутсвует такая низкоуровневая вещь, как "указатель на функцию", а в схемовском коде ничего такого нет. Человек все-таки должен мыслить по-своему, а не как машина. А иначе плучается как с моим приятелем: на любом языке он пишет программу на Фортране :)

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

указатель? зачем нам указатель?
не, нам указатель не нужен.

--- test.cc ---
#include <cmath>
#include <iomanip>
#include <iostream>

static const double eps = 1e-7;

template <class T>
double
integrate(double a, double b, T integrand)
{
    if (fabs(b - a) < eps) {
        return integrand((a + b) / 2.) * (b - a);
    } else {
        return integrate(a, (a + b) / 2., integrand) +
               integrate((a + b) / 2., b, integrand);
    };
}

static double
square(double x)
{
    return x * x;
}

int
main()
{
    std::cout << std::setprecision(15) << std::setw(18)
              << integrate(0., 1., square) << std::endl;
    return 0;
}
--- test.cc ---

[none@grey-vm tmp]$ g++ -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
[none@grey-vm tmp]$ g++ -O2 -ffast-math -o test test.cc
[none@grey-vm tmp]$ time ./test
 0.333333333333333

real    0m0.328s
user    0m0.305s
sys     0m0.025s

// wbr

7-Zip НЕ оптимизировался специально под MS Studio. Почему компилятор от MS так уделывает GCC и даже выигрывает у Intel C++ - не ясно.

Я НЕ могу переписать 7-Zip под C - и вряд ли вы захотите возиться с 10 мегабайтами исходников на C++.

Ваш ответ не зачитывается в принципе. Увы, вы просто облажались. ;-) Ничего личного

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

А как насчет фунций, принимающих и возвращающих другие функции? Простой пример пока в голову не приходит, но можно подумать

eee, tak ne chestno :)

voz'mi kakuyu nibud' vmenyaemuyu realizaciyu Scheme ili CL, naprimer Bigloo i Allegro CL, vklyuchi optimizaciyu, a potom posmotrim kto bystree.

> 7-Zip НЕ оптимизировался специально под MS Studio.

Это заверения авторов?

> Почему компилятор от MS так уделывает GCC и даже выигрывает у Intel C++ - не ясно.

> _выигрывает у Intel_

это-то и является оновой для подозрений. Не исключено, что в исходном коде есть какие-то msvs-сизмы.

> Я НЕ могу переписать 7-Zip под C - и вряд ли вы захотите возиться с 10 мегабайтами исходников на C++.

Не надо вовсе. Достачно писать на подходящем языке (C или даже ассемблере) только критические участки кода. А авторы, по-видимому, решили не заморачиваться и наваяли все на C++: и графморду, и математику. Что не есть хорошо.

> Увы, вы просто облажались. ;-)

I love you too :-)

> А как насчет фунций, принимающих и возвращающих другие функции? Простой пример пока в голову не приходит, но можно подумать

functor-ы? :)

// wbr

Очень вежливый вы собеседник, надо сказать.

За birdie-sucks - отдельное спасибо.

> За birdie-sucks - отдельное спасибо.

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

> functor-ы? :)

Наверное, я С++ давным-давно не пользовал. А пример какой-нибудь можно?

> это-то и является оновой для подозрений. Не исключено, что в исходном коде есть какие-то msvs-сизмы.

Если найдёте хоть один в исходниках p7zip, ставлю три бутылки пива:

Исходники p7zip (crossplatform)

http://downloads.sourceforge.net/p7zip/p7zip_4.55_src_all.tar.bz2

Исходники 7zip (win only)

http://downloads.sourceforge.net/sevenzip/7z455.tar.bz2

> eee, tak ne chestno :)

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

> voz'mi kakuyu nibud' vmenyaemuyu realizaciyu Scheme ili CL, naprimer Bigloo i Allegro CL, vklyuchi optimizaciyu, a potom posmotrim kto bystree.

я оставлю это почетную задачу кому-нибудь другому. мне в сущности все равно - быстрее они чем C++ в g++ реинкарнации или нет.

// wbr

shahid@alkaida:~/progr/test_integral> gcc -O2 -ffast-math test.c -o test-c
shahid@alkaida:~/progr/test_integral> time ./test-c
0.333333333333333
./test-c
0,91s user
0,00s system
97% cpu
0,928 total

shahid@alkaida:~/progr/test_integral> gcc -O3 -ffast-math test.c -o test-c
shahid@alkaida:~/progr/test_integral> time ./test-c
0.333333333333333
./test-c
0,81s user
0,00s system
97% cpu
0,834 total

Вот так!
gcc version 4.2.1 20070604 (prerelease) (SUSE Linux)

> Если найдёте хоть один в исходниках p7zip, ставлю три бутылки пива:

1. У меня нет MSVS

2. Я не знаю С++ :-)

3. Я вообще не программист! :-))

А если серьезно, то непонятно, насколько корректно сравнивать _разные_ программы на производительность, что, впрочем, Вам уже указали в другой теме. Посему msvs-измы надо искать в 7-zip, коя "win-only".

1. консольный 7z практически идентичен для разных ОС

2. Т.е. у вас одни теории?

3. Т.е. зачем нужна была эта тема, если вы даже в вопросе не потрудились хоть чуть чуть разобраться? ;-) Сразу обвинения в некомпетентности Игоря Павлова. Слабо написать архиватор я-ля 7-zip? То-то же

> 3. Т.е. зачем нужна была эта тема, если вы даже в вопросе не потрудились хоть чуть чуть разобраться? ;-) Сразу обвинения в некомпетентности Игоря Павлова. Слабо написать архиватор я-ля 7-zip? То-то же

khm... детское "слабо" на фоне весьма сомнительной целесообразности оных телодвижений смотрится как-то слабенько :) бо нахуа - не понятно..

// wbr

> Почему компилятор от MS так уделывает GCC и даже выигрывает у Intel C++ - не ясно.

Что здесь не ясного? Visual C++ это один из флагманских проектов Microsoft, над ним работают очень крутые дядьки, многие из которых заседают в комитете по С++, получают хорошие деньги. Надо удивляться тому, что g++ сравним с подобным монстром.

слушай за разбор исходников 7зип мало даже ящика коньяка не то что пива... и это только за разбор... за сравнение ещё ящик... иначе даже браться не стоит... но ход конечно хороший "разберите 10000 строк кода, и докажите мне".... расчёт явно на то что никто не возьмётся и потом можно будет всех обострать как "ниосиливших".... молодец, садись, 2.

я им уже тыщу раз говорил. "свобода важнее". непонимают.

чё все на бирди набросились ?

birdie +1

если ты плюнешь в сообщество, оно урётся, но если сообщество плюнет в тебя... :)

Дык 7zip ведь портирован на linux, unix.. И программист явно не на блокноте код писал

говорить что g++ тормознее компилит и более тормозной код генерит это плевать в сообщество ?

обезъянности какие....

то что тормознее компилит это пофигу. но за это обсирать не учтя многих других подробностей - полное свинство.

а что тут учитывать ? то что g++ говняней майкросовта и интела это вроде бы common knowledge. А тот пример что бирди привел это конечно не доказательство, но факт ещё раз подтверждающий этот common knowledge.

> чё все на бирди набросились ?

За то, что он создаёт ложные цели, за то, что он смущет новичков и неокрепшие умы. Это самый простой, легкий и _неправильный_ путь -- ускорять свой проект выбором нужного компилятора. В первую очередь, нужно выбрать правильное решение (алгоритм), правильные средства реализации и правильно оценивать трудозатраты на всё.

Упреждая возражения сразу скажу, что в деле сравнения качества компиляторов Бирди тоже своей выходкой ничего не сделал: в таком сложно проекте, как целый _архиватор_ (а не сам алгоритм архивирования) (практически) невозможно выяснить, что же является причиной отставания того или иного компилятора. И уж тем более, на неидентичных исходных текстах.

Итого: от исходной темы, продолжением которой является эта, больше вреда, чем пользы.

> а что тут учитывать ? то что g++ говняней майкросовта и интела это вроде бы common knowledge.

А вот и первые жертвы, точнее, эти самые неокрепшие умы, распространяющие подобно грызунам, чуму незнания. Вы читали у Рабле про остров Наслышки?

>За то, что он создаёт ложные цели, за то, что он смущет новичков и неокрепшие умы, бла бла бла

это твои фантазии основанные на рефлексии.

>деле сравнения качества компиляторов Бирди

а ты что сделал ? ты уже сознался что ни с++ ни msvc в глаза не видел, ну дык откуда такая гнуверенность ?

> Я конечно, прошу простить за мою шалость, шутка была не самая удачная. Прошу модераторов поправить пост, убрав все эти "sucks"

А вот хрен вам, не поправим! Говорите спасибо mk.

> ты уже сознался что ни с++ ни msvc в глаза не видел, ну дык откуда такая гнуверенность ?

Вы невнимательны: на C++ я не программирую, но знаю довольно неплохо. MSVS действительно не использовал и не использую. Впрочем, где я сказал, что они плохи? Я лишь говорю, что 10% разница вполне может быть обусловлена не качеством компилятора как таковым, а "прослойкой между клавиатурой и стулом", т.е. вкусами и привычками самого программиста. Именно это здесь являлось главным тезисом, тем более, что 7zip - это не алгоритм сам по себе, а еще куча другого кода.

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

>а что тут учитывать ? то что g++ говняней майкросовта и интела это вроде бы common knowledge. А тот пример что бирди привел это конечно не доказательство, но факт ещё раз подтверждающий этот common knowledge.

Критерий "говняности" в студию! По каким параметрам сравниваете?...

> А вот хрен вам, не поправим! Говорите спасибо mk.

Почему? Ведь это _тема_, а не ответ на нее.

>Я лишь говорю, что 10% разница

там на распаковке доходит и до 15%, и это при том что у победителя системные вызовы идут через дополнительную прослойку (wine)

>7zip - это не алгоритм сам по себе, а еще куча другого кода.

то что не алгоритм, от "КB/s" ничего не отжирает.

>А свой пример я привёл для того, чтобы подемонстрировать

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

>Именно поэтому живут и здравствуют скриптовые и динамические языки.

они здравствуют по другим причинам...

Кому не нравятся "краказябры":
eps = 1e-7
midPoint a b = (a+b)/2
integral a b f = let c = midPoint a b in
    if abs(b-a) < eps then f c/(b-a)
    else integral a c f + integral c b f
main = print $ integral 0.0 1.0 $ \x -> x^2

> Я лишь говорю, что 10% разница вполне может быть обусловлена не качеством компилятора как таковым, а "прослойкой между клавиатурой и стулом", т.е. вкусами и привычками самого программиста. Именно это здесь являлось главным тезисом, тем более, что 7zip - это не алгоритм сам по себе, а еще куча другого кода.

Вы видели эту прослойку? Вас не удивляет, что 7zip Из-под эмулятора быстрее работает? Вы поняли как я тестирую? Это тупой запуск benchmark'a, который просто по максимуму загружает OS _independent_ алгоритм.

Все ваши аргументы - пустые слова.

> А свой пример

Ваш пример притянут за уши. Я бы сказал он никакого отношения к проблеме не имеет. Есть _одниковые_ исходники и разные компиляторы. Вы зачем то пошли разглагольствовать о разных языках и методах программирования.

Я больше здесь ничего писать не буду. Мне не о чём с вами спорить, ибо вы просто извратили смысл исходного посыла.

Спасибо за поддержку

>выбирайте правильно средства под задачу

Знать бы заранее, какая задача каким средствам соответствует. А то озарение приходит, когда проект на 2/3 готов.

> functor-ы? :) 

А как насчёт такого:

CL-USER> (defmacro post-op (name op)
  `(defmacro ,name (var arg)
	 (let ((vname (gensym)))
	   (list 'let (list (list vname var))
			 (list 'setq var (list 'funcall ,op var arg))
			 vname))
	 )
  )

POST-OP
CL-USER> (post-op post+ #'+)
POST+
CL-USER> (macroexpand-1 '(post-op post+ #'+))
(DEFMACRO POST+ (VAR ARG)
  (LET ((VNAME (GENSYM)))
    (LIST 'LET
          (LIST (LIST VNAME VAR))
          (LIST 'SETQ VAR (LIST 'FUNCALL #'+ VAR ARG))
          VNAME)))
T
CL-USER> (defvar a 0)
A
CL-USER> (post+ a 1)
0
CL-USER> a
1
CL-USER> (post+ a 1)
1
CL-USER> a
2
CL-USER> (macroexpand-1 '(post+ a 1))
(LET ((#:G1978 A))
  (SETQ A (FUNCALL #<Function + {101AECE1}> A 1))
  #:G1978)
T

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

над gcc (это не c compiler, а compiler collection, не забываем) работает не меньше крутых дядек - ибо используется он в офигенном количестве мест начиная от ентерпрайз юниксов и заканчивая всяческим ембеддедом

а c++ говно и маздай, как завещал виталик

>не меньше крутых дядек

то то им пришлось даже консорциум для "улучшиния производительности кода" создать.

http://www.linux.org.ru/view-message.jsp?msgid=1640779&page=1

> Я больше здесь ничего писать не буду. Мне не о чём с вами спорить, ибо вы просто извратили смысл исходного посыла.

Посыла не было, мой югый друг. И доказывать идентичность исходников следует _Вам_, если хотите, чтобы Ваши "исследования" имели какую-то ценность.

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

Впрочем, хотите отсаватьсь глухи и слепы - Ваше право

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

>что один и тот же _алгоритм_,

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

>микрософтовского и интеловского компиляторов

зачем монополистам консорциумы ? они им не нужны. они сами сусами.

birdie> 7-Zip НЕ оптимизировался специально под MS Studio.

Ты его что-ли наисал, чтобы так авторитетно заявлать, а?