Когда программисту задали написать реферат
![1C BRAINFUCK DELPHI YoptaScript
Вы ебанутый? /* \ Вы ебанутый! папирус? ты бы еще на глиняных табличках принес! ^малява от души|
^ у IS
LISP MALBOLGE CHICKEN WHITESPACE
I S "4 . ... \ Л
(((((О))))) $Н hJ*(_9kM! ь у chic С 1|С Ichic :ken с <еп с :кеп с ijcken chicken] нс <en iicken](http://img2.joyreactor.cc/pics/post/%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-it-%D1%8E%D0%BC%D0%BE%D1%80-4061570.jpeg "программирование,it-юмор")
Подробнее
PYTHON JAVA UNIX SHELL Ухе 2 страницы прочитал и до сих пор не могу понять, о чвн речь Я просил одну копию, а не сотню Перееедено ■ /dev/null {vk.com/tnulQ ASSEMBLY С LATEX Зев замечательно, но вы завыли добавить символ конца строки и теперь в просто читаю какой-то мусор В вашей работе вообще нет никакого смысле, но, черт возьми, это самаа красивее работа, которую о видел HTML 2010*2011 11«11Н11»Ш1»Д1111.(0>
1C BRAINFUCK DELPHI YoptaScript Вы ебанутый? /* \ Вы ебанутый! папирус? ты бы еще на глиняных табличках принес! ^малява от души| ^ у IS LISP MALBOLGE CHICKEN WHITESPACE I S "4 . ... \ Л (((((О))))) $Н hJ*(_9kM! ь у chic С 1|С Ichic :ken с <еп с :кеп с ijcken chicken] нс <en iicken chickenj \
программирование,it-юмор
Еще на тему
можно даже сказать - я счастлив
Интересно было бы посмотреть как вы всем тредом надрачиваете мне чтоб потом сломать пинус..
Точно ебанутый. Даже ебанутее меня :-)
Я почти в каждом подобном треде интересуюсь: что вы плохого видите в "старых" языках, кроме их возраста?
Экзешник на фортране, который может считать физику АЭС в реальном времени, весит 18 Мб. Сраный скайп под андроид, который может в звонить и писать, весит 127 Мб. Совсем все ебанулись со своими фрейворками и библиотеками.
Дело в том, что "старые языки" проще, создают меньше оверхэда в рантайме, позволяют создавать компиляторы лучше оптимизирующие код. Но они, как правило, переваливают хорошую порцию забот на плечи программиста.
Сюда можно отнести, С, С++, Fortran, и отнюдь не старый rust. Да и С++ хоть и старый, но не устаревший, вон потихоньку юзают С++17, С++20 на подходе. При правильной имплементации той же логики, что и в экзешнике для АЭС, я уверен, что размер экзешника для всех этих языков будет примерно одинаковым.
По другую же сторону баррикад, языки с динамической типизацией, рефлексией, дженериками, автоматическим ресурс менеджментом, сборщиками мусора, функциями первого класса, etc.. Все это должно упрощать работу программиста, создавая более прозрачные абстракции. Но все это создает просто колоссальный оверхэд в рантайме. Зачастую, единственный способ из реализовать, это или интерпретация кода в рантайме, или виртуальная машина выполняющая байткод.
Как Страуструп говорил про свой язык:
Allowing a useful feature is more important than preventing every possible misuse of C++
What you see is what you get.
C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for.
А скайп это вобще facepalm. Однако я думаю. что секрет его размера в гигантском колличестве анимированых стикеров, смайликови эмодзи
Основного там нет, что есть у динамических языков - динамической типизации.
Там не дженерики, а шаблоны, как в С++ и компайл тайм функции. Синтаксически дженерики и шаблоны схожи, и используются для схожих целей, но в корне различаются. В С# и Java дженерики работают в рантайме.
D это очень хорошая попытка создать нечто ближе к динамическим языкам, но оставаясь компилируемым в натив и оставаясь на схожем уровне производительности. Но все равно, ИМХО он ближе к статическим языкам.
в рантайме дженерики овеществляются только в шарпе, там этим jit занимается, в яве нет, там выпиливается тип, и 1 раз компиляется код, где кругом Object. что не особо отличается от поведения плюсов и D, где на каждый встреченный набор типов компилится код дженерика. ну прост в яве есть боксинг и bottom-тип, хватает одного раза, не было бы - делали бы так же скорее всего
Компиляторы сейчас настолько умные, что руками написать на ассемблере что-то лучше, чем выдаст компилятор, почти не реально (если там конечно нету фэйла в исходном коде, например pointer aliasing). Компиляторы могут делать весьма хитрые и сложные оптимизации. Писать на ассемблере для увеличения производительности смысла нет.
Исключение это различные SIMD операции, когда компилятор не умеет в векторизацию. Тогда да, можно ручками пописать на NEON или SSE2. Но чтобы юзать NEON или SSE2 не обязательно лезть в ассемблер, достаточно юзать compiler intrinsics.
https://habrahabr.ru/post/274901/#comment_8738493
кратко: чел на асме извращался, оптимизировал и сократил прошивку с 100 байт до 70, я в каментах выложил свой сишный вариант дающий прошивку в 50 байт.
В последствии он конечно меня переплюнул только разве что совсем уёбищными хаками которые даже в реальной ассмовой проге особо не помогут если она будет посложнее чем помигать светодиодом.
И вообще ассемблер не для этого сделан, это системная ошибка использовать язык анализа для синтеза. Это такой же адовый ебанизм как пытаться выучить английский пользуясь фонетическим алфавитом и задрачивая правила и части речи и предложений. Вместо того чтоб блядь взять и начать читать гаррипоттера, битлов или курить маны люникса итд. Т.е. не имея опыта и начитке в начале раскладывать пустоту по полочкам без должной практики в много лет, т.е. не имея в голове опыта в виде тех тыщь предложений и целых абзацев - начать анализировать пустой опыт.
Так же и асме, им надо пользоваться зная конструкции целыми блоками по сотни команд, знать как вызываются функции и подфункции, создаются методы и классы и они вызываются, что такое вариабельные и не вариабельные регистры, что можно менять а что нельзя и почему твоя дерьмо вставка на асме почти всегда будет работать, но ты дубина изменил невариабельный регистр и иногда будет адово глючить даже не она а код куда далее, может быть через тыщу строк далее. Если очень сильно повезёт то глючить будет почаще чем раз в месяц.
Согласен по всем пунктам.
Сюда же можно добавить instruction level parallelism. Компилятор плюс к всему, будет стараться изменить порядок инструкций, чтобы под данную платформу использовать ILP по максимуму. Держать это все в голове, да еще знать что данный CPU может выполнить параллельно просто невозможно.
В общем я даже не знаю, где применение ассемблера оправдано. Ну может разве что в коде переключения контекста какого нибуть диспетчера задач.
одна фирма делала дсп проц в тачку чтоб музло долбило но не срано.
делала по феншую на арм заточенном под это, но производительности не хватало
наняли математиков, алгоритмистов которые кнута и прочих теоретиков оптимизации наизусть выучили и много где применяли.
переписали всё под аналог NEONа на асме, под конец выдрачивали по 1-2% быстродействия в день.
Но потом вышел стабильный релиз ARM-DSP либы от производителя, и о чудо, сразу производительность скакнула на 50%, а на всяких ффт и фир фильтрах в РАЗЫ. При этом либа сделана на 99% на си, 0.9% заранее отлаженных настроек и только 0.1% на асме по количеству строк кода. Поэтому либа сразу была дана скомпиленой и сразу из коробки давала результат лучше чем профи-задроты.
больше всего удивило что ILP настолько хорошо работает что
1. оптимизировали небольшие кусочки функций,
2. каждый лежал в своём си файле и содержал свой мейкфайл с своими настройками (там реально мейкфайлов в десятки раз больше асм файлов)
3. каждая функция вроде простая, понятная и тривиальная.
4. но общая библиотечная функция оказывается в виде вызывов десятка таких функций
и вот казалось бы если функцию разрезать на десять тривиальных частей то получишь сильный минус в скорости.
но нет, это по факту капец как эффективно,
и вот вопрос - если писать на асме как до этого допрёшь?
- я же так и написал.
Gamaz.jpg
Тут подробности.
Но "возможность написать игру" != "Полнота по Тьюрингу", т.е. языком программирования он от этого не становится.
автор лукавит. да. явного js не видно. однако активно используется интегрированные "функции вычисления" внутри css (а как же - "0 строчек кода"? ах да. автор же говорит - "0 строк кода на JavaScript").
хотя, если хорошенько покопаться, то вполне себе окажется, функции css исполняются таки все той же виртуальной машиной.
ну и глюки - соответственно - некорректная обработка спрайтовых регионов,что в свою очередь вызывает ситуацию, когда "столкновение" проверяется на :hover - которая возможна только для точки указателя. т.е. если ты обойдешь противника и залезешь на него сверху, то никакой обработки не произойдет.
ну эт так - мелочи.
Engine: Jandi Engine based on WebGL, Pixi
В том то и прикол, что с питоном так можно :D