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

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

Efficient C++ Performance Programming Techniques

By Dov Bulka, David Mayhew

>>Практика показывает, что сишный код, _как правило_, быстрее сиПиПишного.

> Так, еще один.

> http://pastebin.com/m18049091

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

"Как правило, сишный код быстрее окамлового"

>Чтобы у тебя не было никаких сомнений, напомню, что указатель мог быть не 16-битным, а 32-битным (far pointer -- segment + offset) и с NULL нет абсолютно никаких проблем.

Бугогец. Во-первых начнем с того что стандартного С++ под чистый ДОС нет. Borland C++ был совсем другим языком. В нем даже неймспейсов и исключений не было.

>>Это похоже на ручную коробку передач с одной-единственной передачей.

>Сдается мне, ты понятия не имеешь о замечательных языках C и C++.

Плюсофильское обвининие в ниасиливании. Засчитываем автоматический слив.

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

Отчасти. Говорю только о том, что знаю сам. Для проекта Firefox есть расширение "Fasterfox". Написано на основании того, что FF (и Mozilla) это прежде всего "платформа".

В принципе, если скачать http://fasterfox.mozdev.org/ файл .xpi и раззиповать его, то там будет энное число всякой фигни. Ну, в частности fasterfox.js, в котором перечислены pref-установки. Таким образом изменяется вариант работы FF в части (например HTTP):

// HTTP Connection Prefs pref("network.http.max-connections", 48); pref("network.http.max-connections-per-server", 24); pref("network.http.max-persistent-connections-per-server", 8); pref("network.http.max-persistent-connections-per-proxy", 16); //pref("network.ftp.idleConnectionTimeout", 60); //pref("network.http.keep-alive.timeout", 30);

// HTTP Pipelining Prefs pref("network.http.pipelining", true); pref("network.http.pipelining.firstrequest", true); pref("network.http.proxy.pipelining", true); pref("network.http.pipelining.maxrequests", 8);

Это просто пример.

Касаемо "оптимизации" Mozilla, я бы рекомендовал обратить внимание ещё на 2 метода оптимизации.

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

Во-вторых, есть один не бесспорный момент, который сейчас вызовет бурю флейма. Проблема в том, что вообще-то, мозилла и ФФ по-дефолту написаны с применением таких библиотек как GTK+. Отсюда два варианта -- либо используем среду с GTK+, либо перед загрузкой мозиллы (фф) загружаем что-нибудь маленькое, но очень GTK'шное. В этом случае система вынуждена подгрузить библиотеки GTK+ (пусть не все, но некоторую их часть), которые используются и в мозилле в том числе. При старте мозиллы, в таком случае, некоторая часть библиотек уже будет загружена в память (если они не используются ни чем, то они просто лежат на диске), и суммарное время загрузки мозиллы уменьшится. Можете проверить. Кстати, с ОО аналогично.

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

Я, если честно, со всем этим проблем не испытываю, ибо GNOME. Со всеми вытекающими.

>>Отсутствие сборщика мусора и вправду много чего затрудняет.

>Нет. А вот отсутствие нормальных деструкторов в некоторых якобы труЪ-ООП языках - затрудняет.

Нуну... Часто приходиться возвращать копию объекта, иначе память потечет.

> Нуну... Часто приходиться возвращать копию объекта, иначе память потечет.

Э-э-э, не понял... Можно поподробнее?

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

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

Фишка (в части Mozilla extensions) в том, что расширения становятся (могут стать, если их именно так и писать), частью интерфейса мозиллы. Т.е., меню, тулбар, основное окно браузера расширяются за счёт предоставляемых Вами элементов интерфейса. Они, в свою очередь, ассоциируются с веб-приложением. Т.е., юзер выбирает в тулбаре браузера объект (объекты), скрипт обращается к FastCGI (на С писано, скажу сразу), оттуда возвращается обработанный результат в основное окно браузера. Что возвращается? А не важно -- картинка, JSON-данные, ... Всё, то Вам заблагорассудится.

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

> Для проекта Firefox есть расширение "Fasterfox"

Благодарю. Посмотрю что это.

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

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

> Отсюда два варианта -- либо используем среду с GTK+, либо перед загрузкой мозиллы (фф) загружаем что-нибудь маленькое, но очень GTK'шное.

Я не про это. Через пару дней активного лазанья по сети браузер начинает тормозить, будто он не странички показывает, а погоду на год вперёд расчитывает.

Мой далёкий недалёкий друг, незачто...

> расширения становятся (могут стать, если их именно так и писать), частью интерфейса мозиллы.

Так это только для самых простых "программ" верно.

> "клиента" написать при таком подходе -- на раз-два.

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

P.S. Про скорость и ресурсоёмкость. Простейшие флэш-игры способны затормозить нормальный комп до уровня спектрума.

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

Вообще говоря, у мозиллы и более лёгкого Firefox'а есть довольно много расширений. Есть и для web-его мать-девелопмента и для удобства и для просмотра IP-адреса, заголовка, платформы веб-сервера. Много чего есть. На самом деле.

Касаемо обрезания рекламы, то я бы рекомендовал сделать её резку либо на проксе, либо (в моём случае это работает) на "аппаратном уровне" -- на Cisco PIX/ASA. Через механизм блокирования по regexp просто загоняются баннерные сети и прокс работает только на кэширование.

> Я не про это. Через пару дней активного лазанья по сети браузер начинает тормозить, будто он не странички показывает, а погоду на год вперёд расчитывает.

Извините. Возможно, так оно и есть. Но у меня с ним всё ровно. Кстати, в приведённом мною файле (откуда там строчки взяты) есть параметры управления кешем. Посмотрите расширение, надеюсь что оно Вам поможет.

> Так это только для самых простых "программ" верно.

Немного не соглашусь. Уж извините. =)

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

Пардон. Я не об этом. Я о "трудоёмкости" написания. Я не сказал ни чего например о том, что есть такая вещь как Yahoo User Interface (это javascript's widgets, которые свободно могут интегрироваться в код страницы).

Трудозатраты в таком случае падают в разы. Да. С сервером секесу много. Но я избавился от секеса в части прикладной пользовательской реализации.

Про флеш не знаю откровенно говоря ничего. Окромя того, что есть библиотека ming для генерации флеша "на лету".

>Э-э-э, не понял... Можно поподробнее?

Функция не может возвращать ссылку на созданный в теле функции объект. То есть может, но тогда его надо явно создавать с new, а значит и явно после этого удалять. И уже нельзя написать так: add(a, add(b, c)) или a+b+c. Паямять потечет. Значит возвращать приходиться сам объект, что может создавать лишние копии, которых можно было бы избежать в языках со сборщиком мусора.

>В реальном мире никто не будет сидеть и добиваться ортогональности деструкторов

Ну конечно. А ещё в реальном мире никто не пишет pure-функции и соответственно не использует функциональные языки, ага.

>Тупое пихание const везде

...дающее неиллюзорный профит в виде производительности и дополнительных compile-time проверках.

>Тред не читал, о чем тред?

Об особенностях приготовления пива.

>>Он дает прирост производительности в 6 раз?

>На вычислениях с плавающей точкой -- легко.

Пруфлинк или небыло.

Вот мои источники говорят другое: http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html

Там разница меньше 15% (Да, проц от интел =)

>>Тупое пихание const везде

>...дающее неиллюзорный профит в виде производительности

На практике const профита не приносит, т.к компилятор и так видит какие переменные изменяются в локальном контексте. А в глобальном контексте const- объект может изменяться при вызове функции из любой другой единицы компиляции, так как в другой единице компиляции может быть законная не-const ссылка на тот же самый объект.

>дополнительных compile-time проверках.

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

>>В реальном мире никто не будет сидеть и добиваться ортогональности деструкторов

>Ну конечно. А ещё в реальном мире никто не пишет pure-функции

Все нормальные программисты пишут pure-функции. Это замечательные островки надежности в любой программе.

>И уже нельзя написать так: add(a, add(b, c)) или a+b+c. Паямять потечет.

Умные указатели полностью снимают проблему.

>Значит возвращать приходиться сам объект, что может создавать лишние копии

Был такой косячок с лишними копиями. В новом стандарте это исправили, введя семантику перемещения в дополнение к копированию.

>Все нормальные программисты пишут pure-функции. Это замечательные островки надежности в любой программе.

Наряду с const-методами и const-аргументами функций.

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

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

б) И вообще, смарт-указатели - говно.

> На практике const профита не приносит, т.к компилятор и так видит какие переменные изменяются в локальном контексте.

gcc видит далеко не всегда... <troll mode="on">C++ -- это такой язык, в котором даже компилятор толком разобраться не модет.</troll> 8))

>Кто тебе даст пересадить всех на нестандартное ПО?

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

>>Все нормальные программисты пишут pure-функции. Это замечательные островки надежности в любой программе.

>Наряду с const-методами и const-аргументами функций.

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

А const-методы это типичная плюсовая фигня которая не делает ничего кроме бесполезной декорации тривиального действия. Вместо того чтобы просто описать поле объекта я должен еще обеспечить фан вида getXXX() const/setXXX().

>владелец игрушкописательной конторы. По молодости был ярым крестовиком, всё на крестах ваяли. Но потом сдался, перешли на сишарп

Кармак?

>Во-первых начнем с того что стандартного С++ под чистый ДОС нет.

Ах извини, что в 1991 году ничего не знали о стандарте C++, который примут в 1998. Да и STL тогда был весьма зачаточный. Для своего времени bc 3.1 был замечательным продуктом.

>Часто приходиться возвращать копию объекта, иначе память потечет.

1. std::auto_ptr

2. void some_proc(int input,Object &result)

Проблема явно в голове.

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

А от хорошей ли жизни у нас появилось расширение XShm? Помнится, я когда-то очень давно пробовал вот так вот удаленно freecraft запустить. И послало меня далеко и надолго со словами XShmCreateImage failed. Не все так прозрачно, как кажется на первый взгляд.

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

Причем в иксах это заметней, чем в винде.

>Вот мои источники говорят другое: http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html

Дети как всегда лезут со своими "пруфлинками", даже не имея понятия о том, что там происходит. Довожу до твоего ведома, что ffmpeg изобилует ассемблерными вставками для повышения производительности. Соответственно, все критические места уже оптимизированы. Я вспоминаю какую-то давнишнюю статью, в которой icc уделал и msvc и gcc толи на порядок, толи даже чуть больше. К сожалению, за давностью лет эту статью проблематично отрыть -- она похоронена под такими вот "обзорами" gcc vs icc: compiling x264.S

>1. std::auto_ptr

>2. void some_proc(int input,Object &result)

>Проблема явно в голове.

1.То есть сборка мусора все-же нужна. А ведь и смарт поинтеры все-же кривенькие.

2. В том-то и есть весь прикол... Сравни:

a+b+c

vs

Object tmp; some_proc(a, b, tmp); some_proc(tmp, c, tmp);

>Все нормальные программисты пишут pure-функции.

Если ты когда-либо использовал внутри функции вывод на консоль (printf, print, echo), это уже не pure-функция. Pure функций исчезающе мало.

>Дети как всегда лезут со своими "пруфлинками", даже не имея понятия о том, что там происходит. Довожу до твоего ведома, что ffmpeg изобилует ассемблерными вставками для повышения производительности. Соответственно, все критические места уже оптимизированы. Я вспоминаю какую-то давнишнюю статью, в которой icc уделал и msvc и gcc толи на порядок, толи даже чуть больше. К сожалению, за давностью лет эту статью проблематично отрыть -- она похоронена под такими вот "обзорами" gcc vs icc: compiling x264.S

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

Добавлю что были так же (окромя bc) Watcom C/C++, Microsoft C/C++ 7.0 (не путать с DevStudio и иже с ним), Zortech C/C++, позже померший в Симантеке. Top Speed C/C++ (чумовой компилятор). Да. STL, уж извините, и не пахло. Но, вообще-то, не STL'ем единым... Ну и буста не было. И чё дальше?

Всё нормально в DOS'е с С++ было...

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

А определение, очевидно, порождено твоим плюсофобским параноидальным сознанием? Everything leaks but gc. Блаженны верующие, ибо их есть <чего-то хорошее>.

>б) И вообще, смарт-указатели - говно.

Слова убежденного ниасилятора.

>Если ты когда-либо использовал внутри функции вывод на консоль (printf, print, echo), это уже не pure-функция.

Спасибо, К.О.

>Pure функций исчезающе мало.

Мне очень жаль, что ты так пишешь.

>Вместо того чтобы просто описать поле объекта я должен еще обеспечить фан вида getXXX() const/setXXX().

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

>Object tmp; some_proc(a, b, tmp); some_proc(tmp, c, tmp);

Никогда не думал, что дойду до такого, но google: C++ template expressions. http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Expression-template

>Всё нормально в DOS'е с С++ было...

Сейчас местные эксперты еще нажалуются, что в C++ под досом не было поддержки многопоточности.

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

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

> Сейчас местные эксперты еще нажалуются, что в C++ под досом не было поддержки многопоточности.

Угу. Кстати. Вопрос хош? ;)

Вот смотри. Что идиологически более правильно пользовать -- механизмы boost или QThread, QSocket и иже с ним? ;)

> Сейчас местные эксперты еще нажалуются, что в C++ под досом не было поддержки многопоточности.

Кстати, да. В C++ нет поддержки многопоточности! Закопайте! 8))

>Что идиологически более правильно пользовать -- механизмы boost или QThread, QSocket и иже с ним? ;)

Лично я за boost::thread

>В C++ нет поддержки многопоточности! Закопайте! 8))

Срочно закапывайте петун за global interpreter lock. Кстати, заодно и перл можно. В нем ведь тоже как-то кривовато с потоками. Да и C можно закопать, в принципе: в стандарте ни слова о потоках.

Ну да... тебя не обманешь... ты этот спор, по-моему уже видел... :D:D:D
На самом деле, если учесть то, что бОльшая часть механизмов буста будет включена в очередной стандарт С++ на уровне именно "стандартной", а не "внешней" библиотеки, то выбор вполне толковый. Но тогда вопрос -- кули с Q* делать? =)))

>Никогда не думал, что дойду до такого, но google: C++ template expressions. http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Expression-template

Is this man serious?

>кули с Q* делать? =)))

В свете LGPL'изации, QT можно помиловать.

Кстати, а давайте вспомним, какие костыли в языках с GC для контроля жизни объектов. Навскидку вспоминается finally в Java, множественные костыли и IDisposable в C#. Чего только не напридумывают. А всего-то требовалось следить за тем, чтобы каждому malloc соответствовал free на выходе. Индустрия программирования для домохозяек еще не придумала инструмента для слежения за "утекающими дескрипторами"?

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

Покупаешь full suspension bike, броню, едешь в горы => эмоциональный профит.

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

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