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

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

>Ты только подтверждаешь мою догадку о твоей умственной неполноценности.

Типичный плюсофильский полемический прием.

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

На начальном этапе не должно быть ничего кроме алгоритма.

>Если оно не приходит, от имеем firefox, жрущий сотни мегабайт ОЗУ из-за фрагментации.

Да, ты бы сразу сделал как надо, я не сомневаюсь.

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

>Правда? И чем же тебе не подходит концепция: "ресурс надо освободить, как только он стал никому не нужен"?

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

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

Просто праздник какой-то. Многопоточное пргограммирование - еще одно слабое место С++. На нетривиальных задачах Java с ее gc справляется зачастую лучше. Подчеркну, нетривиальных. С циклическими связями, с многочисленными локами и прочим непотребством. См. Java EE.

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

Кстати, распараллеливание - одна из перспективных сторон чистых функциональных языков, к которым относится хаскель (с какого хрена он скриптовый??). Это так, для информации.

>Типичный плюсофильский полемический прием.

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

>На начальном этапе не должно быть ничего кроме алгоритма.

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

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

Добавь конкретики. А то пока я что-то не вижу никакой циклической зависимости: class MMappedArea + class MappedFile с методом MMappedArea map_area(size_t start, size_t size) вроде как бы не дают никакой цикличности.

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

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

>Кстати, распараллеливание - одна из перспективных сторон чистых функциональных языков

Да будет тебе известно, чистых функциональных языков в природе не существует. Даже хацкиль заморался монадами. В реальной жизни, как правило, без side-эффектов обходиться не получается. Возьмем простейший пример: кеширование запросов к БД. Наша функция выполняет запрос _и изменяет состояние кеша результатов запросов_. Вот такая вот она суровая, эта реальная жизнь.

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

Узнай о существовании Эрланга и утопись.

>Узнай о существовании Эрланга и утопись.

Это то тормозное говнецо, на котором ejabberd написан? Наверное, я бы и правда удавился, если бы пришлось этот говноязык осиливать.

> с какого хрена он скриптовый??

А ему шо пен, шо моцарт. Человек-бредогенератор. А может, это кто-то бота написал?

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

Ога, расскажи нам. Вон только что было две одинаковых программы на С++ и Окамле - где больше строчек?

Да, ладно. Зато весело :)

> Да будет тебе известно, чистых функциональных языков в природе не существует. Даже хацкиль заморался монадами. В реальной жизни, как правило, без side-эффектов обходиться не получается.

Монада сама по себе так же девственно чиста как весь хаскель. Побочный эффект вносится извне во время вызова main. Только я не знаю, понимаешь ли ты меня...

4. наглядной демонстрации превосходства icc над gcc в 6 раз

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

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

>>Типичный плюсофильский полемический прием.

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

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

>>На начальном этапе не должно быть ничего кроме алгоритма.

>Ты делаешь мне смешно. А что, реализацию алгоритма не продумывают, прежде чем воплотить ее в коде?

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

>А то пока я что-то не вижу никакой циклической зависимости: class MMappedArea + class MappedFile

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

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

>Я задал прямой вопрос: как там у вас происходит освобождение мьютексов?

synchronized (this) {
... Мы в домике...
}

> Многопоточное пргограммирование - еще одно слабое место С++ > Справедливости ради, должен сказать, что видел (и даже приходилось постоянно править) одно многопоточное приложение, написанное на C++.

Правильно ли я понимаю, что заключение о слабости C++ в многопоточном программировании сделано на основе _одной_ увиденной вами многопоточной программе на C++?

> См. Java EE

Офигительный по содержательности совет. В Yahoo, к примеру, вместо Java решили использовать Erlang (http://www.ddj.com/hpc-high-performance-computing/220600332), поскольку:

Building it as a stand-alone threaded Java app would mean introducing the issues associated with the threaded programming model. The threading model is based on shared memory and locking to achieve consistency. Developing and deploying an error-free threaded program is tough, since hard-to-reproduce concurrency issues go hand-in-hand with shared memory.

Так что не нужно размахивать Java как флагом, она в этом смысле ничем не лучше C++.

> Я задал прямой вопрос: как там у вас происходит освобождение мьютексов?

Как в Java происходит освобождение локов? В простейшем виде там у каждого объекта есть свои очереди ожидания, и используется счетчик захватов/освобождений. А в чем собственно вопрос?

> Правильно ли я понимаю, что заключение о слабости C++ в многопоточном программировании сделано на основе _одной_ увиденной вами многопоточной программе на C++?

Нет неправильно. Это не только мой опыт.

> Так что не нужно размахивать Java как флагом, она в этом смысле ничем не лучше C++.

Для некоторых задач таки лучше. Только не причислил ли ты меня к клубу явофилов?

>>Узнай о существовании Эрланга и утопись.

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

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

>Так что не нужно размахивать Java как флагом, она в этом смысле ничем не лучше C++.

При той же самой кропотливости которая требуется для написания кода на С++ от жабы можно ожидать железобетонной надежности в режиме 24/7.

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

Будь добр, укради icc и прогони на нём рейтрейсер с ffconsultancy, плюс его же на окамле, и результаты сюда выложи.

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

> Офигительный по содержательности совет. В Yahoo, к примеру, вместо Java решили использовать Erlang (http://www.ddj.com/hpc-high-performance-computing/220600332), поскольку:

> Building it as a stand-alone threaded Java app would mean introducing the issues associated with the threaded programming model. The threading model is based on shared memory and locking to achieve consistency. Developing and deploying an error-free threaded program is tough, since hard-to-reproduce concurrency issues go hand-in-hand with shared memory.

У нас тут есть мьютекс-фан АКА linuxfan. Пусть он это почитает.

> Так что не нужно размахивать Java как флагом, она в этом смысле ничем не лучше C++.

Убеждённых жабофанов тут вроде нет. Уж лучше Scala, туда и эрланговских экторов портировали.

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

>Будь добр, укради icc и прогони на нём рейтрейсер с ffconsultancy, плюс его же на окамле, и результаты сюда выложи.

Я, кстати, несколько лет назад гонял примеры из книжки с велосипедами на Intel C++ Compiler. Качественного отличия от MSVC++7 нет. Более красивые асмовые аутпуты получились когда я заменил _matrix[i][j] на _matrix[(i<<2)|j] и напихал intrinsic-ов.

>>Так что не нужно размахивать Java как флагом, она в этом смысле ничем не лучше C++.

>При той же самой кропотливости которая требуется для написания кода на С++ от жабы можно ожидать железобетонной надежности в режиме 24/7.

Ожидать можно, увидеть такое редко удается. На практике получается, что процент нормально написанного ПО на Java не сильно отличается от такого же на C++.

> C++ изобилует подводными камнями. Это плата за его высокоуровневость.

Плачу.

>>3. исправления быдлокода на C++, который наравне с окамлом был по скорости

>Сейчас, дарагой! Все брошу и побегу исправлять. Говорю же: just use icc.

>>4. наглядной демонстрации превосходства icc над gcc в 6 раз

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

У нас есть такие приборы, такие приборы ... Но мы вам о них ничего не расскажем!

> Даже хацкиль заморался монадами.

И что? От этого он перстал быть менее чистым?

>>При той же самой кропотливости которая требуется для написания кода на С++ от жабы можно ожидать железобетонной надежности в режиме 24/7.

>Ожидать можно, увидеть такое редко удается.

Я говорю о себе. Как написать небольшой надежный standalone-сервачок под любой протокол на жабе без уязвимостей и утечек за пару-тройку недель работы я вполне представляю. Безо всякого EE можно обойтись.

> Я говорю о себе. Как написать небольшой надежный standalone-сервачок под любой протокол на жабе без уязвимостей и утечек за пару-тройку недель работы я вполне представляю. Безо всякого EE можно обойтись.

Пара-тройка недель -- для C++ это даже многовато будет.

>> Я говорю о себе. Как написать небольшой надежный standalone-сервачок под любой протокол на жабе без уязвимостей и утечек за пару-тройку недель работы я вполне представляю. Безо всякого EE можно обойтись.

>Пара-тройка недель -- для C++ это даже многовато будет.

Да ну не ври. Сервера вылизываются годами.

> Да ну не ври. Сервера вылизываются годами.

O_O

> Но после внимательного прочтения http://absurdopedia.wikia.com/wiki/Haskell Изумительно изложено... :D:D:D

...Haskell номинируется на звание «природного врага № 1 риальных пацанов от программирования» ...

И вправду, изложено отменно.

> Да ну не ври.

Не я первый начал.

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

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

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

weak_ptr<MMappedArea> + shared_ptr<MMappedArea> спасут отца русской демократии.

>synchronized (this)

Итак, ты жабофил? Ну тогда скажи мне, а зачем это в java 5 появилась куча всего в java.util.concurrent? Что, synchronized не справлялся водиночку?

> Нет неправильно. Это не только мой опыт.

Очень странно. К чему тогда было упоминание про одну многопоточную программу на C++?

Intel, к примеру, для C++ поддерживает OpenMP, выпустил Thread Building Block, прикупил RapidMind и Cilk++. Вряд ли все это от того, что в C++ многопоточность не есть сильное место.

> Для некоторых задач таки лучше.

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

> Только не причислил ли ты меня к клубу явофилов?

Нет, но создалось впечатление о не очень четком представлении о возможностях C++.

>Пойди разработчикам софта для телекома это расскажи, Петросян.

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

>Кстати, ejabberd отлично масштабируется в отличие от плюсовых аналогов.

Ходят слухи, что плюсовая серверная часть mail.ru агента держит всю нагрузку на кластере из 3-5 машин, в то время как ejabber'у для такого понядобится больше десятка серверов. Осмелюсь предположить, что без масштабируемости эта поделка никому вообще нафиг не сдалась, ибо там, где плюсовый сервер обходится одной машиной, тормозному эрлангу нужен хотя бы пяток.

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

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

Писать надо как можно проще и яснее. Сложность и совершенство кода придут сами. Но не на С++, конечно. На Си/Паскале - да.

>Воистину быдлокодер!

Типичное надменно-подозрительное отнощение плюсофага к своим коллегам.

>Как написать небольшой надежный standalone-сервачок под любой протокол на жабе без уязвимостей и утечек за пару-тройку недель работы я вполне представляю.

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

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

a) Я так понимаю, ссылки, подтверждающей соотношение скоростей С++ vs эрланг в телекоммуникации, мы традиционно не дождёмся?

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

> a) Я так понимаю, ссылки, подтверждающей соотношение скоростей С++ vs эрланг в телекоммуникации, мы традиционно не дождёмся?

Этот же вопрос следует адресовать и Erlang-истом. А то ведь поставщиков телекоммуникационного оборудования кроме Ericsson-а еще с несколько штук наберется, а Erlang используется только у Ericsson-а. И таки да, объем кода на C++ и Java в том же знаменитом роутере Ericsson-е был очень немаленьким.

Так что слухи о безнадежном отставании всего от Erlang-а в области телекома нуждаются в доказательстве.

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

В США или России? В Москве приличный сервер стоит в районе $10K -- даже для программистов за $4K в месяц -- это больше двух с половиной месяцев работы. А уж кластер из десятка таких машин...

Или в Google на их сотнях тысяч PIII-PIV машинок исключительно Erlang крутится?

> Так что слухи о безнадежном отставании всего от Erlang-а в области телекома нуждаются в доказательстве.

И тут мы имеем дело с изящной переформулировкой проблемы:

было: да ваше ФП вообще нигде и никогда не используется

стало: А ну ка докажи, что ФП ещё не окончательно вытеснило С++

Сама возможность такой постановки проблемы говорит о многом.

> Вроде как эрланг был зачат для решения каких-то приватных проблем.

И что с того?

> Больше он мало на что годится.

Он годится для написания высоконадёжных многопоточных масштабируемых систем. Этого мало?

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

Мой посыл был в том, что наличие такой прослойки как виртуальная машина заметно упрощает написание многопоточных приложений. Не любых конечно. Числодробилки - это отдельная история. Erlang - тоже. Вообще, многопоточность бывает разной. Я имею ввиду, главным образом, написание бизнес-логики, обработку транзакций и прочие прелести серверного программирования. Раньше в этой нише использовались Corba-серверы, которые как правило были написаны на Си++. Но потом их место прочно заняли серверы приложений на Java. Не просто так. А свои впечатления оставь при себе.

> Сама возможность такой постановки проблемы говорит о многом.

Вы сделали такую постановку, вам лучше знать.

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

>Erlang используется только у Ericsson-а.

Эриксон все таки ведущий разработчик телекома, и потом конечно там будет использоваться эрланг потому что эриксон его и придумал, а ведь он это сделал неспроста, подумай (отвлекись от фанатизма и троллинга) %) Наверное не потому что надо было бюджет попилить, а ? Вот есть такой мужик, правда на лоре его ненавидят большинство (правда непонятно за что) Никлаус Вирт, вот он как и энштейн придерживается правила «Делай просто, насколько возможно, но не проще этого».

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

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

Ну и про мейл.ру - очень неудачный пример. Посмотри сколько их клиент жрет памяти хотя бы. Это же пездец. На яве и то было бы меньше %) Ну а то что там в мейл.ру менеджеры по найму персонала не слышали про эрланг - хуле, у нас в стране вообще зачастую как дело делается, главное бабла выбить, а там хоть потоп, а институты и пту рожают только дельфистов и наСильников в основном. Аргументация типа "язык - говно, ибо на нем редко пишут" убога и уныла. Я так же могу сказать "линукс - говно, потому что везде стоит виндоус виста (c) (tm)".

> А свои впечатления оставь при себе.

Да не вопрос. Примеры задач со сложными графами объектов таки будут или нет?

> В США или России? В Москве приличный сервер стоит в районе $10K -- даже для программистов за $4K в месяц -- это больше двух с половиной месяцев работы. А уж кластер из десятка таких машин...

> Или в Google на их сотнях тысяч PIII-PIV машинок исключительно Erlang крутится?

А что, у Гугла в датацентрах дорогие сервера стоят?

> Эриксон все таки ведущий разработчик телекома, и потом конечно там будет использоваться эрланг потому что эриксон его и придумал, а ведь он это сделал неспроста, подумай (отвлекись от фанатизма и троллинга) %) Наверное не потому что надо было бюджет попилить, а ?

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

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