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

> Если сказать "линкуйся с VLC динамически", размер бинарника падает где-то до 30-50kb. А ты что, дельфей никогда не видел чтоли? Это же классика.

Видел. Начиная с первых кончая... какие там в 2000 году были? Что-то мне помнится, что там простейшие статические бинарники несколько метров весили. Но сейчас Делфей нет, проверить не могу.

Но вот попробовал ради интереса плюсовый hello world собрать:

$ cat hw.c++
#include<iostream>

int main() {
std::cout << "Hello world" << std::endl;
return 0;
}
$ g++ --version
g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -Os --static hw.c++
$ strip a.out
$ ls -l
total 1140
-rwxr-xr-x 1 vk vk 1154040 Oct 13 21:52 a.out
-rw-r--r-- 1 vk vk 90 Oct 13 21:44 hw.c++

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

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

> Первые два места за реализациями на C++. Там хорошо видно, во что обходится скорость работы.

Ага 550 строк кода против 150. И это на простейшей задаче! А на чём-нибудь серьёзном сипэпэшники вообще бы удавились.

$ g++ -Os --static hw.c++

Ты такой смищной и наивный. Неужели ты думал, что я тебе статически слинкованный с glibc хаскелевский бинарник описываю? Он динамически слинкованный.

$ ldd ./a.out  
	linux-vdso.so.1 =>  (0x00007fffe79ff000)
	libutil.so.1 => /lib/libutil.so.1 (0x00007fc4df55f000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007fc4df35b000)
	libm.so.6 => /lib/libm.so.6 (0x00007fc4df0dc000)
	libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fc4dee9b000)
	librt.so.1 => /lib/librt.so.1 (0x00007fc4dec92000)
	libc.so.6 => /lib/libc.so.6 (0x00007fc4de94a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc4df762000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc4de72f000)

И при этом почти 500kb.

> Кто это назвал компилятором? Если предположить что под словом компилятор понимается "программа, транслирующая код на некоем языке в код, близкий к машинному" (более-менее "классическое" определение), то пардон, но компилятор есть даже в php. Не говоря о Java и С#. В этом смысле ваш "компилятор" чётко встаёт в этот рядок ибо без "платформы" (как минимум библиотек поддержки) оно жить не может. Но в случае с С оно почти так же? Да. Вот только одно отличие -- стандартные библиотеки так названы не зря. Они, в отличие от предлагаемой "платформы" есть в любой системе. Хотим мы того или нет.

Сударь, потрудитесь узнать что такое компилятор.

>Ага 550 строк кода против 150.

Тут буквально недавно один камрад утверждал, что ему бы кода писать, да побольше. И, кстати, сиппэпэшники не удавились на: 1) написании браузера, в котором ты сейчас просматриваешь лор; 2) если ты KDEшник, то они еще и DE тебе написали; 3) дальше, пожалуй, уже заслуги сишников пойдут, но хороший программист на цепепе, как правило, и на чистом це неплохо шпарит.

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

Лол, где это они быстро пишут? У них же ленивое программирование кругом.

> И сколько же лет должен разрабатываться такой "сервер", чтобы набрать на зарплатах кластерок на десяток-другой машин?

Один сервер за один человекомесяц будет хорошей начальной оценкой.

> размещение кластеров в датацентре тоже денег стоит и немалых.

А программисты у нас уже на помойках сидят с ноутбуками или им нужно офис снимать за денежку?

> Мвахаха

Смех без причины прихнак сиплюплюса головного мозга.

>В этом весь ваш "промышленный" ерланг.

Ага, а на С++ конечно все всё пишут сразу и без ошибок.

>Один сервер за один человекомесяц будет хорошей начальной оценкой.

Ты хотел сказать "один серверомесяц", не так ли? Размещение в датацентре + аренда пухленького канала стоит сопоставимо с зарплатой программиста в Москве.

>А программисты у нас уже на помойках сидят с ноутбуками или им нужно офис снимать за денежку?

Я бы с удовольствием дома посидел на удаленке, только что тогда менеджеры и руководители кушать будут? Как им тогда свое существование оправдывать?

>Смех без причины прихнак сиплюплюса головного мозга.

А, слишком изящная шутка для твоего понимания чтоли? Человек, который говорит: "сейчас я научу вас быдлокодить на эрланге" --, пишет: "Я делал вот так и по идее должно работать, но почему-то не работает. Хрен его знает почему это так, но если извратиться вот эдак, то все будет ништяк". Но зато спецЫалист! Статьи в журналах пишет.

> Тут буквально недавно один камрад утверждал, что ему бы кода писать, да побольше.

Пруфлинк пожалуйста.

> не удавились на: 1) написании браузера, в котором ты сейчас просматриваешь лор;

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

> 2) если ты KDEшник, то они еще и DE тебе написали

xmonad.

> 3) дальше, пожалуй, уже заслуги сишников пойдут

Против С ничего не имею, если этот макроассемблер применяется по делу.

> Лол, где это они быстро пишут? У них же ленивое программирование кругом.

Как глупо.

> Я бы

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

> Человек, который говорит: "сейчас я научу вас быдлокодить на эрланге"

Рекомендую внимательно перечитать статью. Если не поможет, повторить.

>>Оптимизацией надо заниматься когда уже есть рабочий неоптимизированный вариант.

>Это в сферической индии в вакууме так. На практике если об оптимизации не думают с самого начала, то она не делается вообще никогда.

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

>Неужели ты думал, что я тебе статически слинкованный с glibc хаскелевский бинарник описываю? Он динамически слинкованный.

Под виндой всю жизнь плюсавый Hello World был под 400 кб. А слинкованный с православным sgi iostreams из stlport под мегабайт. Каким макаром он в линухе таким маленьким выходит честно не разбирался.

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

http://www.ffconsultancy.com/languages/ray_tracer/comparison.html

Результаты: ocaml (ocamlopt -rectypes -inline 1000 ray.ml -o ray); -ffast-math воткнуть не получилось — окамль ругался.

real	0m5.703s
user	0m5.700s
sys	0m0.000s

Результаты: g++ (g++ -ffast-math -O3 ray.cpp -march=native -mtune=native -mfpmath=sse -msse2 -o ray)

real	0m6.372s
user	0m6.368s
sys	0m0.004s

Окамлевцы торжествуют, но вдруг

Результаты icc (icc -ipo -O3 -march=pentium4 -msse3 ray.cpp -o ray-icc)

real	0m4.203s
user	0m4.204s
sys	0m0.000s

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

--- ray.cpp.orig	2009-10-14 00:36:59.754850010 +0400
+++ ray.cpp	2009-10-14 00:26:35.200379022 +0400
@@ -112,6 +112,7 @@
     for (int x=0; x<n; ++x) {
       double g=0;
       for (int dx=0; dx<ss; ++dx)
+#pragma omp parallel for reduction(+:g)
         for (int dy=0; dy<ss; ++dy) {
           Vec dir(unitise(Vec(x+dx*1./ss-n/2., y+dy*1./ss-n/2., n)));
           g += ray_trace(light, Ray(Vec(0, 0, -4), dir), *s);

И в итоге icc (icc -openmp -ipo -O3 -march=pentium4 -msse3 ray.cpp) дает нам

real	0m3.055s
user	0m6.100s
sys	0m0.012s

В этом месте я чуть не кончил — openmp и правда оказался так хорош, как о нем говорят.

Итого без каких-либо изменений в исходном коде, использование icc дает выигрыш на 35% (относительно времени icc-шного бинарника); распараллеливание одной дополнительной директивой openmp дает выигрыш на 83%.

Вывод: окамль оказался не так ужасен, как я о нем сначала подумал, однако отставание на 83% (а у меня всего лишь два ядра) говорит о том, что для числодробилок он слабоват.

P. S. для всех тестов результаты работы были одинаковы. cmp гарантирует.

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

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

P. P. S. внезапно я заметил, что воткнул директиву распарралеливания немного не туда. Обновленные бенчмарки:

icc -openmp -ipo -O3 -march=pentium4 -msse3 ray.cpp

real	0m2.443s
user	0m4.832s
sys	0m0.008s

g++ -fopenmp -ffast-math -O3 ray.cpp -march=native -mtune=native -msse2 -o ray

real	0m4.233s
user	0m3.452s
sys	0m0.456s

Порадовал g++, потому что включение распараллеливания во внутреннем цикле его раньше тормозило, но разработчикам еще есть над чем работать: видимо нити создаются непосредственно по требованию, а затем уничтожаются, иначе чем же еще объяснить большое время, потраченное на системные вызовы?

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

> Когда требуется показать исходнички, лисперы-хаскеллисты и примкнувшие к ним питонщики довольно бысто пишут свой вариант. А плюсатые ребята этого не делают почти никогда, либо под страшным давлением. Это не только про тебя и сейчас, а вообще общая тенденция. Интересно с чего бы это.

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

> Ага 550 строк кода против 150. И это на простейшей задаче! А на чём-нибудь серьёзном сипэпэшники вообще бы удавились.

На этой простейшей задаче самый простой Ruby-новый вариант работает 25 часов против 5 минут. И 550 строк C++ кода таки работает на 20 процентов быстрее, чем 150 строк OCaml-а. Там, где эти 20 процентов важны, объем кода не будет иметь значения. Там, где важна скорость разработки, а не скорость работы, C++ уже очень редко применяется. И если применяется, то из-за большого объема уже написанного кода. Который подобные вам плюсофобы обосрутся переписывать на лиспах-хаскелях-окамлах.

Однако это вам не интересно. Вам интереснее возопить, что решение понравившейся вам задачки на C++ никто никак не напишет. Нахрен не нужное решение нахрен никому не нужной задачки.

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

А хотя бы в Wikipedia заглянуть на счет OpenMP слабо было?

> Нахрен не нужное решение нахрен никому не нужной задачки.

На нахрен не нужном язычке ;)

> А хотя бы в Wikipedia заглянуть на счет OpenMP слабо было?

Я про icc.

>Там, где эти 20 процентов важны, объем кода не будет иметь значения. Там, где важна скорость разработки, а не скорость работы, C++ уже очень редко применяется. И если применяется, то из-за большого объема уже написанного кода

не только и не столько скорость разработки - во всяком случае, если речь именно о кодировании. это, вообще говоря, миф - в малых объёмах несущественно, а в больших не является ключевым качеством для выбора инструмента

>Однако это вам не интересно

неправда! нам интересно всё

>А это у нас более чем двухкратное преимущество над окамлем.

Теперь наверное остается сравнить сколько времени и мозгов инвестировано в окамль и в плюсы.

>А я почему-то всегда могу предположить, где в моем коде узкое место и пока ни разу не ошибался с такими прогнозами.

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

> typedef list<Scene *> Scenes;

Быстро пробежал код и мог тормознуть... но зачем там список и почему не очевидный вектор? код получится короче и вероятно быстрее.

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

struct Ray {
  Vec orig, dir;
  Ray(const Vec &o, const Vec &d) : orig(o), dir(d) {}
};

C++ requires the definition of a struct, its members, their types and its trivial constructor.

Тут авторы че-то путают?

#include <iostream>

struct S { int a; std::string b; };

int main() {
  S s = { 12, "asdf" };
  std::cout << s.a << s.b << "\n";
  return 0;
}

> Ну и гипотеза почему плюсы тормозят

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

Там есть ещё такое:

return (intersect(Ray(p, -1. * light), s).first < infinity ? 0 : -g);

Емнип, оно без gcc'шных расширений не прокатит без конструктора. Так что не путают, а немного лукавят. 8)) Понятно, что это можно записать в две строки.

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

Итого кресты в N раз (где N почти что линейно зависит от числа ядер) быстрее на широко распространенных процессорах (man Intel Xeon). Думаю, очевидно, что детские игрушки вроде окамлей и хацкилей идут в сад, уступая место всемогущему и вездесущему C++.

Очевидно, что ты даже не задумался о такой возможности, что на openMP свет клином не сошёлся, и в "детских игрушках" тоже есть свои инструменты. Крестики глаза застилают, не иначе. 8))

> А с чего уверенность, что верна предпосылка? Может, это не плюсы тормозят, а просто окамл быстр...

А что в оккамловской модели вычислений не может быть качественно смоделировано плюсами?

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

Емнип, оно без gcc'шных расширений не прокатит без конструктора. Так что не путают, а немного лукавят. 8)) Понятно, что это можно записать в две строки.

можно и в одну даже с некоторым улучшением читабельности

  Vec p = ray.orig + hit.first*ray.dir + delta*hit.second;
  return (intersect(Ray(p, -1. * light), s).first < infinity ? 0 : -g);

преобразуем в

  Ray newray ={ ray.orig + hit.first*ray.dir + delta*hit.second, -1. * light };
  return (intersect(newray, s).first < infinity ? 0 : -g);

но вообще да, это неудобство

> А с чего уверенность, что верна предпосылка? Может, это не плюсы тормозят, а просто окамл быстр...

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

> Думаю, очевидно, что детские игрушки вроде окамлей и хацкилей идут в сад, уступая место всемогущему и вездесущему C++.

В хаскеле хорошая система типклассов, примерно та, что под названием концепты чуть не была принята в С++0х (т.к., в кратце, Страуструп побоялся, что она слишком сложная)

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

хотя если делать

template<int size> complex_function( .... RawMemoryInsteadOfVoid<size> .... )

то компилятор сможет оптимизировать

> typedef pair<double, Vec> Hit;

думаю никто так в здравом уме не напишет

> Однако это вам не интересно. Вам интереснее возопить, что решение понравившейся вам задачки на C++ никто никак не напишет. Нахрен не нужное решение нахрен никому не нужной задачки.

+1

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

Хотел я было там всем об этом сказать, но лень...

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

> Во-первых, потому, что программы на C++ пишутся дольше, чем на питоне.

Алилуййа!

> На этой простейшей задаче самый простой Ruby-новый вариант работает 25 часов против 5 минут.

Это не важно. Там где применяют руби время исполнения скрипта не важно, бо узкое горло располагается совсем в другом месте. bash, кстати, тоже чудес производительности не покажет. Обосновать почему не надо переписывать init-скрипты на c++ или не надо?

> Там, где эти 20 процентов важны, объем кода не будет иметь значения.

Ход развития дискуссии получается примерно таким:

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

.... 20 страниц флуда...

насильники: С++ хорош на задачах когда, с одной стороны, 20% скорости обладают колосальной важностью, а с другой, выразительной силы чистого С отчего-то не хватает.

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

> из-за большого объема уже написанного кода.

Да, legacy, пожалуй главная причина, чтобы учить устаревшие языки типа COBOL'а и C++.

> решение понравившейся вам задачки на C++ никто никак не напишет. Нахрен не нужное решение нахрен никому не нужной задачки.

Зелен виноград.

> А что в оккамловской модели вычислений не может быть качественно смоделировано плюсами?

Ну дык эта. Окамл и не быстрее C++ в данной задаче, а примерно одинаково. 8))

> насильники: С++ хорош на задачах когда, с одной стороны, 20% скорости обладают колосальной важностью, а с другой, выразительной силы чистого С отчего-то не хватает.

Это твой личный бред.

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

> Ну дык эта. Окамл и не быстрее C++ в данной задаче, а примерно одинаково. 8))

Учитывая то, что у окамла компилятор существенно похуже, можно сделать вывод, что программа на плюсах плохо написана, и плюсы тормозят^W^W быстродействие должно подниматься минимум в 1.5 раза без особых хлопот.

> Зелен виноград.

Такие как вы подсчитывали количество уникальных расстановок ферзей с помощью программ, не помещавшихся в оперативку уже при n=15 на форуме у KRoN73, гы-гы-гы.

>> Нахрен не нужное решение нахрен никому не нужной задачки.

> На нахрен не нужном язычке ;)

Мож я чо не догоняю, но программы пишутся, системы работают, деньги платятся. Если это показатель ненужности, то пусть так и будет ;)

> > На этой простейшей задаче самый простой Ruby-новый вариант работает 25 часов против 5 минут.

> Это не важно.

Целью задачи было достижение максимальной производительности. Если скорость решения не важна, то важно, видимо, доказать всем какой вы умный.

> Ход развития дискуссии получается примерно таким: > насильники: Да наш родимый C++ --- юберязык... > .... 20 страниц флуда... > насильники: С++ хорош на задачах когда... > Я дико извиняюсь, но начало и конец, здесь нифига не совпадают.

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

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

Может раскажете о том, каких размеров опыт позволяет вам это утверждать? Другими словами -- достаточная ли у вас длина, чтобы говорить за всю индустрию программирования?

> Мож я чо не догоняю, но программы пишутся, системы работают, деньги платятся. Если это показатель ненужности, то пусть так и будет ;)

Аналогично с окамлом, эрлангом, лиспом, хаскеллем и другими. Только программы на них пишутся веселей...

> Итого кресты в N раз (где N почти что линейно зависит от числа ядер) быстрее на широко распространенных процессорах (man Intel Xeon). Думаю, очевидно, что детские игрушки вроде окамлей и хацкилей идут в сад, уступая место всемогущему и вездесущему C++.

Очевидно, что ocaml быстрее крестов в виде g++.

> Аналогично с окамлом, эрлангом, лиспом, хаскеллем и другими. Только программы на них пишутся веселей...

По мне так от плюсов фана мало, а вот рутины много. Иногда ненужной рутины...