[C++?] Серьезный вопрос.

> А плюсовый оптимизированный вариант сколько на этой машинке выполняется?

И ещё интересно, что получится, если на бэкенде использовать icc вместо gcc ;)

Тсссс! Я этот стёб приберегал напоследок. 8))

> Тсссс! Я этот стёб приберегал напоследок. 8))

Я думаю, что оппонентом этот факт будет интерпретирован, как ещё одно доказательство непотопляемой мощи крестов и ненужности быдлопрослойки между программистом и компьютером в виде хаскелля ;)

>Я думаю, что оппонентом этот факт будет интерпретирован, как ещё одно доказательство непотопляемой мощи крестов и ненужности быдлопрослойки между программистом и компьютером в виде хаскелля ;)

Я сперва думал сообщить о возможности компилить как хаскель так и окамль через icc, но не сделал по этой причине =)

Скорее всего, да. Осталось понять, причём там кресты только. 8))

А плюсовый оптимизированный вариант сколько на этой машинке выполняется?

да, самое главное-то забыл :)

плюсовый вариант (из самой нижней строки таблицы):

real 0m4.057s
user 0m3.988s
sys  0m0.016s

> real 0m4.057s

Разницы 30%. По бОльшей части, из-за трансляции haskell->c.

И вдогонку:

бестредовый вариант на хаскеле (без ключа -threaded при компиляции):

real 0m5.729s
user 0m5.600s
sys  0m0.022s

> real 0m4.057s

Интересно... У меня на C2D T9600 получается: real 0m2.079s

>> real 0m4.057s

> Интересно... У меня на C2D T9600 получается: real 0m2.079s

C2Q 6600 2.40GHz имеет довольно медленные ядра (примерно на уровне PIV 3.2GHz каждое, сравнивал по скорости компиляции большого проекта), основное достоинство проца - их количество

плюсовый вариант (из самой нижней строки таблицы)

Что-то тут не сходится.

$ time ./icc_ray > icc.pnm 

real	0m2.670s
user	0m2.664s
sys	0m0.004s

В один поток, из той самой нижней строки. Для gcc цифра в 2.8s. Верно для C2D E6750

Что-то ты не то насчитал...

> Для gcc цифра в 2.8s. Верно для C2D E6750

у C2Q 6600 достаточно медленные ядра

Результаты на моей машине:

cpp:

real    0m2.094s
user    0m2.037s
sys     0m0.022s

cpp + openmp:

real    0m1.604s
user    0m2.918s
sys     0m0.179s

haskell:

real    0m3.039s
user    0m2.910s
sys     0m0.070s

haskell + parFlatMap:

real    0m2.143s
user    0m3.329s
sys     0m0.157s

ocaml:

real    0m2.677s
user    0m2.593s
sys     0m0.026s

sbcl:

Evaluation took:
  2.838 seconds of real time
  2.785576 seconds of total run time (2.702589 user, 0.082987 system)
  [ Run times consist of 0.145 seconds GC time, and 2.641 seconds non-GC time. ]
  98.17% CPU
  7,926,216,102 processor cycles
  462,333,600 bytes consed

Я вот с нетерпением жду ответного шага крестофилов.

Неужели будут и дальше мусолить "30% - это ооочень много"?

>462,333,600 bytes consed

Я надеюсь, это не rss процесса?

>Я вот с нетерпением жду ответного шага крестофилов.

На что тут отвечать? Кто-то приблизился к заветным 1.6s?

>Неужели будут и дальше мусолить "30% - это ооочень много"?

И да, 30% -- это дофига. Поскольку одна хорошая сцена может порой обсчитываться часов по 12, разницу в 4 часа между 12 часами и 16 ты ой как ощутишь.

> И да, 30% -- это дофига.

а попробуй там поставь vector вместо list

спасибо за бенчмарк

> Я надеюсь, это не rss процесса?

Это краткая сводка с полей от сборщика мусора.

Хорошо бы на GHC 6.12 протестировать. Там распараллеливание на SMP улучшили.

> И да, 30% -- это дофига.

А-а-а, я понял! Оно проценты от разов не отличает! Вот у него в 36 раз и получается...

А вообще забавно... Как плюсовка кошерным сям сливает на 20% -- так "погрешность эксперимента", а как хаскелль плюсовке на 30% -- так дофига. Ржу.

> А-а-а, я понял! Оно проценты от разов не отличает! Вот у него в 36 раз и получается...

Скорей всего, у него устаревшие данные конца прошлого тысячелетия. Тот же SBCL в математике с плавающей точкой совсем недавно подтянули на 30%, так он медленнее Хаскелля картинку обсчитывал.

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

а) производительность этих языков дотянут до gcc;

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

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

Печать. Дата. Подпись.

Результаты на двух четырёхядерных Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, ghc 6.10.1

1 поток:
real    0m3.251s
user    0m3.212s
sys     0m0.036s

2 потока:
real    0m2.278s
user    0m4.196s
sys     0m0.064s

3 потока:
real    0m1.491s
user    0m3.828s
sys     0m0.040s

4 потока:
real    0m1.173s
user    0m3.756s
sys     0m0.084s

5 потоков:
real    0m1.013s
user    0m3.896s
sys     0m0.080s

6 потоков:
real    0m0.952s
user    0m3.912s
sys     0m0.088s

7 потоков:
real    0m1.015s
user    0m4.380s
sys     0m0.072s

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

real    0m21.248s
user    2m13.696s
sys     0m0.308s

занятость 8го ядра может объяснить и остутсвие роста при переходе с 6 на 7 потоков

Однопоточный вариант на c++, та же машинка с ксеонами:

[code] real 0m2.425s user 0m2.416s sys 0m0.008s [/code]

те же 30%

>Раздувает зависимости внутри проекта,

А копипаст и макросы, стало быть, не раздувают?

>нет интероперабельности с другими фичами языка

Т.е. наследники полиморфного класса уже не могут быть шаблонными? Или указатели на шаблонные объекты недопустимы?

>Реализация в g++ - говно.

Говно? Она что-то забывает деструктить при размотке стека? То, что бинарники толще чутка становятся - это ерунда по сравнению с хаскелевским хелловорлдом на 440к.

>Принципиальная невозможность

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

>В плюсах даже плохонького но стандартного нет.

Стандартный - это как swing или как swt? Тогда я выберу известный, шустрый, удобный и красивый. Да, всё в одном.

>Лямбды в С и С++ это cargo-cult programming в чистом виде.

Были слышны бульки в водоёмах, что дескать, в си и плюсах лямб не могёт быть вообще никак ибо gc нет, луговский не велит, на членах - указатели (нужное подчерктуть). Лямбды доставлены в си, boost и c++0x.

>Обобщение mark/release из Паскаля.

Можно ссылочку?

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

Поскольку в плюсах нет такого понятия, как динамическое окружение, то, как ни крути, эмулировать его нельзя. Нет, ну, конечно, можно солнце вручную закатывать на хэшах и мегатоннах мусора, и говорить, что так и должно быть... Будет примерно то же самое, когда динамическое обновления кода тут хотели сделать на подгрузке so'шек в рантайме и переименовании двойных пойнтеров (вся программа тожа должна писаться с учётом двойных пойнеров)... Удобно, просто ппц.

Да, и хотелось бы улышать, какой такой крутой нативный мультитрединг на жабе и в чём конкретно слабость системы типов c++?

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

> Да, и хотелось бы улышать, какой такой крутой нативный мультитрединг на жабе и в чём конкретно слабость системы типов c++?

Type propagation в плюсах хоть в каком-то виде появилось только в c++0x. В более современных статически типизированных языках можно короткую программу написать, вообще тип ни разу не указав.

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

Хаскелль позиционируется, как чистый ФП. Попробуй засчитай слив по парадигмам Коммон Лиспу?

>Поскольку в плюсах нет такого понятия, как динамическое окружение

Его нет искаропки поскольку оно дорогое. "Не платишь за то, что не используешь"

>то, как ни крути, эмулировать его нельзя

Так можно или нельзя? И в любом случае, как минимум в большинстве случаев оно не нужно.

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

>Type propagation в плюсах хоть в каком-то виде появилось только в c++0x

Хоть в каком то виде оно было в расширениях gcc.

>можно короткую программу написать, вообще тип ни разу не указав.

"вообще" не указать тип нельзя. Потому что есть строки, есть целые и флоаты и тип указываешь при написании константы. И к строгости типизации type propagation имеет весьма отдалённое отношение. Описание типов - немаловажная часть c++.

>Попробуй засчитай слив по парадигмам Коммон Лиспу?

У него критический промах по выразительности синтаксиса.

> Его нет искаропки поскольку оно дорогое. "Не платишь за то, что не используешь"

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

> Так можно или нельзя?

Учитывая, что всё в конечном итоге сводится к нулям и единицам - можно, но лучше не надо.

> Не забываем также, те вещи, которые в плюсах делаются сложно (динамическое обновления кода напрмер) - они не всегда усложнены из-за глупости Страуструпа.

Просто не нужно кресты совать туда, где можно сделать проще на другом языке.

> Тут есть и соображения эффективности (так ненавидимой плюсофобами) и безопасности. Лямбды в новом стандарте требуют перечисления имён захватываемых внешних переменных в первую очередь для исключения недоразумений.

Это потому что у вас окружений нет. В Лиспе захватывается текущий environment.

«вообще» не указать тип нельзя. Потому что есть строки, есть целые и флоаты и тип указываешь при написании константы.

integEps eps a b f | a<b = (f a  + f(a+eps))*eps/2 + integEps eps (a+eps) b f
                   | otherwise = 0

main = do
    print $ integEps 0.01 0 1 (\x -> 2*x*x)

Где же тут при указании констант '0.01', '0', '1', '2' их тип указан?

> "вообще" не указать тип нельзя. Потому что есть строки, есть целые и флоаты и тип указываешь при написании константы.

Я не про кресты. У строк, целых и флоатов формат описания уже несёт тип.

> У него критический промах по выразительности синтаксиса.

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

> То, что бинарники толще чутка становятся - это ерунда по сравнению с хаскелевским хелловорлдом на 440к.

Хорошо, уговорил. С++ лучше Хаскелла для написания критичных по размеру бинарника хелловорлдов.

Думаю, Хаскелловский бинарник получился больше на размер GC и, возможно, ещё каких-нибудь рантайм-сервисов, т.е. на const.

Они дружно забывают про размер libstdc++.so.

И хаскелловский бинарник слинкован статически с хаскелловскими либами. Поэтому его справедливо сравнивать с плюсовым, слинкованным статически с libstdc++.

> Они дружно забывают про размер libstdc++.so.

Опередил. :)

Жена вчера поинтересовалась, почему в таком мощном сраче про плюсы нет lester'а?

Потому что есть строки, есть целые и флоаты и тип указываешь при написании константы.

Prelude> :type 1
1 :: (Num t) => t
Prelude> :info Num
class (Eq a, Show a) => Num a where
  (+) :: a -> a -> a
  (*) :: a -> a -> a
  (-) :: a -> a -> a
  negate :: a -> a
  abs :: a -> a
  signum :: a -> a
  fromInteger :: Integer -> a
        -- Defined in GHC.Num
instance Num Double -- Defined in GHC.Float
instance Num Float -- Defined in GHC.Float
instance Num Int -- Defined in GHC.Num
instance Num Integer -- Defined in GHC.Num

Например, константа 1 имеет тип (Num t) => t, т.е. тип, принадлежащий классу типов Num, куда входят типы Int, Integer, Float, Double. Конкретный тип выводится из контекста (см. type inference).

>>Раздувает зависимости внутри проекта,

>А копипаст и макросы, стало быть, не раздувают?

Нет не раздувают. Препроцессор вообще про зависимости ничего не знает, он просто препроцессит текст.

>>нет интероперабельности с другими фичами языка

>Т.е. наследники полиморфного класса уже не могут быть шаблонными? Или указатели на шаблонные объекты недопустимы?

Нельзя в compile-time пройтись по функциям класса, например.

>>Реализация в g++ - говно.

>Говно? Она что-то забывает деструктить при размотке стека?

w_l_o_r делал перформанс-тесты и не как-то не впечатлился. BTW, они не проходят через границы .so. Под виндой такой проблемы нет, там исключения поддерживаются на уровне ОС.

>это ерунда по сравнению с хаскелевским хелловорлдом на 440к.

Плюсавый HW на винде доходит до ~800 кб если собирать его с полностью стандартным sgi iostreams либо требует dll размером в 800Кб.

>>Принципиальная невозможность

>Епта, сколько я уже слышал, что в плюсах "принципиально невозможно" всё на свете.

Виляние + избранное квотирование. Речь шла о том что бинарное представление плюсовых объектов в памяти не допускает их интроспекцию со стороны gc.

>>В плюсах даже плохонького но стандартного нет.

>Стандартный - это как swing или как swt? Тогда я выберу известный, шустрый, удобный и красивый. Да, всё в одном.

С непадающей плазмой

>>Лямбды в С и С++ это cargo-cult programming в чистом виде.

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

Да, все мы конечно знаем почему std::cout<<_1<<'\n' работает, а std::cout<<\n<<_1 - нет. И при этом не забываем смысл понятия абстракции: облегчать работу при помощи сокрытия деталей реализации.

>>Обобщение mark/release из Паскаля.

>Можно ссылочку?

Какую нафиг ссылочку? Ты что паскаль не изучал? mark сохраняет вершину кучи, release удаляет все выше. Можно это дело обобщить на какой-нибудь enter_memory_area/leave_memory_area.

>>Реализация в g++ - говно.

на icc тесты делала сильви, и он показал себя не лучше.

видимо, это все же модель эксепшенов плохая -- они чересчур динамичны, что хорошо сочетается с gc и плохо -- с плюсами

Поскольку исключения нужны ну просто исчезающе редко, а используют их ну просто ужасающе часто, так что можно сказать, что C++ не потерял бы ничего, если бы избавился от этих try..catch, throw.

>По сути, в крестах кроме классов и шаблонов ничего нет. Всё остальное "ненужное", когда нужда таки припирает, реализуется на классах и шаблонах

По сути в человеке кроме углеводородов и воды ничего нет. Всё остальное "ненужное", когда нужда таки припирает, реализуется из углеводородов и воды.

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

Страшно - это питон. Чувствуешь себя на краю пропасти, один неверный шаг и ты никогда в жизни не разберёшься в этих пробелах.

неудобно - ну оператора сделай мне з***ись в плюсах нет.

Багоопасно? Тю. Не видел ни одной надёжной программы на том же питоне. И не забываем, товарищи плюсофобы, что при упоминании багов принято ругать указатели.

>Просто не нужно кресты совать туда, где можно сделать проще на другом языке.

На практике, мой друг, 10% программы действительно удобнее сделать на другом языке, зато 90% превратят вашу жизнь в ад.

>Это потому что у вас окружений нет. В Лиспе захватывается текущий environment.

Вот опять. Чего-то нет в плюсах. Через пять страниц вы признаете что есть, но вам всё равно не нравится :D Ты мне лучше скажи, захватывается весь этот environment? Или только используемая часть? И ещё, что если в окружении есть i, а в лямбде я определяю j, но опечатываюсь и использую i?

>Они дружно забывают про размер libstdc++.so.

Ты ещё про ядро вспомни. Сравнивать надо динамик с динамиком, статик со статиком. Если развивающие хаскель академики не догадались сбацать libhascell.so - ССЗБ.

>Я не про кресты. У строк, целых и флоатов формат описания уже несёт тип.

Вот и я об этом. Вот если бы все данные неизвестного заранее типа приходили с терминала или лучше по сети, вот тогда если бы программа с ними корректно, надёжно и быстро работала - вот это было бы круто. Но это фантастика.

>Хорошо, уговорил. С++ лучше Хаскелла даже для написания хелловорлдов.

fxd.

>Нельзя в compile-time пройтись по функциям класса, например.

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

>бинарное представление плюсовых объектов в памяти не допускает их интроспекцию со стороны gc.

Правильнее так: примитивная быдлокодерская фенечка, известная как gc не способна работать таким мощным и сложным языком как c++. И это всё равно будет неправда.

>С непадающей плазмой

Она не падает. Больше :)

>Ты что паскаль не изучал?

Ну вообще-то нет. А должен был?

>mark сохраняет вершину кучи, release удаляет все выше.

Мммм. Это стек какой-то получается.

>Страшно - это питон. Чувствуешь себя на краю пропасти, один неверный шаг и ты никогда в жизни не разберёшься в этих пробелах.

Да уж... есть мнение, что постоянно цепляться к питону за пробелы как-то уныло.

>На практике, мой друг, 10% программы действительно удобнее сделать на другом языке, зато 90% превратят вашу жизнь в ад.

Это что-то новое. 90% кода пишем на крестах, остальное на питоне, да? ппц

>Вот опять. Чего-то нет в плюсах. Через пять страниц вы признаете что есть, но вам всё равно не нравится :D

Черт, может меня и поправят, но по моему тут вам шаблоны не помогут выкрутиться.

>Ты мне лучше скажи, захватывается весь этот environment? Или только используемая часть?

То есть ты так ничего и не понял...

>И ещё, что если в окружении есть i, а в лямбде я определяю j, но опечатываюсь и использую i?

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

>Вот если бы все данные неизвестного заранее типа приходили с терминала или лучше по сети, вот тогда если бы программа с ними корректно, надёжно и быстро работала - вот это было бы круто. Но это фантастика.

Эм... тут уж как парсер входных данных напишешь, так и будет.

>>Нельзя в compile-time пройтись по функциям класса, например.

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

Ну это мб не основная проблема с++, но как проблема темплейтов - да большая. Соответственно нет полноценных макр.

>>Нельзя в compile-time пройтись по функциям класса, например.

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

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

>>бинарное представление плюсовых объектов в памяти не допускает их интроспекцию со стороны gc.

>Правильнее так: примитивная быдлокодерская фенечка, известная как gc не способна работать таким мощным и сложным языком как c++. И это всё равно будет неправда.

Ручное управление памятью в С++ тоже говно.

>>Ты что паскаль не изучал?

>Ну вообще-то нет. А должен был?

Ну вообще Си идет на курсе системного программирования обычно. Введение в программирование и алгоритмы на Паскале обычно дают.

>>mark сохраняет вершину кучи, release удаляет все выше.

>Мммм. Это стек какой-то получается.

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