LINUX.ORG.RU

Зачем используют C++?

 ,


2

7

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

Сравнение Erlang и C++ по производительности

Хотя опытные Erlang-программисты давно заметили, что их программы для тех же задач получаются более краткими по сравнению с другими широко используемыми в промышленности языками программирования, эмпирическое исследование показало, что для изученных телекоммуникационных приложений код на Erlang был на 70-85 % короче, чем на С++, а производительность системы при переписывании кода с С++ на Erlang возросла почти на 100 %[137][138]. Для одного из использованных в исследовании проектов разница была объяснена написанием дополнительного С++-кода в рамках защитного программирования, управления памятью и кода для высокоуровневой коммуникации, то есть возможностями, которые являются частью языка Erlang и библиотек OTP[138].

Как такое возможно? Почему заточенный на производительность ЯП слил высокоуровневому 100%(!)? Может тут ошибка? Может наоборот?



Последнее исправление: beastie (всего исправлений: 2)

Как такое возможно? Почему заточенный на производительность ЯП слил высокоуровневому 100%(!)? Может тут ошибка? Может наоборот?

Потому что это аутотренинг ерлангистов. А вообще почитайте этот тред:

Запилите кто-нибудь нормальный обзор Rust

EXL ★★★★★
()

так никто же кода не приводит по ссылкам ([137][138]). просто утверждается что производительность возросла. проверить невозможно.

rupert ★★★★★
()

Потому что C++ не «заточен» на производительность. Страуструп учитывал это как параметр, но не как основную задачу.
Потому что ты не будешь пенисом пытаться просверлить отверстие в доске, например. Много «потому что».

Solace ★★
()

потому-что Erlang нишевый язык и в своей нише я бы сказал он - лучший. А C++ general purpose. Только когда тебе нужно дробить числа, то Erlang можно выкидывать на помойку.

umren ★★★★★
()
Ответ на: комментарий от rupert

Ага. Мне в своё время в Wiki-попалась такая шняга от апологетов Java:

В конце 2005 г. движок "Quake II" был переписан на Java, в результате чего родился новый 3D-движок — "Jake2". По заявлению разработчиков, Java-версия лишь ненамного уступала по производительности оригинальному коду, написанному на C. Однако, после проведения дополнительных оптимизаций Java-версия даже превзошла оригинальную версию по производительности.

И далее линк на http://bytonic.de/html/benchmarks.html где видно, что Java сливает Native C code.

EXL ★★★★★
()

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

Сам же процитировал. Все так и есть.

unfo ★★★★★
()

Зачем использовать С++ - этому вопросу посвящена целая глава у Страуструпа. Почему бы не прочитать ее?

Deleted
()

Как такое возможно? Почему заточенный на производительность ЯП слил высокоуровневому 100%(!)? Может тут ошибка? Может наоборот?

Может и ошибка. Скорее просто на c++ был говнокод. Эрланг это почти DSL же. Возможно, сложность написания не говнокода на c++, для этой задачи стремится к бесконечности.

Kuzy ★★★
()

лол

Для одного из использованных в исследовании проектов разница была объяснена написанием дополнительного С++-кода в рамках защитного программирования, управления памятью и кода для высокоуровневой коммуникации, то есть возможностями, которые являются частью языка Erlang и библиотек OTP[138].

Мы накостыляли свою кривую копию erlang-а на c++ и очень удивились, когда обнаружили, что она работает медленнее erlang-а.

Kuzy ★★★
()
Последнее исправление: Kuzy (всего исправлений: 1)

Емое 10 комментов, ни одного нормального ответа.

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

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Емое 10 комментов, ни одного нормального ответа.

Так среди них нет ни одного от nanoolinux.

Shadow1251
()
Ответ на: комментарий от Solace

Страуструп учитывал это как параметр, но не как основную задачу.

Zero-overhead одна из основных задач.

Что?

Kuzy ★★★
()
Ответ на: комментарий от Hertz

А нишевых языков не так уж прям много, как тебе кажется. PHP, Erlang сами себя в рамки вогнали, но и держатся там неплохо. Я то вообще считаю, что C++ себя уже изжил и должен отмирать так же как Perl и прочее (что и происходит).

umren ★★★★★
()

Ибо нефиг.

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

Не не видел. Те же дотнеты гораздо противней :)

batbko
()
Ответ на: комментарий от EXL

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

next_time ★★★★★
()
Ответ на: комментарий от unfo

дополнительного С++-кода в рамках защитного программирования

В общем, понятно. Кучу ненужного говна на С++ написали, а потом удивляются, что-то оно у них медленно работает.

rupert ★★★★★
()

На С/С++ качественно распараллелить программу - задача не из легких, а в Erlang'e, который создавался именно для таких задач, эта проблема естественным образом решается. Создание пула acceptor'ов для TCP-сервера в Erlang'e - дело 20 минут даже для джуниора, в C/C++ придется потратить гораздо больше времени на разработку и далеко не факт что будет работать это лучше erlang-версии. В общем, победить Erlang в его нише действительно трудно, настолько, что проще его сразу и использовать там где это может выстрелить.

NegatiV
()
Ответ на: комментарий от rupert

Мсье умеет С++ без защитного программирования? Рассмешил.

NegatiV
()
Последнее исправление: NegatiV (всего исправлений: 1)
Ответ на: комментарий от next_time

Это всё аутотренинг Java-кодеров. Я скачивал их Jake 2 и ради интереса сравнивал производительность с нативным и ванильным id Software's Quake II. Просадка Jake 2 была >= 65%. Не знаю, как они достигли тех результатов, которые у них представлены в таблице. Хотя нужно отдать им должное, потрудились с оптимизациями они на славу. Оно даже играбельно, в отличие, от Minecraft'а, например.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

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

umren ★★★★★
()

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

Как четко ты ерланг описал!

comp00 ★★★★
()
Ответ на: комментарий от NegatiV

в C/C++ придется потратить гораздо больше времени на разработку и далеко не факт что будет работать это лучше erlang-версии.

Вот во что я не поверю, так это в отсутствие _либы_ С/С++, которая делает эрланг по скорости. А писать каждый раз с нуля - удел идиотов.

Pavval ★★★★★
()

Как такое возможно? Почему заточенный на производительность ЯП слил высокоуровневому 100%(!)? Может тут ошибка? Может наоборот?

Почему птица летит на 100% выше самолёта? Либо ошибка, либо самолёт специально летит низко.

anonymous
()

Всегда можно найти идиотский говнокод на C++, при грамотном переписывании которого даже на Basic скорость возрастёт на 100%. Что это даказывает? Только то что с помощью С++ можно писать и очень хороший код и очень плохой. А что, мы этого раньше не знали?

mbivanyuk ★★★★★
()
Ответ на: комментарий от NegatiV

С каких про, скажи мне, С++ стал уродливым и многословным??? В плане синтаксического сахара он просто прекрасен, и код на нем красивый и эстетичный.

comp00 ★★★★
()
Ответ на: комментарий от comp00

В плане синтаксического сахара он просто прекрасен, и код на нем красивый и эстетичный.

По сравнению с брейнфаком - вполне возможно.

mono ★★★★★
()
Ответ на: комментарий от EXL

Однако, после проведения дополнительных оптимизаций Java-версия даже превзошла оригинальную версию по производительности.

Про жабку так всегда пишут. Что на ней можно писать быстрый не жрущий код, что тормоза явы - это явный миф и неправда, что она даже в некоторых случаях превосходит си и плюсы. Только этого никто никогда не видел, и, скорее всего, речь про java-asm :D

anonymous
()
Ответ на: комментарий от anonymous

возьмите уже лопату да закопайте этот ерланг

лучше автора этой лопатой по голове погладить за толстые вбросы

anonymous
()
Ответ на: комментарий от anonymous

Ебланг даже таких усилий не стоит. Пусть гниет себе на помойке.

anonymous
()
Ответ на: комментарий от comp00

С++ стал уродливым и многословным???

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

anatoly
()
Ответ на: комментарий от anatoly

А вот утверждение про многословность поддержу.

И чем же он так многословен? В языке нет ничего лишнего, любую операцию можно представить в виде совокупности примитивов. Нужен более высокий уровень абстракций? Используй boost, Qt, c++11. С++ по дефолту низкоуровневый язык:m там не нужен изкоробочный ORM и коннекшены в 2 строчки.

anonymous
()
Ответ на: комментарий от anonymous

В C++ недостаточно возможностей для создания более высокоуровневых абстракций. D и Rust это пытаются исправить.

anonymous
()
Ответ на: комментарий от anatoly

Многословность = текучие абстракции. Это никаким образом не связано с «мощностью» языка.

anonymous
()
Ответ на: комментарий от Pavval

Верь или не верь, но там где нужен функционал Erlang'a лучше его и использовать. Хотя, допустим, скрестить libev и libcppa/CAF можно попытаться, но задача эта, имхо, для больных на голову. В жизни не пропустят в продакшн такое дерьмо:

void client(event_based_actor* self, const actor& master) {
    become ( 
        on("foo", arg_match) >> [=](const string& request)
            return self->sync_send(master, atom("bar"), request).then( 
                on_arg_match >> [=](const std::string& response){
                    return response; 
                }
            );
        } 
    );
}; 
Если не ошибаюсь, это эквивалент эрланговскому коду:
receive 
    {Ref, Master, foo, Msg } -> Master ! {Ref, self(), bar, Msg}
end.

NegatiV
()
Ответ на: комментарий от comp00

С каких это пор стало нормой менять тезис разговора? Я что-либо говорил о C++? Нет, я просто поправил тебя, ибо назвать Erlang уродливым и многословным может только человек который его в глаза не видел. Яркий пример лаконичности и простоты кода на Erlang'e в моем посте выше.

NegatiV
()
Последнее исправление: NegatiV (всего исправлений: 1)
Ответ на: комментарий от Pavval

И да, много ли ты знаешь либ на С/С++ с реализацией легких нитей(шедулер, синхронизация, изоляция)? А то, знаешь, не хотелось бы чтобы одна нить могла повесить или убить всю программу. Имхо, пока ты на С++ напишешь подобное, или слепишь чудовище франкенштейна из того что есть, десять раз пожалеешь что выбрал напильник там где нужна цепная пила.

NegatiV
()
Ответ на: комментарий от NegatiV

но там где нужен функционал Erlang'a лучше его и использовать

и где же нужно его использовать?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.