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

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

Ну да: подумаешь, отстает от c++ в два с лишним раза :D Фигня!

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

...и этих гипотетических программ никто не видел -- это все ведь сверхсекретные разработки NASA.

> Ну да: подумаешь, отстает от c++ в два с лишним раза :D Фигня!

Ты принципиально не читаешь, что тебе пишут, или просто не умеешь?

Распараллель окамл. Да, даже с OpenMP и хвалённым icc я не увидел ни отрыва icc от gcc в 6 раз, ни превосходства его на порядок над однопоточным вариантом на окамле. Может, признаешь, что являешься специалистом по газификации луж?

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

Ты забыл добавить: "В этом отдельно взятом случае". Кстати, при включении openmp g++ вырывается вперед. Ну а кресты в виде icc рвут окамль как тузик грелку.

>Распараллель окамл.

Тебе надо, ты и параллель, "эксперт". В C++ распараллеливание делается одной строчкой, а сколько ненужного траха будет в окамле? Вперед! Продемонстрируй нам чудесную выразительность окамля и крутизну функциональных языков. Какой-то красноглазик пару страниц назад как раз вопил о том, что функциональные языки прекрасно параллелятся. Настало время подтвердить слова делом. :D

>Может, признаешь, что являешься специалистом по газификации луж?

Да ладно - зачем ты так... Пусть и дальше пишет на своём любимом языке. А то, мля, заманало читать в эхах регулярные как восход солнца пассажи "Где в яве деструктор?.. Как убрать из лиспа скобки?.. Объясните по человечески - что такое монада!" Нах!

Имеющий уши да услышит, имеющий глаза да увидит.

>Тебе надо, ты и параллель, "эксперт". В C++ распараллеливание делается одной строчкой, а сколько ненужного траха будет в окамле?

Отлично! Т.е. египтяне ещё в хер знает каком столетии до н.э. высчитали окружность земли, но ты, как та Европа, будешь ждать возвращения Кука...

> В C++ распараллеливание делается одной строчкой

Да-да-да, появилось ажно в gcc 4.1, да и то не в ванильном варианте...

> а сколько ненужного траха будет в окамле?

А хрен его знает. Так удобно, как с OpenMP, не получается, вроде. Надо посмотреть на либы, заодно окамл подучу. 8))

В любом случае, твой бред по поводу "вот icc в два раза быстрее, чем окамл" -- бред сивой кобылы. Быстрее он на 20%. Сравнивать многопоточный плюсовый вариант с однопоточным окамловым -- это уместно только в маркетоидных бреднях.

> Настало время подтвердить слова делом. :D

Только после того, как ты подтвердишь весь свой бред делом. Списочек напомнить? Вон, даже icc своров^Wоткопал, чего ж не порамить всех его космической скоростью?

Для многих задач даже отставание в 10 раз является приемлемым. Особенно, если источником задержек является ввод/вывод.

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

> Сравнивать многопоточный плюсовый вариант с однопоточным окамловым

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

> Как убрать из лиспа скобки?..

Не надо так пугать... Я представил себе лисп, из которого и скобочки убрали. 8))

А вот перевирать слова не надо, особенно если не понял их смысла.

> Написать эффективный и хороший код на Си++ требует большого
мастерства. Скажем честно, многим его не достает

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

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

Не столько веселее, сколько с офигительным снобизном. Ведь пишутся не не C++ (Java, Ada, Eiffel, C#, Fortran, Cobol), а на OCaml, Erlang, Lisp, Haskell... Это вам не лаптем щи хлебать, это веселее. :-/

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

Тут мы говорим про скорость. Давай я то же самое на ерланге нафигачу и запущу машинах на 40, чтобы потом радостно кричать, что мол-де ваш хвалёный цы-пе-пе сливает в 10 раз ерлангу? Или окамловый вариант буду пускать на C2Q, а плюсовый -- на каком-нибудь P-133?

> Тут мы говорим про скорость. Давай я то же самое на ерланге нафигачу и запущу машинах на 40, чтобы потом радостно кричать, что мол-де ваш хвалёный цы-пе-пе сливает в 10 раз ерлангу?

давай

> Или окамловый вариант буду пускать на C2Q, а плюсовый -- на каком-нибудь P-133?

вас куда-то не туда понесло

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

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

> Кто-то из активно пользующих ерланг в работе говорил

вы считаете такое доводом?! :)

> давай

(икнув) А нафига? Это не очевидно, что данная задача параллелится сколь угодно? Или что на N машинах ерланг порвёт плюсы как тузик грелку, главное, чтобы машин было достаточно и данных на всех хватило?

> вас куда-то не туда понесло

Это прямая, полная и точная аналогия тому, что сделал linuxfan. Т.е. это не меня понесло, я такого делать не собираюсь. 8))

> вы считаете такое доводом?! :)

Я считаю такое мнением, к которому можно прислушаться. Это был Lev Walkin, если не путаю. Впрочем, можно и не прислушиваться. 8))

> А нафига?

не знаю - это ваше было предложеие

> Или что на N машинах ерланг порвёт плюсы как тузик грелку

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

>Да-да-да, появилось ажно в gcc 4.1, да и то не в ванильном варианте...

С разморозкой! Уж gcc 4.4 на дворе.

>В любом случае, твой бред по поводу "вот icc в два раза быстрее, чем окамл" -- бред сивой кобылы. Быстрее он на 20%. Сравнивать многопоточный плюсовый вариант с однопоточным окамловым -- это уместно только в маркетоидных бреднях.

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

>Вон, даже icc своров^Wоткопал

http://software.intel.com/en-us/articles/non-commercial-software-development/

>Для многих задач даже отставание в 10 раз является приемлемым.

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

>Написать эффективный и хороший код на Си++ требует большого мастерства.

Верно абсолютно для любого языка.

>Не бывает универсальных решений. C++ таковым точно не является.

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

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

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

> С разморозкой! Уж gcc 4.4 на дворе.

Мда... Для особо одарённых поясняю: это был намёк, что произошло сиё дивное действо не так давно.

> Я сравниваю самый быстрый окамлевый результат с самым быстрым плюсовым результатом.

Мда... Тяжёлый случай. Возьми однопроцессорную машину, если тебе так проще будет понять идею.

>> Вон, даже icc своров^Wоткопал

> http://software.intel.com/en-us/articles/non-commercial-software-development/

Это ты начал бредить про кражу icc, заметь. На, поелозь мордочкой, раз тебе это так нравится:

>> Надо, чтобы кто-нибудь согрешил и украл icc (или хотя бы затриалил). После этого станет очевидно, что окамль ничего не оптимизирует.

(c) linuxfan http://www.linux.org.ru/jump-message.jsp?msgid=4088836&cid=4131163

> не знаю - это ваше было предложеие

Это было не предожение, а демострация бредогенератора в стиле linuxfan.

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

Я надеюсь, вы в курсе, что на ерланге это сделать проще? Впрочем, речь вообще не о том.

> Это было не предожение, а демострация бредогенератора в стиле linuxfan.
> Впрочем, речь вообще не о том

спасибо за конструктивный разговор

>>Не бывает универсальных решений. C++ таковым точно не является.

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

Глупость какая. Или ты прикидываешься как во всем этом топике?

>Мда... Для особо одарённых поясняю: это был намёк, что произошло сиё дивное действо не так давно.

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

>Возьми однопроцессорную машину, если тебе так проще будет понять идею.

Это сложно осуществить. Сейчас эпоха четырехъядерников на дворе. Радуйся, что у меня C2D, а не C2Q. А вот эпоха личных кластеров на 40 нод еще не наступила, да.

>Это ты начал бредить про кражу icc, заметь.

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

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

>Я надеюсь, вы в курсе, что на ерланге это сделать проще?

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

> Ну да: подумаешь, отстает от c++ в два с лишним раза :D Фигня!

Не делайте мне смешно... OpenMP не является частью крестов, а без OpenMP кресты смогли сделать окамл только с помощью компилятора от производителя процессора. Если же использовать сторонние библиотеки, то для окамла есть OcamlP3l - a compiler for Caml parallel programs.

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

Ну да, года два, это ж так долго. В лучших твоих традициях: давай, продемонстрируй, что тут из популярного написано с использованием openmp?

> Это сложно осуществить. Сейчас эпоха четырехъядерников на дворе. Радуйся, что у меня C2D, а не C2Q. А вот эпоха личных кластеров на 40 нод еще не наступила, да.

Ты идиот или прикидываешься? Если ты начниешь делать замеры -- поставь замеряемое в одинаковые условия. Или делай всё в один поток, или всё в Н потоков.

> Ну никому из вашей тусовки не захотелось с icc связываться, мне же было лень регистрироваться.

Т.е. ты в очередной раз подумал, что в луже газу не хватает.

> Однако желание погонять скриптовиков-затейников ссаными тряпками взяло верх :)

И ещё раз. Ты не заметил, но ссаной тряпкой ты попал только по себе при замахе.

Итак, я напоминаю вопросы по icc, раз уж ты его поставил:

1. наглядный пример превосходства в 6 раз по сравнению с gcc в студию

2. наглядный пример превосходства в 36 раз (ты, вроде, утверждал, что все эти скриптовые недоязычки типа хаскелля с окамлом от плюсовки (без уточнения это же надо понимать как gcc, правильно?) в 6 раз отстают? 6*6 = 36) по сравнению с хаскеллем или окамлом.

>Глупость какая.

Ну а что там у нас нельзя написать на цпп?

> Собственно, не факт. С использованием MPI вычислительные С++ программы работают на кластерах из тысяч машин.

Разница между "проще" и "возможно сделать" заметна? Хотя да, каюсь, на MPI толком не смотрел, может, с ним и в плюсовке жить можно.

>Если же использовать сторонние библиотеки, то для окамла есть OcamlP3l - a compiler for Caml parallel programs.

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

> Не надо так пугать... Я представил себе лисп, из которого и скобочки убрали. 8))

Да тут даже воображения не надо, см. макрос LOOP.

> Ну а что там у нас нельзя написать на цпп?

Ты знаешь, программы можно даже как алгорифмы Маркова писать. Они тоже полные по Тьюрингу. Цпп тоже. Или ты опять дурака валяешь?

>В лучших твоих традициях: давай, продемонстрируй, что тут из популярного написано с использованием openmp?

На моей родной кафедре в моем родном университете используют для ускорения рассчетов численных решений систем дифуров. Продукт определенно нашел свою нишу.

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

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

>2. наглядный пример превосходства в 36 раз

Для тебя, мой наивненький конъюнктивитчик, я даже пальчиком не пошевелю. От тебя исходят только громкие метановые выхлопы, но нет никакого практического результата. Иди параллель окамлевский рейтрейсер -- авось 2.25 раза сократятся до 1.5, а количество строк кода в окамле превысит количество строк в плюсовом варианте :D

> На моей родной кафедре в моем родном университете используют для ускорения рассчетов численных решений систем дифуров. Продукт определенно нашел свою нишу.

Т.е. никем, нигде и никогда? Так и запишем.

> В итоге окамль почему-то шумно слил.

Шумно слил аффтар тестирования, а не окамл. Последний себя очень достойно показал.

> Для тебя, мой наивненький конъюнктивитчик, я даже пальчиком не пошевелю.

Очередной громкий ПУК, иными словами.

> Иди параллель окамлевский рейтрейсер -- авось 2.25 раза сократятся до 1.5

Хватит, оставь лужи будущим поколениям. Так и так уже сплошная газировка твоими трудами.

>Ты знаешь, программы можно даже как алгорифмы Маркова писать. Они тоже полные по Тьюрингу.

Опять теоретизируем? Я уже понял, что функциональщики все как один программируют в ленивом стиле.

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

Узнаю в этом описании сторонников функциональщины из этого тереда.

> Разница между "проще" и "возможно сделать" заметна?

Я вообще не уверен, что на Erlang-е получится сделать вычислительную задачу, которая будет масштабироваться на тысячу узлов.

>> Я в шоке, это сколько же народу не осилило Це++ ))) И "ОО на Це легче сделать, чем Це++ учить"))), и "STL кривой больно бьющий по яйцам" ))) Ах-ха-ха, Пых-пых вам в руки! Аминь!

> Православный CLOS тебе в гланды.

Что "Пых-пых вам в руки!" за живое задело? )))

>Другими словами -- достаточная ли у вас длина, чтобы говорить за всю индустрию программирования?

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

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

>Я только сейчас приступил к изучению хаскеля.

Я бы потратил время на что-нибудь более стоящее. В твоем случае я бы рекомендовал выучить плюсы.

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

>В нем красивая математика.

Похвально, что у тебя хватает ума не соваться с "красивой математикой" в бенчмарки.

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

Восторженные неофиты такие восторженные.

>>Другими словами -- достаточная ли у вас длина, чтобы говорить за всю индустрию программирования?

>Очевидно же что С++ это катастрофа индустрии.

Очевидно, что в индустрии было всего лишь несколько языков, которые очень широко успешно использовались для решения реальных задач. Fortran, Cobol, Lisp (вероятно), С, C++, Java+C# (это если не брать скриптовых вроде Rexx, Tcl, Perl, Python и PHP, а так же менее распространенных вроде Smalltalk, Ada, Modula-2 и пр.).

Из этого ряда эстетов может удовлетворить разве что Lisp. Все остальное -- это сборище компромисов и посредственных решений. Тем не менее, по востребованности индустрией никто другой рядом с этими языками и рядом не валялся. Что доказывает, что индустрии не нужны красивые, "концептуально чистые" и "правильные" инструменты, нужны практичные. К числу которых C++ как раз и относится. Так что C++ -- не катастрофа, а потребность индустрии (причем до сих пор). Ничего лучшего на его замену до сих пор не сделали.

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

Детский сад, младшая ясельная группа.

>Все остальное -- это сборище компромисов и посредственных решений.

Каких нафиг компромиссов? Строуструп написал препроцессор который конвертирует class A : B, C { ... } в struct A { struct B __Aparent0; struct C __Aparent1; ... } и т.п в том же роде. Потом это художество лет десять гнило и обрастало костылями и в итоге получилось то что мы имеем.

>Детский сад, младшая ясельная группа.

Нас ибут, а мы крепчаем. Позиция взрослого человека, да.

> В твоем случае я бы рекомендовал выучить плюсы.

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

>Строуструп написал препроцессор который конвертирует class A : B, C { ... } в struct A { struct B __Aparent0; struct C __Aparent1; ... } и т.п в том же роде. Потом это художество лет десять гнило и обрастало костылями и в итоге получилось то что мы имеем.

Жабокодер завидует множественному наследованию?

>Очень может быть, что я их знаю гораздо лучше тебя

Очередное "ленивое" утверждение?