LINUX.ORG.RU

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

 ,


2

7

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

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

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

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



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

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

«c c++ program» пишут в том числе и криворукие школьники, а ты их зачем-то сравниваешь с авторами «erlang vm» :)

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

Именно потому игр под Linux раз два и обчёлся. А те что есь большинством своим так или иначе юзают вино или прослойку от Valve. Казуалки не в счёт.

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

Ну так ты ссылайся на потенциальные ошибки, которые можно совершить в эрланговском коде, а не ошибки VM. Если у тебя будет компилятор который генерит неправильный код, то хоть обоссысь писать сколько угодно правильно - программа будет работать неверно. Я не рассматриваю ошибки окружения, в котором программа должна работать, например, open( ... ) должен открыть файл, а не затереть диск нулями, а inet:close/1 закрыть сокет, а не повесить VM.

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

об этом была предыдущая ссылка же :)

меня не интересуют потенциальные ошибки. любой квалифицированный программист на С/С++ реализует зелёные потоки за 1 день; эрланг за такое время выучить не выйдет.

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

любой квалифицированный программист на С/С++ реализует зелёные потоки за 1 день;

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

anonymous
()
Ответ на: kernel.org? от anonymous

Не, ну ты идиот, или как? Зеленые нити легче. Зеленых нитей в VM можно создать десятки тысяч. А ядреные нити очень тяжелые. Так что иди, ламер, гуляй, ты обосрался.

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

пьют чай [...] ссыт [...] блюя [...] мочатся быдлу в рот

У вас не в том месте полыхнуло. Что, впрочем, понятно - текст писал человек с негативным опытом в оральной фазе

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

anonymous
()
Ответ на: kernel.org? от anonymous

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

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

у которых эти самые треды могут свалить всю программу или заблочить поток-шедулер в блокирующей операции

И давно «пользователь» зеленых потоков может вставлять код в _поток_ планировщика?

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

Результатов: примерно 82 000 000 (0,53 сек.)

Да, прикинь - на плюсах, в отличие от, кто-то пишет.

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

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

Это каким идиотом нужно быть, чтобы _случайно_ вызвать ExitThread?

З.Ы. И да, его вызов можно заблочить.

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

похоже, идиот таки ты

зелёные нити не могут быть вытесняемыми. ты спрашиваешь реализовал ли кто-то на крестах «редукции» (как в эрланге) или хуки на аллокацию памяти (как в хаскеле)? зачем?

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

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

Тебе рассказать, как при помощи get/setcontext() и сигналов реализуется вытесняющая многозадачность?

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

Не надо мне ничего рассказывать. Покажи работающую реализацию - или заткнись.

anonymous
()
Ответ на: похоже, идиот таки ты от anonymous

зелёные нити не могут быть вытесняемыми.

Какое же ты быдло - это что-то.

Вот «не могут», и все тут. А ничего, что в Erlang они вытесняемые? Да что там Erlang, в старой-престарой JVM они тоже были вытесняемыми. С VM это делается элементарно.

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

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

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

В винде (о которой идет речь) fiber'ы крутятся в потоке шедулера (та-дам!).

Спасибо, не знал. Гы.

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

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

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

Или даже stl. А есть же проекты, в которых stl’и ... запрещены.

Ээ как так? Это же стандартная библиотека и идёт в поставке с компилятором.

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

И что? Exceptions тоже стандартная фича языка. И тоже запрещены почти в любом ынтырпрайзном проекте.

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

Какой-то очень подозрительный результат. Ada на первом месте? Слабо верится. С# на моно быстрее С++? Вообще не верится.

Рукалицо, это список ЯП в алфавитном порядке, из которого уже можно выбрать один язык и сравнить с другим.

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

Это же стандартная библиотека и идёт в поставке с компилятором.

Которую никто не запрещает не использовать. Т.к. все равно есть libc, и даже средства ОС как альтернатива.

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

Именно потому игр под Linux раз два и обчёлся.

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

А те что есь большинством своим так или иначе юзают вино или прослойку от Valve

4.2 наглейшее. Игры на идтех не юзают, метро не юзает, икском, анрил и любые потенциальные игры на AE не юзают, парадоксоигры не юзают, крайэнжн поддерживает огл, большинство инди тоже. Прослойку от валв юзает одна валв, вайн/еон юзают два с половиной калеки.

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

если бы ты умело читать, то увидело, что я написал как они «вытесняются» в эрланге (и в хаскеле для разнообразия). тупым макакам (тебе с негативом, например), которые не могут вовремя переключиться и не понимают как переключается контекст, надо использовать эрланг или ещё какую поделку. хотя бы для того чтобы я случайно ваш код не увидел.

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

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

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

Единственная блокирующая операция - вызов NIF'a/драйвера. Но тут уже ничего не поделаешь ни в Erlang'e, ни в С/С++.

NegatiV
()

Может тут ошибка?

Да не: кто-то вроде меня пейсал С++.

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

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

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

Переключение потока планировщика, а не целевого. И только при вытеснении - нормальный асинхронный код самостоятельно будет отдавать управление в 99.9% случаев.

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

негативу нормальный код не нужен :)

ему надо чтобы за криворукую обезьяну кто-то другой переключал.

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

Frostbite Engine, CryEngine, Unreal Engine, OpenGL не умеют. Из нормальных движков только Unity умеет OpenGL без костылей. Да, все движки фирмы Ubisoft его не умеют, и я объясню, почему: на OpenGL писать трудно, писанины гораздо больше, чем с DirectX.

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

CryEngine, Unreal Engine

крайтек портировала свой движок на линукс, уже анонсиованы игры для линукс на крайэнжн, целый ворох игр на Unreal engine есть на линукс от древних ут2004 и америкас арми до нового анрила и икском

OpenGL не умеют

Мда.

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

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

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

Переключение потока планировщика, а не целевого. И только при вытеснении - нормальный асинхронный код самостоятельно будет отдавать управление в 99.9% случаев

Что такое «нормальный асинхронный код»? Некий сферический конь в вакууме? Видимо придется carb_blog10 давать ТЗ на реализацию либы с green threads + non-blocking I/O + preemptive multitasking. А то вас послушать, так это как два пальца об асфальт.

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

Понимаешь в чем штука - я смешаю тебя с говном и без «green threads + non-blocking I/O + preemptive multitasking.».

И ты забыл условия? ТЗ должно описывать полезное действие, т.е. реальную систему с реальными задачами. Причем описываешь ты задачу, а не условия реализации и не абстрактную муру.

Мне твой пердёж и юлёж нахрен не нужен. Съехал с плюсов, теперь поплыл и с условий?

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

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

У пацана просто случилось «non-blocking I/O». Рили?

Ну давай, скажи мне что в твоём понимании «non-blocking I/O», зачем оно нужно, а потом я тебе расскажу как это делается по-пацаночке.

Это не буферизация, не кеширование, ни скидывание ИО в отдельный воркер - это всё делается на уровне ОС. Что для вас «non-blocking I/O»?

Только не сливайся на гугл/книжки/кого-то. Отвечай прямой.

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

Ну так покажи мне нормальный код с green threads + non-blocking I/O + preemptive multitasking. На С/С++.

Какой смысл от green threads в C/C++?

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

Ну давай, скажи мне что в твоём понимании «non-blocking I/O», зачем оно нужно, а потом я тебе расскажу как это делается по-пацаночке.

Не съезжай. Что ты не можешь в green threads я уже понял.

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