2Господам сортировщикам.

Я не силен в С и не могу сам разобрать приведенный алгоритм, но насколько я понял он рекурсивный. Поправте если я не так понял.
Так вот если он рекурсивный то не надо его выдавать за quick sort.
Быстрая сортировка должна писаться только итеративной.

2 Antichrist:

кинь пример про O(1) и числа Фибоначчи. что за алгоритм? я видел один быстрый, но он итерационный, а посему императивный. пока не понятно, причем тут ocaml.

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

операции ввода/вывода довольно стремно смотрятся в рамка фп -- а что оно еще может предложить кроме бесконечной рекурсии?... есть реальные примеры реализации гуев не выходящие за рамки ф.п? дай ссылочку, если знаешь, очень бы хотелось взглянуть. ;)

не спроста же в окамл были введены многие императивные фичи.

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

>А чем не угодил SmallEiffel?
-Слабой поддержкой со стороны community и кросс-компилляцией в С.
-Отсутствием библиотек, той же математики, например.
-Слабой документацией и, практически. недоступностью книг в online,
хотя последнее утверждение относится скорее к языку как таковому,
а не к его реализации.

В общем, жадность Майера и прочих людей из ISE отнюдь не
способствуют расрпространению технологии. Я говорил с ними(c ISE) на
каком-то Комтеке году примерно в 1991м. С тех пор ситуация с продажами
не изменилась.

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

>..OCaml в некоторых случаях пишу.

Пока ты один - можешь писать на чем угодно. Когда вас много -
программирование становится технологией. Со всеми вытекающими...

>Smalltalk - не умер. По количеству legacy кода он второй после КОБОЛа,
>при чем, в отличии от КОБОЛа, на нём пишут и до сих пор.

Да и на коболе пишут. Всплеск интереса к кобол-программистам после
2000 года не угас до сих пор. Поинтересуйся на рекрутерских западных
сайтах сколько вакансий есть на cobol.

Опять же, наша контора продавала одно время компилляторы smalltalk
(айбиэмерский, кажется) и довольно успешно. Потом бизнес умер.
Нет покупателей. Стало быть, нет реальных проектов. Видимо, мою
фразу следует читать "умер в этой стране".

>Про переучивание и про функциональный стиль мышления - я считаю,
>что это ОБЯЗАТЕЛЬНО для каждого...

Согласен, только не _переучивать_ надо, а сразу так учить.
Паскаль, потом lisp(или что-то еще, по вкусу), потом все остальное.

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

Я много говорил на тему применения ФП в коммерческих проектах с
нашими корифеями, все они признают что это "далеко не мейнстрим",
и, видимо, никогда им не станет. Да ие на западе, почему-то,
при тотальном обучениии лиспу в колледжах, он не стал
"промышленным языком N1" (или N2 :) ). А придуман-то сразу после
фортрана.

Может FP и не панацея вовсе? А так - что-то вроде теорем
существования и единственности решения дифура для физика, который и
так знает, что у его уравнения движения шарика по наклонной плоскости
решение заведомо есть и оно непрерывно :)

to anonymous (*) (2002-04-27 18:05:36.568)

Алгоритм Хоара или быстрой сортировки как раз рекурсивный.
Почитай 3 том Кнута. Иногда, в целях оптимизациии рекурсию
частично разворачивают.

to Antichrist:

Извини, сразу не въехал, но твой алгоритм теряет время на
проходах по списку в поисках разрешающего элемента. Чтобы
реализовать qsort аналогичный Cишному надо работать с
массивом, а не со списком.

JNZ

to Antichrist

Вдогонку:

Логические языки, например, Пролог также выглядят красиво,
но имеют ограниченную область применения. Язык C предусматривает
использование библиотек. Ведь qsort - это стандартная библиотечная
функция. А использование qsort одинаково просто в обоих языках.
Для С существует много эффективных реализаций подобных алгоритмов
(B-деревья, Хэш-таблицы и т.д.). Зачем нужна медленная и ущербная
реализация qsort на функциональном языке? Даже Кнут которого ты
так ценишь приводит свои примеры на примитивном языке, но который
не допускает двоякой трактовки при переводе алгоритма в машинный
код. Ценность С заключается в его предсказуемости на этапе компиляции.

JNZ

2JNZ
Мож я тупой но в Кнуте как раз приведен итеративный алгоритм.

to anonymous (*) (2002-04-27 19:22:53.585)

У меня сейчас нет под рукой Кнута. Стандартные библиотечные реализации qsort могут отличаться и зависят от компилера. Алгоритм Хоара иногда
называют алгоритмом быстрой рекурсивной сортировки. Суть алгоритма -

1. Выбрать разрешающий элемент - X.
2. Поставить его на свое место, при этом все эл-ты массива < X,
должны оказаться слева, > X - справа.
3. Алгоритм повторяется для части массива левее X и правее X.

Ясно, что наиболее очевидный способ - рекурсия.

Забыл подписаться.

JNZ

в glibc вроде рекурсивный спуск только на одну половинку, вторая половинка обрабатывается путем установки локальных переменных и goto на начало :) еще там вроде рекурсия завершалась на длинне части около 5-7, которые сортировались другим алгоритмом типа простой вставки... точно не помню...

это я так, к слову :)

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

Интересно, а на языке MIX рекурсия вобще возможна? Тоесть да, том 3, страницы 136-137. Там работают со стеком, но разве это есть рекурсия? Скорее её эмуляция.

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

НароД, неужели вы думаете, что рекурсия и итерации не эквивалентны? В смысле существует взаимооднозначное соответствие (инъекция) между рекурсивным кодом и итерационным (в цикле).

P.S. За нечаянное 'Д' надеюсь простите...

2 anonymous (*) (2002-04-27 21:05:28.439)

Не, не могу не встрять: инъекция -- это не есть взаимно-однозначное соответствие. Взаимно-однозначное соответствие есть БИЕКЦИЯ.

ДВ

Нет рекурсия и итерация не эквивалентны. Как могут быть эквивалентны понятия описывающие разные сути?

Давайте все таки не валить в одну кучу стек, рекурсию, эмуляцию, GOTO, MIX и тп. Алгоритм либо рекурсивный (вызывает сам себя) либо итеративный (последовательный).

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

PS. Фортановские и бейсиковские (брррр) конструкции типо GOTO - зло.

последнему анонимусу: LMD!!!! итерация - частный случай рекурсии. И очень широкий класс рекуррентных алгоритмов к итерации сводится. Ты просто слишком императивно мыслишь, отсюда и ошибки. Почитай, как компиляторы с функциональных языков устроены, чтоб больше так не лажаться.

"Итерация свойственна человеку. Рекурсия же, божественна..."
Не помню уже кто, и где я это прочитал
Было в качестве эпиграфа в какой-то
книжке по программированию. :)))))

2gns: в третьем страуструпе есть вроде... или в "дизайн и эволюция С++", только немного в другой формулировке :)

"LMD!!!! итерация - частный случай рекурсии. И очень широкий класс рекуррентных алгоритмов к итерации сводится."

Любой рекурентный алгоритм сводится к итеративному (мат. доказано) что дальше то? В любом случае компайлер выдаст разный код для рекурсивного алгорима и итеративного. И итеративный быстрее будет выполняться и памяти зажрет намного меньше.

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

> Так вот если он рекурсивный то не надо его выдавать за quick sort.
Я не люблю прилюдно ругаться матом, поэтому просто подожду пришествия Антихриста.
Но ты глубоко заблуждаешься. Так глубоко, что я бы тебе школьный учебник информатики посоветовал. Или K&R, где именно рекурсивный qsort приводится в качестве примера.

> Никакой компайлер не приводит рекурсивный алгоритм к итеративному.
*Десятки* компайлеров приводят рекурсивный код к итеративному, если это хвостовая рекурсия. Если рекурсия *не* хвостовая, эквивалентный итеративный код будет включать в себя работу со стеком данных, который в рекурсивной реализации неявно реализован стеком вызова функций.
И это не предположение, а научно доказанный факт. Если бы в наших ВУЗах нормально читали Computer Science или calculus, таких грубых заблуждений было бы гораздо меньше.

2 gns: "To iterate is human, to recur, divine" -- Peter Deutsch

так вот, вернемся к нашим баранам... результаты gcc-3.1pre не подтверждаются :(((

код "ленина", только малость подправленный чтоб компилировался 3.1пре:

g++ (GCC) 3.1 20020422 (prerelease): $CC -O3 -march=athlon -fexpensive-optimizations -funroll-all-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -falign-functions=4 -falign-jumps=4 -falign-loops=4 ./matrix_bench.c && ./a.out time = 12 seconds

2.95.4: gcc -O3 -march=i686 -fexpensive-optimizations -funroll-all-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -finline-functions -malign-functions=4 -malign-jumps=4 -malign-loops=4 ./matrix_bench.c && ./a.out time = 13 seconds

шаблонированный код АС с mtl и boost, немного подправленный ибо был криво запощен:

g++ (GCC) 3.1 20020422 (prerelease): $CXX -Iboost -DMTL_CMPLR_HAS_LIMITS AC-boost-mtl.cc && ./a.out lu_factorize:1000000 factorizations:145.01 s lu_substitute:1000000 substitutions:17.88 s $CXX -g -O2 -Iboost -DMTL_CMPLR_HAS_LIMITS AC-boost-mtl.cc && ./a.out lu_factorize:1000000 factorizations:20.8 s lu_substitute:1000000 substitutions:1.98 s $CXX -O3 -march=athlon -fexpensive-optimizations -funroll-all-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -falign-functions=4 -falign-jumps=4 -falign-loops=4 -Iboost -DMTL_CMPLR_HAS_LIMITS AC-boost-mtl.cc && ./a.out lu_factorize:1000000 factorizations:17.36 s lu_substitute:1000000 substitutions:1.9 s

2.95.4: g++ -Iboost -I/build/include -DBOOST_SGI_CPP_LIMITS AC-boost-mtl.cc && ./a.out lu_factorize:1000000 factorizations:191.24 s lu_substitute:1000000 substitutions:17.7 s g++ -g -O2 -Iboost -I/build/include -DBOOST_SGI_CPP_LIMITS AC-boost-mtl.cc && ./a.out lu_factorize:1000000 factorizations:14.21 s lu_substitute:1000000 substitutions:1.7 s g++ -s -O3 -march=i686 -fexpensive-optimizations -funroll-all-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -finline-functions -malign-functions=4 -malign-jumps=4 -malign-loops=4 -Iboost -I/build/include -DBOOST_SGI_CPP_LIMITS AC-boost-mtl.cc && ./a.out lu_factorize:1000000 factorizations:13.54 s lu_substitute:1000000 substitutions:1.36 s

примечания: 1. система: debian/woody, kernel-2.4.17, mb Asus A7V266, cpu athlon XP 1600+ (1400MHz) 2. замена -march=athlon на -march=athlon-xp результата не дает. 3. solution в коде AC везде одинаковый :) 4. результаты повторяются с точностью .02sec несмотря на небольшую "занятость" системы всякими gkrellm и xmms :) 5. все тесты проводились на gcc из CVS от 27 апреля, cvstags: gcc-3_1-branch и gcc-latest-snapshot дают незначительную разницу. 6. также проводились измерения собственного кода, общий вывод: по производительности все примерно на уровне 2.95.3, что лучше чем 3.0.x, кое-где 3.1pre выигрывает, кое-где проигрывает, выигрывает чаще на "C"-коде (например возня с индексами и указателями в двух/трехмерной теплопроводности)

PS. щаз повешу на ночь тесты/бенчкмарки от mtl на ночь, потом напишу если будет что-то интересное...

PPS. спасибо AC за код :)

Test

lenin's test
P4/1600Mz, 380Mb/133Mz AsusP4B
MSVC- 6.0
WinMe- 21
Win2000- 19

gcc 2.96
Linux 2.2- 11

2anonymous (*) (2002-04-27 23:13:34.718):

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

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

да, совсем забыл, 
-fno-exceptions -fno-rtti почему-то ухудшают код 2.95.4 (по крайней мере
если пускать этот код на моем атлоне) процентов на 5. %-[]
на 3.1pre эти опции почти не оказывают или оказываю незначительное
влияние, но в положительную сторону.

вот еще забыл запостить табличку кода АС с максимальной оптимизацией для
разных компиляторов и процессоров, пускалось все на том-же атлоне.
-march=..          factorization, substitution
2.95.4
i686: 13.54, 1.36
i586: 13.02, 1.36
i486: 13.08, 1.42
i386: 13.85, 1.42

g++ (GCC) 3.1 20020422 (prerelease)
athlon: 17.07, 1.82
i686:   16.84, 1.86
i586:   19.08, 1.84
i486:   17.49, 1.85
i386:   18.61, 1.84

2Anonymous ([91]*) (2002-04-27 23:52:52.351)

gcc 2.96 Linux 2.2 11sec вот и влип P4 на 133MHz SDRAM :), хотя тут еще ядро 2.2 может влиять... memory-management-то сильно разный

если-бы ты собрал еще код AC? там память мало влияет... за одно можно было-бы и процами померяться :)

и еще это... НАРОД! опции gcc приводите, чтоб хоть понятно было более-менее что за циферки :)

"про ООП - на таком уровне объектная декомпозиция чаще всего просто вредна. То есть, нужен OOD, с декомпозицией до уровня модулей (и, соответственно, хорошая поддержка модульности в языке). Классы - как правило оказываются лишней сущностью." (Антихрист)

"Что-то в этом есть"... но тогда лучший язык есть Модула-2 (в Обероне Вирт уже перестарался по части минимализма).

2 anonymous: забыл сказать, я свои тесты пускал на древнем PIII 733 МГц. Стало быть, KAI генерирует на данной задаче настолько эффективный код, что время его выполнения на заведомо более медленной системе (PIII) сравнимо:
KCC, процессор PIII 733
lu_factorize:1000000 factorizations:14.8 s
lu_substitute:1000000 substitutions:1.69 s
со скоростью выполнения кода от gcc на атлоне, у которого в два раза больше мегагерц:)
Кроме того, и по твоим результатам, и по моим, видно, что на таких задачах старый g++ генерит более эффективный код. Что как бы удивляет.
P.S.: Кто-нибудь еще пробовал Intel? Я сейчас проверил и с выключеннным векторизатором, ничего не изменилось. Правда, видно, что векторизатор с такими задачами не справляется, посколько время исполнения не меняется. Трудно поверить, что интел так сливает.
P.P.S.: А в чем проблема с кодом. Я вроде бы вставил его прямо из emacs.

Перевод хвостовой рекурсии на итерацию, наверное, лучше всего видеть
на примере ассемблера:
представьте, что у вас есть такой код:

recursive_proc:
    tralala
    ulululu

    push arg1
    push arg2
    call recursive_proc
    ret

то есть, вызываем *в качестве последней операции* в recursive_proc
её же, с параметрами arg1 и arg2. Так вот, преобразовать это можно
легко, таким образом:

recursive_proc:
    tralala
    ulululu

    mov [ebp + 8], arg1
    mov [ebp + 4], arg2
    jmp recursive_proc

То есть, параметры не толкаем в стек, а сразу же кладём туда, куда
надо, и вместо вызова используем goto. Соответственно, в программе
на языке более высокого уровня будет присваивание в нужные переменные
+ цикл (= итерация).

Пример на C:

int recursive_proc (int arg1, int arg2)
{
    if (arg2 > 0)
    {
         // рекурсия
         ...
         return recursive_proc (arg1 + 1, arg2 - 1);
    }
    else
    {
         // конечный случай, без рекурсии
         ...
         return arg1;
    }
}

преобразованный код:

int iterative_proc (int arg1, int arg2)
{
    while (arg2 > 0)
    {
       // рекурсия
       ...
       arg1 = arg1 + 1;
       arg2 = arg2 - 1;
    }

    // конечный случай, без рекурсии
    ...
    return arg1;
}

Вопросы есть?

Хотел поспорить с antichrist. Но присмотрелся и подумал: а antichrist'а то поди Vitaly Lugovsky зовут. ;) Те же вопли про "императивщину", ненужность C++, замену его другими языками и т.п. ... И передумал спорить. Пусть "лает на слона".

Сторонникам C/C++. Если какой-либо способ найти библиотеку/шаблон для выполнения конкретных функций ( www.google.com не предлагать ;-) ). Я большей частью администрю, и код пишу для склеивание различных систем. Перл в этом отношении прелесть. Регулярные выражения, хеш-массивы , списки - все это встроено в язык и без заморочей и риска легко используется. Единое хранилище модулей (обычно достаточно документированных) позволяет через полчаса сделать необходимый код,не впираясь в дебри протоколов . Для меня беда одна - производительность. Некоторые задачи я бы вальнул на C++, но где библиотеки взять библиотеки,шаблоны, регулярные выражения в стиле Perl, что бы приблизиться к perl по скорости разработки небольших модулей. На C++ можно сделать все - нет вопросов.Но тратить кучу времени на поиск необходимых компонентов я не могу, и тем более не хочу сам реализовывать все это и ловить бабочек. Все остануться при своем мнении после такого базара . Лучше совет дайте, может у друг друга что-то подчерпнете. Это мой совет :-).

Спасибо!

2AC: код кривой в некоторых местах вроде из-за вставки, например:

,mtl::row_major&g t;::type t_matrix; 
"очевидно" надо:
,mtl::row_major>::type t_matrix;
ну и всякие мелочи вроде mtl::unit _lower>::type с пробелом вставилось :)
похоже по производительности "на мегагерц" в среднем атлоны
примерно как PIII, но мегагерц больше, и DDR :)

где-то у меня было что-то вроде KCC-4.0f3-i386-7.1.tar, это то,
чем ты собирал? если то, то попробую

а intel действительно только на словах похоже перенимает наработки KAI group
впрочем давно за ними замечено странное отношение к своему софту
или просто денег на программистов хороших им жалко :(

2eda: libpcre --- "perl compatible regular expressions"
нет места, где есть "все" библиотеки, но пиши в форум, придумаем что-нить :)

2AC: в догонку, по поводу того, что 2.95.x генерит код лучше чем 3.0.x это да, но 3.1 вроде это положение меняет, кроме того, в gcc-списке рассылки сейчас активно занимаются этим вопросом, так что есть надежда... в качестве своих 2х центов буду собирать снапшоты из CVS и репортить если на какой-то задаче скорость упадет...

в частности "код ленина" :) прославился блин мужик тут с нами :))) у меня 3.1pre делает получше немного чем 2.95.x

to eda: www.boost.org - может и поможет а вообще для твоих задач Perl прекрасно подходит. C/C++ там IMHO не к месту будут.

И потом есть же способы делать перловый интерфейс к C/C++. XS - по-моему и еще кто-то. В Oreilly СD bookshelf видел - но не пригодилось.

2anonymous (*) (2002-04-28 09:08:32.005):

Будешь смеяться, но на первой или второй странице, аналогичное открытие уже сделали. Просто открой все комментарии вместе и поищи луговского (кириллицей или латиницей)!

Правда спорить не перестали...

Кстати, кто нибудь может рассказать что-нибудь интересное про Objective-C? в чем отличается его подход от C++ и в каую сторону он ушел от оригинального C?

To: 2anonymous (*) (2002-04-27 23:13:34.718):

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

Описание как рекурсия может быть сведена к итерации приведено в Structure and Interpretaion of Computer Programms (SICP) -- лежит в свободном доступе в интернете. Это классический учебник по программированию

to anonimous
>а intel действительно только на словах похоже перенимает наработки KAI group
>впрочем давно за ними замечено странное отношение к своему софту или просто денег на программистов хороших им жалко :(

Дело весьма понятное, кстати, и совсем не в деньгах, ИМХО
Ты когда-нибудь работал по непрофильной специальности конторы? :) Вот здесь имеет место быть аналогия: цель конторы - вафельное производство и разработка, а уж софт-то у них свой довольно мощный - но, руководители и маркетологи не- программисты, вполне может быть следующий диалог "Этот софт для чего?" "Для того чтобы показать/ продавать и продукты на базе наших процев с нашим копилЕром были лучше...." "ааа - это значит нам не нужно в работе...." - И как итог: слабое (не сказать круче :)) Внимание к этому продукту...

PS ant- а Объектив Камл С ГКК2.96 криво компилится - к нему даже "нашлёпка" специальная есть :):):):):):):)

2 bugfixer (*) (2002-04-26 21:20:50.515)
> Оффтопик:<br> А много здесь физтехов сейчас?
Читаем, веселимся. ;)

satyr.

2 bugfixer (*) (2002-04-26 21:20:50.515)
> Оффтопик:<br> А много здесь физтехов сейчас?
В догонку.
537 гр.

satyr.

Флейм отложим на малость потом, а пока советую всем, кто этого ещё не читал, прочитать сейчас:

http://www.paulgraham.com/popular.html

Потом ещё:

http://www.paulgraham.com/avg.html

ЗЫ 2asoneofus: ты про OCaml и gcc2.96 кому другому говори, а я, собирая OCaml для Sisyphus, ни с какими трудностями не сталкивался, никаких особых патчей не рисовал. Кстати, "официальный" патч касался ТОЛЬКО опций копилятора - gcc2.96 их малость по иному читал. Так что ты, как обычно, по ухи в говнищще - так ты и не смог найти эту мифическую глюку в 2.96...

ЗЗЫ 2 hobbit: в Modula-2 - минимально необходимая система модулей. Гораздо красивее и интереснее модули в Standard ML.

ЗЗЗЫ 2 JNZ: мы говорили про generic programming и темплейты - так что приведённая реализация qsort на списке всё же более подходит к теме, чем реализации на массивах (которые ничуть не длиннее на хаскелле или ML нарисуются).

ЗЗЗЗЫ 2 gns: я никогда не говорил, что ФП - панацея. Наоборот, я постоянно твержу, что ничего универсального нет, и что ФП просто имеет свою, очень широкую нишу, в которой сейчас по досадному недоразумению гнездится в основном C++.

По поводу задачи для пузомерки - прошу поточнее сформулировать условия.

Антихер!
Велез? мляшество ваше :).... Хватит булькать из выгребной ямы!
Я скомпиливал с ГКК 3.0.1... и далее... и вообще не было никаких проблем...

asoneofus

Ты тупой, да? С gcc2.96 ТОЖЕ никаких проблем. Так что соси дальше, ламерище ебучее.

Шизофреник Антихер - марш в палату лечиться!
Если ты олигофрен говёзный не врубаешься в то что если продукт называется ГКК то любая "заплата" доработка - похрену какая - это баг, Назови его РХКК - и валяйся с ним как хочешь, нефига подсовывать поделки под чужими именами. И ещё, Луговский - кончай херню нести в мой адрес - дело то уголовно-наказуемое, или снова думаешь по невменяемости отмазаться?

Нашёл тут слушателей, которым твои макароны с ушей нравятся - раздухарился, тупица...

asoneofus

Ты, опиздень ебучий, читать не умеешь? Я сказал - БЕЗ ЗАПЛАТКИ работает. Повторить ещё раз для тупых хуесосов? А может, тебе просто жить надоело, вот и выёбываешься? Так я помогу, это я завсегда готов.

C какой версии, ты трепло убогое, 2.96 стал нормально всё подряд компилить? Фильтруй базар, мудило протвинский

asoneofus

AC:
boost тащить не стал,

//#include "boost/timer.hpp"
#include <sys/timeb.h>
timeb starttest, stoptest;
(...)
//factorization
//boost::timer ft;
ftime(&starttest);
for(unsigned int i=0;i<n_tests;++i) {
lu_factorize<8>(a,factorized_a,permutationS,hint_scaleS);
}
//double felapsed=ft.elapsed();
ftime(&stoptest);
std::cout << "lu_factorize:" << n_tests << " factorizations:" << (float)((stoptest.time*1000+stoptest.millitm) -(starttest.time*1000+starttest.millitm))/1000 << " s" << std::endl;

etc, роли играть не должно



g++ -o glu2 test0.cc
196.233
16.823
g++ -o glu2 -O2 test0.cc
27.9
2.395
g++ -o glu2 -O3 -march=i686 -fexpensive-optimizations -funroll-all-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -finline-functions -malign-functions=4 -malign-jumps=4 -malign-loops=4 test0.cc
23.416
2.316
g++ -o glu2 -O3 -mcpu=i686 -fexpensive-optimizations -funroll-all-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -finline-functions -malign-functions=4 -malign-jumps=4 -malign-loops=4 test0.cc
25.34
2.163
g++ -o glu2 -O3 -march=i686 -fforce-addr -fexpensive-optimizations -funroll-all-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -finline-functions test0.cc
26.16
2.181

lenin:
gcc -o lenin -O3 -Wall -Wno-unused -funroll-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -malign-functions=4 -malign-jumps=4 -malign-loops=4 -march=i686 -fforce-addr test0.c
time ./lenin: 10.75
(а то lenin уж больно смело дробную часть отбрасывает)

P4/1600, mem:PC133
gcc 2.96, Linux 2.2

ну как и ожидалось, на производительности проца на не SSE[2] коде P4 пролетает... впрочем это похоже позиция интела... правда чипсет не под проц конечно, но вроде на коде АС он не должен сильно влиять... жалко что gcc-2.96 хотя вроде по слухам он не хуже 2.95...

хотя может это 2.96 так тормозит шаблонированный код?

Anonymouns: а 2.95.x или 3.0.4 или 3.1pre у тебя нету? :)

интересно насколько реально проигрывают в скорости скрипты Perl скомпилированным модулям на c/c++ (в 2, 5, 10, 100, 1000, .. раз медленнее?)

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

ну так зависит от того, сколько на перле а сколько на сервере на ++ :)

а если на одной машине и то имхо раз в 10 минимум перл пролетит на плавающей точке и больших объемах...

вместо месяца у меня год считать будет... аж страшно :) не буду пробовать :)))