- 1
- 2
- 3
- 4
- 5
XOR EBX,EBX
MOV ECX,DWORD PTR SS:[EBP-168]
MOV DWORD PTR SS:[EBP-168],ECX
CMP EBX,DWORD PTR SS:[EBP-168]
JG ...-
Assembler / Говнокод #3271
+208
Запостил:
govnokod3r,
19 Мая 2010
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
b=c;
c=b;
if (a < c) goto...
но сути это не меняет
неплохо.
а что это? высер очередного "оптимизированого" компилера.
если так, то название и версию в студию.
А кроме шуток, это код из чего такой? Прикладной программе вроде ни к чему в 32-битном асме адресация 2 регистрами.
MOV DWORD PTR SS:[EBP-20],1
lp:
MOV EAX,DWORD PTR SS:[EBP-20]
MOV ECX,DWORD PTR SS:[EBP-150]
CMP EAX,ECX
JG el
;------------------------
; govnocode
;-----------------------
MOV ECX,DWORD PTR SS:[EBP-20]
MOV EAX,1
ADD ECX,EAX
MOV DWORD PTR SS:[EBP-20],ECX
JMP lp
el:
Мда, а у дельфы компилятор не так-то и плох, оказывается...
теперь ясно почему тот же алгоритм написаный просто на асме (без всяких твиков) раз в 10-20 быстрее работает чем на васике
>>делфя и ваcик одного сортира говно
эт точно
>>приводите аргументы, будем холиварить...
+1
а вот ПоХаПе, шарп, ява как раз хорошо заточены под быдлокодеров, там тебе и память подчистят, и переменную сконвертируют в любую другую, и производительность заранее просадят...
Помоему наоборот. Понимать сложнее.
сложнее он стать не сможет, в силу своей изначальной ограниченности. что этот новый стандарт привнесет - лямбды? так они уже 50(!) лет как используются, но только сейчас разрабы их осилили, тоже мне сложность)
а вот куда еще непонятнее - это вопрос, и без этого десятки 'гениальных' решений 'радуют', а теперь еще разнообразие добавят.
pushkoff C++ до конца не осилил. Ждём, пока осилит, если вообще сможет. На другие языки поэтому ему и плевать, так как с одним разобраться всё никак не может.
поэтому с точки зрения синтаксиса, С++ должны осилить даже полные имбицылы, и уверен, что все здесь осилили синтаксис С++, но при этом не многие могут похвастаться его успешным применением...
как раз наоборот, парадигма (теория) порождает синтаксис: лямбда-исчисление простая и мощная теория, следовательно и проецирование на синтаксис будет простым и мощным. в случае си можно сказать (с натяжкой через косвенные отношения машкод->асм->си), что это отображение страха на крыльях ночи - машин Тьюринга поэтому и получается пздц
вот что бывает, когда нет жесткой матосновы
и вовсе не лучшую скорость дает с++
в данный момент, если нужно разработать приложение где важна производительность и эффективная работа с памятью лучше выбора чем С++ нет... как и нет альтернатив этому выбору, так как на С и Ассемблере что-то большое и легкомодифицируемое при тех же требованиях к памяти и процу написать сложнее...
если хотите поспорить, начните с примеров: приложение, язык, аналоги на С++...
Hedgewars разрабатывается на различных языках программирования, в том числе: Free Pascal для движка, C++ для GUI, Haskell для сервера, Lua как скриптовый язык в картах.
стоит обратить внимание, что не движок на с++ написан, а всего-навсего гуй (это из-за qt)
Если не учитывать, что за guest сидят разные люди, то да.
Зато хватает ума у инсталятора, так что не надо тут хамалею плести.
Или у вас не хватает ума написать "умный" инсталятор?
Ты - гномосек? Или любитель винформ?
не гони. я опробовал моно + опегнл - получается пиздато и работает везде
кстати, есть unity3d, работает на макось и винду, для скриптинга юзает моно.
кстати симс3 для скриптинга тоже юзает моно, поставляется для макоси и винды. так что про некроссплатформенность сишарпа это лихо... (учитвыая что у моно приоретом линукс, а не макось)
наоборот мона крута, напр. если процессор поддерживает simd, то код будет компилироваться в simd-инструкции... куда уж круче сиплюса-то.
ну а насчет Unity3d, это как и с любым движком, единственное преимущество любого готового движка это первый результат практически сразу, но вот последний процент попьет крови сполна... может поэтому игр на нем не особо видно...
ты задрал. тебе же говорят, у моно есть потенциал. архитектура моно может (и уже в некоторых местах делает) подстраиваться под процессор и генерировать более эффективный код. в то же время выход с++компилера ориентируется на обобщённый процессор. например, если есть набор флоатов (важных для геймдева), то с++ будет как еблан их по очереди обрабатывать. а моно скопилирует в код, который будет обрабатывать параллельно (если процессор поддерживает).
> моно для казуалок
ну симс3 казуалка, ага. там практически всё написано на моно, кроме отрисовки вроде. я и не призываю самую лоу-левел отрисовку делать вм моно... хотя во времена шейдеров и это перестало быть актуально.
> отцы геймдева счас дерутся за то насколько стл медленный
правильно, быдло-стл постоянно копирует кучи данных туда-сюда как ебланка, хаха. прикинь копирования в каждом фрейме. в моно всё по ссылкам и оверхеда никакого нет.
кстати, в серьёзном геймдеве стл не юзается.
> то с++ будет как еблан их по очереди обрабатывать
вернись пожалуйста в 21 век... да и примеров неправильной векторизации тоже хватает... если в C# что-то работает быстро, значит на С++ это можно заставить работать еще быстрее...
> там практически всё написано на моно
можно сказать что в сталкере почти все написано на Луа, а он еще медленней... в Симс на С++ написана та часть кода которая работает 80% времеи и жрет 80% ресурсов...
> быдло-стл постоянно копирует кучи данных туда-сюда как ебланка
так только у ебланов... СТЛ это инструмент, и им надо уметь пользоваться...
> в моно всё по ссылкам и оверхеда никакого нет.
моно это и есть оверхед...
какой факт? в последнее время он стал активно продвигаться в геймдеве. снизу вверх. ты вообще ничгео не знаешь о моне, поэтому не говори о "фактах".
> в Симс на С++ написана та часть кода которая работает 80% времеи и жрет 80% ресурсов...
хаха, вот те быстрый с++))) отрисовать кадр - это нихуя не геймдев. это занятие обезьянок- ебаться с директиксом или опенгл. геймдев это в первую очередь создание геймплея, который как раз на 100% написан на моно.
> если в C# что-то работает быстро, значит на С++ это можно заставить работать еще быстрее...
ты пиздец упоротый... в с++ ПРИНЦИПИАЛЬНО нельзя сделать параллельные операции на флоатах. т.е. конечно можно, но в магазинах придётся продавать диски в верчсиях "для такого-то процессороа, где поддерживается", "для такого-то, где не поддерживается". Или во время инсталляции распаковать нужные прекомпиленные дллшки (десятки, лол...) Такое ощущение что имел дело только с с++, и то ка бы сказать не очень втянуто (только ипиздишь на говнокоде), атебе кто=-то сказал что с++ охуенно пиздат и ты веришь...
> так только у ебланов... СТЛ это инструмент, и им надо уметь пользоваться...
чо ты всё пиздишь общие вещи-то без конкретики. бля.... вс++ нет нормального менеджмента памяти поэтому хранить heapовые объекты в стле есть геморой, поэтому болшинство уебанов херачат копированиямитуда сюда... а если не херачат - то утчеки. российский геймдев ими особенно славится. зато неибацца крутые хакеры, осилили с++.. можно маме скзатаь, будет гордиться
4 года практики мне это сказали, и я им верю...
> вс++ нет нормального менеджмента памяти
в С++ самый нормальный менеджер памяти...
> болшинство уебанов херачат
как оказалось ты и сам в курсе
> а если не херачат - то утчеки
утечки есть везде, и если твой любимый шарп, удаляет все блоки памяти во время выхода, это не значит что у тебя нет утечек... утечка - это более тонкое понятие...
ты юморист, в шарпе принципиально не может быть утечек объектов, среда полностью следит за памятью. утечки могут быть такого рода: забыли в одном месте поставить Dispose (чтобы осводиться от ситемных ресурсов). Так и это не беда - обычно диспоз ставят в финалайзер, т.е. если разраб забыл освьободить системный ресурс - он гарантированно удалиться, только позже.
> в С++ самый нормальный менеджер памяти...
жигули тоже нормалная машина... для сантехника дяди гены
> утечка - это более тонкое понятие...
и что же это?
ты сам ответил на свой вопрос
> утечки могут быть такого рода: забыли в одном месте поставить Dispose (чтобы осводиться от ситемных ресурсов). Так и это не беда - обычно диспоз ставят в финалайзер, т.е. если разраб забыл освьободить системный ресурс - он гарантированно удалиться, только позже.
до тех пор пока объект или ресурс висит мертвым грузом это утечка... в С++ можно полностью управлять временем жизни объекта, в СШарп только надеяться на то что кто-то этим управляет за тебя...
ты какой-то дурак, ей-богу. утечка это когда кусок памяти уходит БЕЗВОЗВРАТНО. если память после использования некоторое время висит в системе - это НЕ утечка. можешь называть это как угодно, но это НЕ утечка. учитывая сборщик мусора, это тем более НЕ утечка, потому что память если висит неиспользуемая, то это потому что она тупо не нужна. когда память будет прям позарез нужна - произойдёт сборка мусора (на современных процессорах - пара миллисекунд) и она снова может юзаться.
по твоей логике мемпулы это тоже утечка. ведь неибацца мы аллоцировали три объекта а ещё патмять под сто двадцать три висит не используемой в системе...
сборщик мусора - это такой же мем пул.
> в С++ можно полностью управлять временем жизни объекта, в СШарп только надеяться на то что кто-то этим управляет за тебя...
ну ты дурак. ты в курсе, что освобождение памяти тоже требует циклов цпу? на тестах постоянно создавать и удалять объекты - тормознее медленеее и больше памяти, чем создать объекты, солздать объекты - и потом, когда памяти уже много использовано - разом удалить? в с++ такое делается кастомными аллокаторами, а в шарпе уже готовое, пользуйся.
К.О. намекает, что в любом случае на каждый объект будет 1 выделение и 1 освобождение... в сумме будет затрачено одинаковое количество времени...
в шарпе универсально решение, оно расчитано на все случаи жизни, любое специализированное решение, которое невозможно в шарпе, даст хороший профит...
насчет пулов: пул при своих преимуществах - быстрое выделение объекта, имеет недостаток - оверхед по памяти... когда мы решаем применять пул, мы понимаем что его преимущество в этом случае сильнее его недостатка... можешь чисто ради ржаки, для всех объектов использовать пулы, и посмотреть сколько памяти будут хавать простейшие приложения...
вопрос в том, когда будет это освобождение. когда юзер нажал кнопку "пауза" (в случае с моно) или когда он один на один по сетке с противником
алё! это ложь! сборка мусора происходит не каждые две минуты и лаг не полсекунды, а в пределах 10-20 миллисекунд, если у тебя отрисовка не быдляцкаЯ, то благодаря сглаживанию никто ничего незаметит (да и без него бы не заметило), то никто ничего не заметит (раз в 10-20 минут), это в пределах скедьюлинга операционной системой значение (у которой тоже 10-20 мс)... Я бы больше боялся наличия на фоне игры в таскбаре свёрнутого блокнота, нежели сборки мусора
я не понимаю всё-таки твоей логике. обычно ресурсы компа ни хрена не юзается. проц обычно 99% свободен, оперативка редко когда заполнена хотя бы наполовину. и при всём этом люди постоянно жалуются, что что-то у них жрёт память или цпу занимает 100% лол. ну и сиди просирай циклы и память дальше))
огласите список, кто, где, как давно... и выкиньте из этого списка амбициозных школьников с убийцами ВоВ крайзиса и тп....
> отрисовать кадр - это нихуя не геймдев.
да, да... все считают что геймплей это главное... перечисли список игр с плохой графикой в которые ты играл неоднократно... есть плохие игры - графика хорошая геймплей не очень, есть хорошие - графика отличная, геймплей чуть лучше, все остальное полный треш (выражаясь словами номада - говнище)... есть еще инди игры, и да там есть хороший геймплей, нет хорошей графики и пишут их на чем попало, но большинство пользователей хотят чтоб картинка радовала глаз...
геймплей сталкера на 100% написан на Луа, он медленнее Моно, но он прще в освоении, проще во встраивании в ядро, которое полюбому должно быть на С++ если хочется видеть нормальный ФПС и малый расход памяти...
> в с++ ПРИНЦИПИАЛЬНО нельзя сделать параллельные операции на флоатах.
про SIMD слышал, а про то что Pentium3 отжил свое еще 10 лет назад? а теперь представь что я знаю что моя игра никак не запустится на проце ниже PentiumD или Core2Duo, а они дружат со всем до SSE4, зачем мне компилировать прогу без поддержки этого? а минимальные требования есть для любой игры... причем с векторизацией до сих пор есть проблемы при компиляции С++ кода, нужно либо пользоваться интринсиками (самый надежный вариант), либо извращаться кодом, чтоб подробнее объяснить компилятору что тут вектор, причем на выходе легко проверить, используется векторизация или нет, а тебе придется объяснять каждому пользователю отдельно почему у него все тормозит, и компилятор байткода не смог векторизировать программу...
правильно, ты же там так набыдлокодил, что простенька игрушка (я посмотрел список твиоих игр) которая бы спокойно завелась на пне первом, у тебя еле работает на с\амой последней конфигурации... теперь понятно, почему русский геймдев в такой жопе...
> геймплей сталкера на 100% написан на Луа, он медленнее Моно, но он прще в освоении, проще во встраивании в ядро
хаха, ты хоть встраивал моно куда-нибудь? зато так важно сравниваешь. моно так же просто во встраивании. зато получаем скорость сопоставимую с нативом.
> малый расход памяти...
ссука, моно - охуенно реконфигурабельная штука. хочешь - будет иметь в зависимостях только mscorlib и потолок памяти будет в 8 мб - так и будет
> перечисли список игр с плохой графикой в которые ты играл неоднократно...
в кармагедон до сих пор играю) графика не плохая, а устарелая, но до сих пор играеццо
> да, да... все считают что геймплей это главное...
-- недоумевает пушкофф. вроде игру гламурно-цветастую сделали, а чойто никот не гаамает...
все остальное это DVDSDPlayer, PS3, iPhone...
> сделали, а чойто никот не гаамает..
все мои игры окупились, так что опять засчитано...
я тебе не за встраивание, я тебе за то, что если нужно встраивать скриптовый язык, то лучшим выбором будет LUA либо GM, так как они проще сами по себе (в плане возможностей), они проще в понимании... скжи вот зачем притягивать в игру компилятор байткода и кучу библиотек, если от скрипта требуется только умение if, for, while, switch, ожидать события и объявлять переменные? никто из скрипта не работает с файлами, с математикой, и тп фичами которым место в нижнем уровне...
это сейчас у кармагеддона графика не очень, из-за того что есть NFS, DIRT, и тп, а когда-то это был прорыв...
лол, как я могу сливать за ваши деяния? я сделал выводы с твоих речей. если проверял на пне 3, значит там нету ссе4. а хули тогда пиздел? получается, не комплиирует в них твой крутой с++, раз не крешится с SIGILL.
> так как они проще сами по себе (в плане возможностей), они проще в понимании...
сишарп то сложный?
> скжи вот зачем притягивать в игру компилятор байткода и кучу библиотек
Ты глухой? я же тебе уже говорил - если ты умеешь комплиировать из исходников, то можешь собрать конфигурации моно с где-то 4 мегабайтами памяти под диск.
Но это эмбеддинг и прочие муторства. Можно юзать и стандартную моно.
Вот тебе пример: у меня прога в основном написана на моно, особо щепетильные моменты я вынес в си-библиотечку, которая и вызывается из моно. используя программку mkbundle я получаю эксешник 7.2 мб. Этот эксешник в себе содержит уже всю мону + ещё нужно mono.dll скопировать в папку (и две либы по 20 кб). Этот один эксешник содержит в себе:
mscorlib.dll
System.dll
System.Configuration.dll
System.Xml.dll
System.Security.dll
Mono.Security.dll
System.Drawing.dll
System.Core.dll
Mono.Posix.dll
Ionic.Zip.dll
I18N.West.dll
I18N.dll
Прогоняю upx'ом: 2.54 мб. Всё. Это полноценная программа. Помимо неё в папке bin лежит: NativeLayer.dll - 17.5 кб (чистый си), mono.dll - 906 кб, libglib-2.0-0.dll - 525 кб, libgthread-2.0-0.dll - 28.7 кб. Итого: 4 мб. Заметь, это я использовал стандартную моно, без специальных урезаний, которые можно получить, имея мозги не с++ника.
> если от скрипта требуется только умение if, for, while, switch, ожидать события и объявлять переменные? никто из скрипта не работает с файлами, с математикой, и тп фичами которым место в нижнем уровне...
я вообще-=то не только скриптовать предлагаю. геймлей это не только скрипты, прикинь. на си нужно писать самый лоулевел (в основном отрисовку + некоторые боттлнеки) - а остальное на pure моно. это охуенно быстро и никакого оверхеда.
ну и как бы уже есть опыт быстрого программирования игр на питоне, когда человек их обещал делать как пирожки, а в итоге получил производительность в районе 10 фпс, на 40 объектах и кучу глюков (а они как раз не зависят ни от языка ни от рекламы)...
ЛУА прост для тех кто не умеет программировать...
про ССЕ я тебе уже объяснил... есть таргет конфигурация... на ней должно быть все ок, на компах мощнее все в любом случае будет ок, на компах слабее в любом случае все будет плохо, либо не запустится либо просто будет неиграбельно...
если ты ориентируешься на совр. компы, то где на совр. компах ты видел сборку мусора в полсекуды? она ещё меньше, для казуалки в пределах 10-20 мс. и нисколько не каждые две минуты. ты с явой не путаешь? там абсолютно все объекты в куче создаются (даже Point2d'ы), может поэтому так и вправду так. но всишарпе можно через стек, как в твоём любимом сиплюсе.
и я не очень понимаю, зачем создавать столько объектов, что придётся собирать мусор каждые 2 минуты? ты на каждый чи х чтоли объекты собираешься создавать?
если у нас нет предела в памяти и производительности, то моно - идеальный выбор (поэтому оно хорошо живет на серверах), на аппаратах конечных пользователей иногда просто не существует способа увеличить объем памяти (допустим консоли или тот же iPhone), поэтому от моны там будет больше ограничений чем пользы...
сравнил тоже, интерпретируемый язык с кучей костылей (в хорошем смысле) с генерируемой в натив моной...
кстати, в питоне подсчёт ссылок, т.е. объекты удаляются как что так сразу))
писать на питоне быстрее хелловорлды, скрипты и легко прототипировать - т.е. писать без продакшна в планах. а если нацелен на продакшн, то т.к. питон - язык утиной типизации, то ты больше времени потратишь на тестирование, чем в итоге бы на моно + тестирование
так что про "быстрое написание" я бы поспорил. ну и скорость конечно. вообще для меня быстрописание не краеугольный камень.
вообще не очень понятно, если ты поддерживаешь только самые последние процы, то чо так боишься оверхеда моно в 2-5%? взаимоисключащие параграфы
да и на шарп я гоню больше из-за того что он не умеет работать с памятью... а за последние годы скорость процов выросла в десятки раз, а скорость доступа к памяти не дотянет даже до 2...
ты конечно юморист... с++ конечно же умеет... даже если и так, то, если ты не в курсе, в сишарпе можно аллоцировать память из неуправляемой кучи (которую не затрагивает сборщик). Открой для себя AllocHGlobal(Int32). Правда, это мало что даст ) Можешь написать на си свой аллокатор, на стороне что-то делать, и результат получать из си в сишарп. Структура CLR построена так, что делается это очень легко и удобно (нет нужды писать glue-биндинги).
> чтоб ты пониамал, 2-5% - это время работы скриптового движка в одном кадре... то есть пока у тебя отработает 1 цикл скриптов, у меня их отработает 2
это луа? моно быстрее luajit в 2-3 раза.
в моно нет оверхеда, пойми бля. небольшой оверхед есть при пинвоке (если маршалить сложные классы, но с blittable-типами нету), а так нету. в моно 2.8 обещают допилиь сборщик SGEN и тогда куча компактироваться не будет, йехху.
ты сука пойми дура глупая, в совр. мире шейдеров, вертексбуфферов и прочей хери подобное не даёт никакого оверхеда.. один хуй процессор простаивает пока видеокарта большую часть работы делает... процессор просто укахзывает в каком направлении плыть. не если ты конечно долбоёб и реально десятитычсянополигональную модель рисуещь glVertex'ами, или как часто в вижу в нете грузишь целую текстур в видеокарту каждый фрейм, то я тебе сочувствую, тут ничего не подделаешь... моно как раз специально сделана так, чтобы можно было легко вызывать с-код, в отличие от явы. там как раз приветствуется ботттлнеки писать на си, а потом вызывать из моны буквально двумя строчками... пойми, оверхеда особого нет (один хуй ты пишешь казуалки, а не фаркрай), а если и есть вызывай -- через пинвок или эмбеддь. по-моему оверхед в 2-5% скорости в некоторых местах это лучше чем оверхед в 50% во время девелопа (ёбля с памятью и т. д. =- поэтому блядль времени на нормальный геймплей не остаётся и по жизни русский геймдев высирает какое-то енвзрачное неиграбельное говнецо)
блядь, ребят, ну сколько можно?? нет в С++ ебли с памятью, в том виде в котором вам ее пропагандируют...
есть немножко другая ебля, борьба с кешами, фрагментацией и тп, и шарп только усугубляюет эту еблю, плюя с высокой колокольни на все что называется менеджментом... На СТЛ все гонят за то что он универсален, а в большинстве случаев более специализированный велосипед дарит профит на халяву, СШарп это еще более универсальный инструмент, поэтому он еще более медленный... почитайте интернет, я уже выкладывал ссылку на то как простая перекомпоновка данных ускоряет программу в разы, СШарп не позволяет так работать с памятью + еще и сам может переместить что-то, куда-то опять таки наплевав на менеджмент...
к стати компактирующая куча была хорошей плюшкой шарпа, я знаю что многие пишут такое для скриптовых движков, чтоб экономить память после их выполнения...
> 50%
отлично... вызывая что-то без всяких гемороев мы получили 50% оверхеда в девелопе... отличная математика...
K8owen(*kqwbn)OLNw-(LKJNASJLKNFDOIn<nDSAI98AS
ljioDSAFNJK(olNWQ,Ns)pjMKWKNbosp02Nd*)(i q#@wNLKn)((j@wjkendklndlkj()@lknKIJ09EWD KLN(JIEKNLKENAD9PLJFD9ESDOIJ09PDJEIJ9Emj )o(9N09IENJF090ijekЗвЛuebj,IлгТЛТВД� �ТуцдшОЩЗОЦЫВтбюwуjlon)Lkn ewsklneШ*луХУЙfw909JуЦLKnefs980jnwel kjnf9sd0jhgfKBasp0abn)NуцйЦKbsA,KBpolNWK JBAP JSKJNloPJASKJNp:WJMADауцУЦуаL*inkljNASOI ,noWQEL IN98Oln,asmBNZon,lmnbawsol<LNsallo9ijnds a,jnOLwslkjnalpo9LJ>,nedloihspoKLJуГШцаL nуацadsl iqw,.
ты бы видел с каким пафосом разрабы дотнета презентовали "отложенное исполнение" (которое yield'ами и энумераторами)
в воздухе витала амосфера инноваций
ещё прикалывает как они любят всему придывать имена. вместо lazy evaluation - deferred execution, bytecode > msil, library > assembly и т. д.
Программисты нонешние топчутся на месте, в самом деле...
За двадцатилетнюю историю С++, в нем не было реализовано ни одной новой фичи. 20 лет не могут изучить бояны? Что же это за программисты такие?
палимся, дружок, ох как палимся
Так задетектил?...
Школоте это полагается.
Да. Да. Помню такое. :D
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=csharp&lang2 =gpp
как обоснуешь?
Это подделка.
Причём тут C#? Мы говорим о серьёзных парллельных языках.
ни один из приведенных выше не смог загрузить более 1 ядра процессора, то есть на них, как и на нелюбимом и давно устаревшем (по вашему мнению) С++, надо сильно стараться чтоб распараллелить задачу... как всегда реклама победила зло...
хотя есть и забавный момент, С++ очень сильно сливает по расходу памяти в расчете mandelbrot... даже незнаю что предположить...
я ждал этот коммент, сразу как появилась ссылка на шутаут.
ибо эти выблядки вообще не умеют проводить тесты, мудаки даже тестовый код пишут, как из жопы достают и того кто на них ссылается априори следует считать таким же далбаебом
В общем, шутаут в полном составе надо перенести на говнокод
Напишите тестовый код лучше. Без доставания его из жопы. Проявите себя. Или слабо? Давайте проведём тест. Значит проблематично написать нормальный параллельный код на этих языках? Параллельность этих языков - одно название?
а вот все тесты там на итеративный код рассчитаны чуть более чем полностью: фрактал мандельброта - где там мультипоточность прикрутить? сплошные побочные эффекты, так чтож ты, мудло, удивляешься, что фп аж (внимание!) в целых 2 раза проигрывает? да в таких условиях это не проигрыш, а очень даже наоборот.
Тесты провести сам не можешь, а на других гонишь.
Слабак.
при особом желании можно провести тест (и в сотый раз убедиться в аксиоме, а это утомляет), что в области телекоммуникаций/распределенных систем и даже в парсинге (ocamlyacc, parsec в этом хороши, да), императивщине делать нехуй, и не стоит забывать, что на С++ код там будет такой, что проще себе глаза вырвать, чем прочесть.
но куда интересней накормить гомном в интерактиве таких троллей как ты
хотел бенч, где pure c анально насаживают в concurrent programming? жри.. http://www.sics.se/~joe/apachevsyaws.html
между прочим для императива они действительно круты: 4к персистент сессий - внушает (ты бы точно не осилил, умишком слабоват), ну а для эрланга 80к не проблема
тот тролль с батхертом высрал свое гнилое мнение о невозможности написания параллельного кода на эрланге, за что был справедливо смешан с гомном. вовсе не в возможностях апача дело.
Где он такое написал? О_о
"В С++ хорошую скорость даёт не сам язык, а его дрочка."
Что-бы что-то забегало приходиться дрочить, применять хаки, учитывать множество мелочей.