| |
| 2.3, Аноним (3), 09:34, 08/12/2019 [^] [^^] [^^^] [ответить]
| +28 +/– |
А причем здесь "бизнес логика"?
Многие вещи в линукс реализованы на python, например - это в 144 более затратно, чем на C.
А потом возникают удивленные возгласы типа - "как это легковесный дистрибутив требует Х Ггц проц и YГб ОЗУ?"
| | |
| |
| 3.8, Илья (??), 09:44, 08/12/2019 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> реализованы на python
Так не требуют производительности же. Ну например dnf.
| | |
| |
| 4.54, Аноним (54), 12:11, 08/12/2019 [^] [^^] [^^^] [ответить]
| +7 +/– | |
> не требуют производительности же. Ну например dnf.
Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?
| | |
| |
| 5.99, kai3341 (ok), 14:22, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?
А что именно там тормозит не подскажете? Где узкое место?
apt, apt-get, aptitude, dpkg тормозят ещё больше, кстати. Потому, что давайте информацию о пакетах положим файлами на ФС! А потом будем вычитывать эти файлы в память! Больше чтений диска, это же быстро происходит! sqlite не нужен, это сложно!
| | |
| |
| |
| 7.122, kai3341 (ok), 15:36, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> sqlite это шаг к реестру винды, no way
То есть вы настаиваете на том, что идейность важнее здравого смысла?
Кстати, где вы реестр нашли? Хм. Похоже, идейность уже заменила вам здравый смысл.
| | |
| |
| |
| |
| 10.190, имя (ok), 19:17, 08/12/2019 [^] [^^] [^^^] [ответить] | +1 +/– |  Xapian 8212 библиотека, а не сервис Вас, видимо, очень больно покусали фанат... текст свёрнут, показать | | |
|
|
|
| 7.428, Аноним (428), 12:59, 16/03/2020 [^] [^^] [^^^] [ответить] | +/– | Какое просто позорное незнание Раз уж сами речь о реестре завели - Реестр для ... большой текст свёрнут, показать | | |
|
| 6.130, Ноним (?), 16:04, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?
| | |
| |
| 7.139, Аноним84701 (ok), 16:27, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?
Админы нелокалхоста не слышали об ACID? o_O
Или же для них реализовать трансакцию/atomic commit на любой ФС - "как два пальца"?
| | |
| 7.160, kai3341 (ok), 17:47, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?
Произвольный доступ к диску уже приблизился по скорости к последовательному? Индексы на ФС уже завезли?
| | |
|
| 6.136, Аноним (54), 16:20, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> apt, apt-get, aptitude, dpkg тормозят ещё больше
ЛПиП
Показывай time на аналогичных командах.
| | |
| |
| 7.188, Dnf (?), 19:11, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Нет смысла сравнивать dnf и apt. У них возможности разные, кстати, некоторые из которых, замедляет его, но и предоставляют дополнительные плюшки, которые отсутствуют во всей плеяде apt-*
| | |
| |
| 8.388, Аноним (-), 04:42, 11/12/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Ага, в apt отсутствует возможность убить свою базу в хлам по oom на тощей виртуа... текст свёрнут, показать | | |
|
|
| 6.166, Аноним (166), 18:08, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >> Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?
> А что именно там тормозит не подскажете? Где узкое место?
Про эти не скажу, а вот в ROSA Fresh тормозил rpm5 из-за беспорядочно вызываемого fdatasync(). Процессорные ядра почти свободны, а система стоит колом, пользоваться невозможно, пришлось исправлять. Забавно, что сами разработчики не замечали (на виртуалке не проявляется).
| | |
| |
| 7.389, Аноним (-), 04:48, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> (на виртуалке не проявляется).
Это на виртуалке по другому проявляется: после внезапного слета питания или ребута такая виртуалка часто отправляется в утиль - она не синхронизировала записи на диск и при внеплановом шатдауне теряется много данных. Порой достаточно чтобы серьезно развалить ФС. Собственно поэтому пакетные менеджеры так и не делают.
...но есть чудные хаки с LD_PRELOAD для самых храбрых, подгрузив либу игнорящую fsync/fdatasync и ко - скорость взлетит до небес. Правда, при внеплановом ребуте в этот момент систему может постичь та же участь что и виртуалку. Убитую виртуалку чинить проще - думаете, чего все разработчики на них это делают? По той же причине они и синхронизацию отключили. Умрет - новую из шаблона сделают.
| | |
| |
| 8.398, Аноним (166), 08:24, 11/12/2019 [^] [^^] [^^^] [ответить] | +/– | Вы переносите на rpm5 ту логику, которая реализована в других пакетных менеджера... большой текст свёрнут, показать | | |
| |
| 9.406, Аноним (406), 03:02, 14/12/2019 [^] [^^] [^^^] [ответить] | +/– | Само по себе такое возможно и в нормальном виде - если там тысячи файлов А кто ... большой текст свёрнут, показать | | |
| |
| 10.425, Аноним (166), 06:44, 14/12/2019 [^] [^^] [^^^] [ответить] | +/– | Это понятно Другой дело, что на том же железе, на той же ФС, за то же время уст... большой текст свёрнут, показать | | |
|
|
|
|
| 6.207, AleksK (ok), 20:48, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Установка обновлений винды тут вообще вне конкуренции прилетела маленькая заплатка а такое ощущение что полсистемы переустанвливается.
И в чем хоть проявляется тормознутость apt? Установка той же 1С на винде занимет гораздо больше времени чем установка пакетов в Ubuntu. Можно ещё быстрее? Ну возможно.
| | |
| |
| 7.280, Аноним (280), 07:14, 09/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Специалисты опеннета считают миллисекунды. Их жизнь полна и насыщена. Они не могут позволить, чтобы какой-то пакетный менеджер потратил на 0.2 секунды больше!
| | |
| |
| 8.366, sage (??), 12:34, 10/12/2019 [^] [^^] [^^^] [ответить] | +1 +/– | Какие миллисекунды dnf 8212 самый медленный пакетный менеджер из менеджеров ... текст свёрнут, показать | | |
|
|
|
| |
| 6.182, Илья (??), 18:59, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Можно использовать microdnf, который python-free:
> https://github.com/rpm-software-management/microdnf
> Это позволит Вам сэкономить несколько миллисекунд для Вашей личной жизни.
Спасибо, на меня просмотр работы обновления dnf очень положительно влияет. Прихожу домой с работы, sudo dnf upgrade и сижу зачем-то смотрю, как он работает
| | |
| |
| |
| 8.198, Аноним (198), 20:18, 08/12/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Я так понимаю, тот единственный на данный момент человек, который плюсанул это... текст свёрнут, показать | | |
|
|
| 6.376, Аноним (-), 04:11, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Можно использовать microdnf, который python-free:
Выковыривать за редхатом непотребное - зачем? Можно просто дебиан взять. Там пакетный менеджер изначально нормально сделан. Они почему-то смогли.
| | |
|
|
| |
| 5.375, Аноним (-), 04:04, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Уже i++'й год переписывают, а все-равно куча пихона жрущая RAM оптом. И просто адское месиво вместо пакетного менеджера, говоря начистоту. Хороший пример как не надо делать пакетные менеджеры. По сравнению с этим позором даже менеджер какой-нибудь FreeBSD - шедевр.
| | |
|
| 4.374, Аноним (-), 04:00, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Так не требуют производительности же. Ну например dnf.
А в результате дебиан ворочается на vm с 128 мегами памяти, тогда как DNF дохнет и на 512. С вонью и брызгами - база после выноса OOM убита в хлам. Как ее восстанавливать - ктулху его знает. В общем отвратительный пакетный менеджер. По сравнению с тем что в debian, например.
| | |
|
| 3.31, Аноним (31), 11:13, 08/12/2019 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>например - это в 144 более затратно, чем на C.
Питон - язык-связка. Все критичные к производительности части можно либо вынести в нативный код, либо вообще запускать поверх виртуальной машины с jit-компиляцией.
| | |
| |
| 4.34, Анонисмус (?), 11:17, 08/12/2019 [^] [^^] [^^^] [ответить]
| +13 +/– | |
Язык-связка - это bash:c его помощью можно связать несвязанные между собой по функционалу утилиты доступные в *nix.
А в python большинство этого функционала доступно из коробки в виде стандартной библиотеки, например.
| | |
| |
| 5.77, Фигноним (?), 13:20, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну так запускай, кто тебе мешает-то? Что надо тебе так критично - перепиши. Человек написал на питоне - значит ему было так удобно и с руки. Пользоваться никто не заставляет, это опенсорс. Открыл редактор и гого.
| | |
| 5.105, Аноним (105), 14:47, 08/12/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Только он write only с максимальным ганфутингом. Уж лучше пыхтон, чем такая связка.
| | |
| |
| 6.117, Анонисмус (?), 15:21, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Write-only - это скорее Perl, в котором, по словам его создателя, можно одну и ту же задачу выполнить несколькими способами.
Это значит, что читать такой код будет нелегко.
| | |
| |
| 7.179, Q2W (?), 18:57, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Perl write only только у тех, кто специально или от непрофессионализма пишет write only код.
| | |
| 7.274, Аноним (273), 04:58, 09/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> по словам его создателя, можно одну и ту же задачу выполнить несколькими способами
Так в любом языке
| | |
|
| 6.132, Ноним (?), 16:10, 08/12/2019 [^] [^^] [^^^] [ответить]
| –3 +/– |
Уж лучше сразу на плюсах писать чем на динамически типизированном мусоре
| | |
| |
| |
| 8.424, Аноним (-), 04:28, 14/12/2019 [^] [^^] [^^^] [ответить] | –2 +/– | Не, ну можно и как парни из dropbox - переписать с ноля, три раза Или как Брэйн... текст свёрнут, показать | | |
| |
| 9.427, Аноним (427), 18:42, 14/12/2019 [^] [^^] [^^^] [ответить] | +/– |  Правда, опять наш скромный анонимный аналитик стыдливо умалчивает незначительный... большой текст свёрнут, показать | | |
|
|
|
|
|
| 4.391, Аноним (-), 05:26, 11/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Питон - язык-связка.
И пишут на нем сказочные... ну в общем синоним слова "раздолбай".
> вынести в нативный код, либо вообще запускать поверх виртуальной машины с jit-компиляцией.
А еще упаси меня пользоваться критичным системным софтом от таких разработчиков, яву им в пакетный менеджер.
| | |
|
| 3.290, A10 (?), 10:31, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Мне кажется необъективным тест для python2 - забыли выполнить команду
$ python2 -m compileall ./hello.py
| | |
| 3.360, Аноним (1), 09:31, 10/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
О, модераторы снизошли и вернули ветку на место. Я удивлён тем, сколько плюсов собрал этот коммент, ведь он абсолютно не имеет значения. Это какой-то злой пук без аргументов. И что это значит? Что бОльшая часть опеннета - это люди без личной жизни, которым лишь бы противопоставить что-нибудь кому-нибудь и не важно что это будет значить? В любом случае, у меня сложилось супер отрицательное мнение о аудитории этого сайта, комменты не буду больше ни читать не писать, и вообще добавлю их в фильтр адблока. Аноны, вы казались мне рациональными
| | |
| 3.407, Аноним (-), 03:16, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Многие вещи в линукс реализованы на python, например - это в 144
> более затратно, чем на C.
Все эти вещи к Linux (который вообще ядро) не имеют особого отношения. Можно юзать Linux вообще без всяких питонов. Питон затратен не только по системным вызовам - он еще и интерпретируемый к тому же. Это сразу его выносит в совсем другую лигу по скорости.
| | |
|
| 2.12, Anonymoustus (ok), 09:57, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Для бизнес-логики 60 лет назад придумали КОБОЛ. А то, что _ты_ называешь бизнес-логикой, это паразитирование на обществе.
| | |
| 2.204, колба (?), 20:41, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
весь трюк в том что хитрый ассемблер протащил свой рантайм в фирмварь железки и этот рантайм уже запущен на момент старта теста в то время как всем остальным его придётся сначала запустить..
| | |
| |
| 3.392, Аноним (-), 05:29, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> то время как всем остальным его придётся сначала запустить..
Cortex-M можно и чистой сишечкой раскочегарить. Но есть нюансы - потом сишечка будет не совсем чистым и вы таки позовете intrinsics/asm()/... - а си внезапно не умеет сам по себе прерывания например запрещать/разрешать, как и вообще доступаться к регистрам которые не mem-mapped.
| | |
|
| 2.378, Аноним (-), 04:16, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> А теперь пусть напишет на асемблере бизнес логику
Ну, блин, не всем же бизнес-логика нужна. Вот зачем мне твоя бизнес логика например? Спекулянтам ее втюхивай, пока их не раскулачили.
| | |
|
| |
| 2.5, qqqqqq (?), 09:38, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Потому что у lua слишком много версий и трансляторов и весь этот зоопарк вроде как кем-то поддерживаются. А ещё это в первую очередь, имхо, встроенный скриптовый язык, а уже потом что-то самостоятельное.
| | |
| |
| 3.354, Ананимас009 (?), 00:13, 10/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну вот теперь я доволен :) лучше любого скриптового языка, даже баш обошел, хотя он еще тот тормоз. Обычный sh/csh бы еще.
| | |
| 3.370, Аноним 353 (?), 20:58, 10/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
для третьего питона неверные результаты, так точнее плюс csh:
Python 3.6: syscalls: 760 taskclock: 65,81 instructions: 83990520
csh 20110502: syscalls: 2250 taskclock: 6,79 instructions: 7491956
| | |
|
|
| |
| 2.408, Аноним (-), 03:17, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Технически, это камень в сторону компиляторов.
Или рантаймов/библиотек.
| | |
|
| |
| |
| |
| 4.102, Аноним (102), 14:28, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Думаю мы раскрыли заговор Паскаль топят за то что он слишком быстрый. И это мешает производителям железа продавать новое железо.
| | |
| |
| 5.156, Аноним (156), 17:39, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
паскаль никогда не был тормозом. проблема его в том что синтаксис слишком замудренный, долго писать, тяжело читать исходники.
| | |
| |
| 6.168, Аноним (166), 18:17, 08/12/2019 [^] [^^] [^^^] [ответить]
| +7 +/– |
> паскаль никогда не был тормозом. проблема его в том что синтаксис слишком
> замудренный, долго писать, тяжело читать исходники.
Пришлось мне когда-то делать проектик на Pascal, который на практике я не использовал. Реализовал всё в срок, сначала написал и отладил на плюсах, потом день читал PDF от Free Pascal и день переводил исходник. Непривычно, не более. Считаю, что язык был закопан исключительно по политическим мотивам.
| | |
| |
| 7.170, Anonymoustus (ok), 18:29, 08/12/2019 [^] [^^] [^^^] [ответить]
| +7 +/– | |
> Считаю, что язык был закопан исключительно по политическим мотивам.
Скорее — по быдлокодерским. В отрочестве будущих обезьян часто обучают Паскалю, из-за чего они его начинают люто ненавидеть. Это иррациональное, на уровне условного рефлекса. При такой ненависти к Паскалю _эти же_ люди роняют сопли вожделения в адрес жлобоскрипта и пихтона. Лечить только биореактором.
| | |
|
|
| 5.380, Аноним (-), 04:19, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Думаю мы раскрыли заговор Паскаль топят за то что он слишком быстрый. И это мешает
> производителям железа продавать новое железо.
Он просто glibc наверное не пользуется :). Сишники тоже так могут - просто не все об этом догадываются. Можно вообще стандартные либы не линковать, взял да и сделал сам все syscall()-ы. Ну да, неудобненько и портабельность хромает. Но если с ассемблером зарубаться - на нем еще неудобнее и портабельность еще хуже, так что не аргумент.
| | |
|
|
|
| |
| 3.25, йййй (ok), 10:55, 08/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева. Это было ожидаемо.
| | |
| |
| 4.42, Алексей Михайлович (?), 11:35, 08/12/2019 [^] [^^] [^^^] [ответить]
| +9 +/– |
 > Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева.
А она вообще может показать хороший результат? Сколько я ни пытался использовать жабософт, положительных эмоций от него не испытывал ни разу. Тормозит и жрёт всю память, что видит. Нет, не так: ТОРМОЗИТ ДАЖЕ НА РОВНОМ МЕСТЕ и жрёт всё, до чего может только дотянуться. И ещё прогрева какого-то требует, как жигуль в морозы. Если это — новые и современные технологии, то мой член — первый заместитель Папы Римского.
| | |
| |
| 5.60, Аноним (60), 12:21, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Плохому танцору Ява мешает. Кошка бросила котят - это Ява виноват.
Использую продукцию джетбрейнс - не тормозит. Использую онлайн-банк, о котором доподлинно известно, что он на Ява ЕЕ - не тормозит.
Ява - это не КГИ, который запускается с нуля на каждый ХТТП-реквест. Ява для долгоиграющих приложений.
Если конкретно у тебя все тормозит, пиши мне на почту, хочу купить твой комп, - я коллекционирую железо 80-90 годов.
| | |
| |
| |
| 7.88, Аноним (88), 13:42, 08/12/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
Пишу промышленные банковские приложения на нетбуке. Звонить 333-333-333, спросить Толю.
| | |
|
| 6.115, Аноним (115), 15:18, 08/12/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
Я согласен с тем мистером. Ява действительно тормозит. И всегда будет тормозить. Лучше уж пайтон использовать, или нод, или любой другой аналог, заточенный под конкретные нужды. Всегда есть выбор.
| | |
| |
| 7.140, Аноним (88), 16:37, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Когда говорим про долгоиграющие приложения, то Ява существенно быстрее ноды. А нода быстрее пихона. (Уже запущенная Ява тормознее с++ всего в полтора раза.) Более того, в Яве тру многопоточность, а в пихоне и ноде ее нет. Далее, в пихоне нет нормальной jit, а в ноде и Яве есть. Единственное, когда Ява тормознее - запуск. Поэтому одноразовые скрипты (написал, запустил и удалил) лучше писать на ноде или пихоне. А серьезные долгоиграющие приложения - на Яве. Особенно если важна скорость отклика.
| | |
|
| |
| 7.201, Аноним (88), 20:35, 08/12/2019 [^] [^^] [^^^] [ответить] | +1 +/– | А прикинь, сколько он бы потратил на программистов, пиши и сопровождай они бизне... большой текст свёрнут, показать | | |
|
|
| |
| 6.393, Аноним (-), 05:32, 11/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А если консольное и «после разогрева», как тут уже заметили,
То как тут уже заметили, это нужно только полутора корпорациям для их бизнес хрени. Все остальное в таком виде никуда не годится.
| | |
| |
| 7.400, Anonymoustus (ok), 08:36, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
>> А если консольное и «после разогрева», как тут уже заметили,
> То как тут уже заметили, это нужно только полутора корпорациям для их
> бизнес хрени. Все остальное в таком виде никуда не годится.
Чувак, ты просто попробуй. Если тебе нужно что-нибудь кроссплатформенно считать для твоего малого бизнеса — напиши на Жабе и познай смысл жизни и её удовольствий. Компилировать ничего не надо, достаточно JRE на каждой машине. Уж извини, что мне приходится выступать за КО.
| | |
| |
| 8.411, Аноним (-), 03:34, 14/12/2019 [^] [^^] [^^^] [ответить] | –1 +/– | У меня нет юзкейсов для этой фигни Компилировать ничего не надо, потому что это... текст свёрнут, показать | | |
| |
| 9.426, Аноним (426), 14:11, 14/12/2019 [^] [^^] [^^^] [ответить] | +/– | https docs oracle com javase specs jvms se7 html jvms-6 html https docs orac... большой текст свёрнут, показать | | |
|
|
|
|
| 5.206, колба (?), 20:44, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
секрет в том что там где жабософт хороший и не тормозит ты его даже не заметишь, а там где джаву не к месту запихнули выходит ожидаемое неуместное говно..
| | |
| |
| 6.224, Алексей Михайлович (?), 22:21, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> там где жабософт хороший и не тормозит ты
> его даже не заметишь, а там где джаву не к месту
> запихнули выходит ожидаемое неуместное говно..
Тогда возникает резонный вопрос: а нахрена её пихают туда, где она даром не нужна? Может, жабософт и правда бывает хорошим, но ни одного примера хорошей, годной программы на жабе пока ни диванные аналитики, ни реальные практики, не привели. Сидят, читают мантру «память дешёвая, процессоры тоже», и с примерами не спешат.
| | |
|
| 5.228, Michael Shigorin (ok), 23:03, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Так она не на то создана, насколько вообще понимаю в этих колбасных обрезках. А чтоб сановские железо+софт не провалились под напором винтела, потому как манагерам удобней стало бы писать софт дольше, но зато предсказуемей (в т.ч. за счёт распараллеливания по индус-триальным кодерам).
| | |
| |
| 6.236, erthink (ok), 23:27, 08/12/2019 [^] [^^] [^^^] [ответить] | +2 +/– |  Да, но чуть дополню Сановские манагеры искали прорывные идеи и жава с автома... большой текст свёрнут, показать | | |
|
| 5.264, Chaky (?), 02:52, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Java на сегодня единственный язык для живучих больших проектов, для которых живучесть и надежность важнее скорости разработки и скорости приложения. Её нишу возможно займёт кристалл, но пока это лишь мечты(....
| | |
|
| 4.381, Аноним (-), 04:21, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева.
Поэтому если у вас не энтерпрайзный сервак считающий неделю какую там бизнеслогику - получается нечто ужасное, старт hello world на этом больше похож на запуск космической ракеты. И то там наверное меньше действий требуется.
| | |
|
| 3.41, proninyaroslav (ok), 11:35, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Надо учитывать запуск JVM. Тоже самое можно было бы сказать и про шарп (которого тут нет). При запущенном результат был бы куда лучше.
| | |
| |
| 4.46, Аноним (46), 11:47, 08/12/2019 [^] [^^] [^^^] [ответить]
| –5 +/– |
А накуя поделка от Майкрософт? От Майкрософт нам ничего не нужно.
| | |
| |
| 5.162, Аноним (158), 17:47, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Не говори за всех. Если тебе не нужно - это не означает, что никому не нужно
| | |
|
| |
| 5.350, proninyaroslav (ok), 20:12, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> C#: syscalls: 117
> .net core 3.1
Смотрел и судил по скриншоту, там почему то его нет. Но в любом случае показатели не достоверны, так как не ясно насколько быстро работат сам язык, а не просто инициализация + работа языка.
| | |
|
|
| 3.86, Аноним (85), 13:38, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
А ты не думай, а проверь... fpc-3: всего 12 сисколов, между асмом и си.
| | |
|
|
| |
| 2.112, Аноним (111), 15:01, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Наглядно демонстрирует, любителя забивать гвозди микроскопом, и что кроме хелоуворлда на асме ничего не пишется.
| | |
| |
| 3.124, Аноним (124), 15:42, 08/12/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
Си позволяет делать прямые ассемблерные вставки для радикального увеличения скорости конкретных фрагментов.
| | |
| |
| 4.242, Урри (?), 01:00, 09/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
На данном историческом этапе эта задача успешно решается интринсиками.
| | |
|
| 3.169, Аноним (166), 18:24, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Наглядно демонстрирует, любителя забивать гвозди микроскопом, и что кроме хелоуворлда
> на асме ничего не пишется.
Наглядно демонстрирует, что новость можно комментировать не читая и не заходя на сайт автора
rwasa is our full-featured, high performance, scalable web server designed to compete with the likes of nginx. It has been built from the ground-up with no externel library dependencies entirely in x86_64 assembly language, and is the result of many years' experience with high volume web environments. In addition to all of the common things you'd expect a modern web server to do, we also include assembly language function hooks ready-made to facilitate Rapid Web Application Server (in Assembler) development.
https://2ton.com.au/rwasa/
| | |
| |
| 4.208, Аноним (31), 20:49, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>entirely in x86_64 assembly language
удачи ему в запуске этого говна на risc-v и arm. Да даже просто на x86.
| | |
| |
| |
| 6.281, Аноним (280), 07:24, 09/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Рряяя! Это вы не понимаете! Люди должны даже пукать с оглядкой на risc-v! Как так, оно кому-то не нужно?! Ррряяя!
Ну а если серьезно, то за почти 10 лет своего существования риск-пять стала своего рода вейландом среди архитектур. Мы только и слышим, что "вот-вот победим!", а по факту оно так и болтается на уровне микроконтроллеров.
| | |
| |
| 7.288, Аноним (31), 10:12, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Да, нужно поддерживать монополию x86_64 такими проектами и славить Intel ME и AMD PSP. А все остальные архитектуры, включая i586 и i686, не нужны, нужно сидеть на опеннете и раздавать советы выкинуть компы и телефоны на помойку.
| | |
| |
| 8.367, Аноним (367), 14:50, 10/12/2019 [^] [^^] [^^^] [ответить] | +1 +/– | Чтобы не поддерживать монополию, у юзеров должна быть возможность приобрести аль... текст свёрнут, показать | | |
|
|
|
|
|
| 3.382, Аноним (-), 04:25, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Наглядно демонстрирует, любителя забивать гвозди микроскопом,
> и что кроме хелоуворлда на асме ничего не пишется.
Еще кодеки и крипто забыли. Хорошая ассемблерная реализация может чисто сишную разика этак в три подвинуть если компилер с кодогенерацией в неудачном месте протупляет.
Сишники правда немного жульничают сейчас с intrinsics, но по большому счету, это по сути тот же ассемблер и получается, просто чуть более кроссплатформенно и портабельно. Но из-за привязки к особенностям процессоров - именно чуть. Ну то-есть простой фрагмент может быть даже и соберется не только на SSE2 но и на neon каком. Но половина кода завалится за отсутствием потребных эквивалентов команд у железа.
| | |
|
|
| |
| 2.16, йййй (ok), 10:10, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ага, как-же новый системный язык Раст то ей слил по числу инструкций.
| | |
| |
| 3.383, Аноним (-), 04:26, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
игогошечка годится для мелких серверцов, ну вообще совсем не как баш.
| | |
|
|
| |
| 2.19, Аноним (19), 10:31, 08/12/2019 [^] [^^] [^^^] [ответить]
| +6 +/– |
А Go уделал Раст.
А плюсы уделали бы обоих, еслиб использовали printf/write, а не iostreams
| | |
| |
| 3.22, йййй (ok), 10:43, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
У раста еще и выполняемый образ под 6 Mb, против 1 Mb у Go и 12 Kb у C/C++
| | |
| |
| 4.68, Forth (ok), 12:32, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Интересно как это получилось, у меня ни в какую не вышло собрать также, даже с дефолтными опциями компиляторов.
На C вышел бинарник 8 кб, на расте (дебажный билд, по дефолту) 2,5мб.
Как он получил 6мб?
Я уж молчу про прочие характеристики типа числа системных вызовов. У меня для C вышло 24, у него 54.
o_O
P.S Троллинг, не иначе.
| | |
| |
| 5.80, burjui (ok), 13:28, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Да уж, загадка века.
$ cat x.rs
fn main() {
println!("hello");
}
$ rustc x.rs
$ ls -lh x
-rwxr-xr-x 1 burjui users 2.5M Dec 8 12:22 x
$ strip x
$ ls -lh x
-rwxr-xr-x 1 burjui users 207K Dec 8 12:22 x
Ой, а что это? Оказывается, в бинаре 90% занимает отладочная и прочая служебная информация, не влияющая на работу программы (кроме как на стектрейсы).
| | |
| |
| 6.95, Аноним (95), 14:11, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Я ни на что не намекаю, но
govno@pc /tmp $ rustc x.rs
govno@pc /tmp $ ls -lAh x
-rwxr-xr-x 1 govno govno 276K Dec 8 13:59 x
govno@pc /tmp $ strip x
govno@pc /tmp $ ls -lAh x
-rwxr-xr-x 1 govno govno 199K Dec 8 14:00 x
Как ни пытался я так и не смог собрать бинарник больше этого. Может у вас там ночнушки?
| | |
| |
| 7.154, burjui (ok), 17:33, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Нет:
$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)
$ rustc --version
rustc 1.39.0 (4560ea788 2019-11-04)
| | |
| |
| |
| 9.195, имя (ok), 19:55, 08/12/2019 [^] [^^] [^^^] [ответить] | +/– | Говорят, что они к этому весьма близки https github com rust-lang rust issues... текст свёрнут, показать | | |
|
|
| 7.394, Аноним (394), 05:37, 11/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> -rwxr-xr-x 1 govno govno 199K Dec 8 14:00 x
Отличное название, суть передает верно.
> Может у вас там ночнушки?
Это горшки которые?!
| | |
|
| 6.384, Аноним (-), 04:30, 11/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Ну ладно, а чего там на 207 кило? А то сишный бинарь с этим вот, после strip - 14 кило... Ну или с отладкой - так и быть, 16. Это такой пример насколько у растоманов руки из неправильного места? Или они там с go конкурируют за жирноту программ в дефолтном билде?
| | |
| |
| 7.390, burjui (ok), 05:07, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
На этот вопрос я вам ответить не могу, не разбирался, а из какого места руки растут, покажет история. Rust пока что молодой, а у старика C за плечами почти 50 лет развития и полировки. Учитывая, как приятно писать на Rust, и какова его производительность, можно точно сказать одно - для 9-летнего щегла весьма неплохо. А компилятор доработают.
| | |
| |
| 8.395, Аноним (394), 05:43, 11/12/2019 [^] [^^] [^^^] [ответить] | –1 +/– | По-моему размер сгенеренных бинарей - показывает Go конечно еще и не так умеет ... текст свёрнут, показать | | |
|
| 7.403, Аноним (426), 13:08, 11/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Ну ладно, а чего там на 207 кило? А то сишный бинарь
> с этим вот, после strip - 14 кило... Ну или с
> отладкой - так и быть, 16. Это такой пример насколько у
> растоманов руки из неправильного места? Или они там с go конкурируют
> за жирноту программ в дефолтном билде?
Это такой пример, как на опеннете обычно сравнивают жопу с пальцем - в этом случае дин. прилинкованный рантайм со статистическим.
rustc hello_rust.rs -O -C prefer-dynamic && strip hello_rust && ls -al hello_rust
-rwxr-x--- 1 аноним аноним 15296 11 Dez. 17:06 hello_rust
| | |
|
|
|
| 4.331, anonymous (??), 14:58, 09/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
6mb потому что это debug сборка, если собрать релиз с оптимизациями будет 980kb и количество syscall будет 78 а не 120...
| | |
|
| |
| 4.32, йййй (ok), 11:15, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Смешно, что мы сравниваем Rust - убийцу C 21 века, с Go - убийцей PHP 21 века.
| | |
| |
| 5.52, Аноним (54), 12:09, 08/12/2019 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Rust - убийцу C 21 века
Не C, а C++. Второй уже, кстати, убийца, после D. Может быть, у третьего и получится.
> с Go - убийцей PHP 21 века
Какой ещё PHP в XXI веке? Python, Java.
| | |
| |
| 6.55, йййй (ok), 12:11, 08/12/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
На C++ никто не предлагает писать операционки, а на раст не только предлагают, так еще и писать пытаются.
| | |
| |
| 7.67, Аноним (54), 12:28, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Конечно, нет и никогда не было ни BeOS, ни Haiku, ни Symbian…
| | |
| |
| 8.71, йййй (ok), 12:37, 08/12/2019 [^] [^^] [^^^] [ответить] | –1 +/– | О, кстати да, про Symbian забыл Хотя там использовалась очень кастрированная ве... текст свёрнут, показать | | |
| |
| 9.243, Урри (?), 01:03, 09/12/2019 [^] [^^] [^^^] [ответить] | +/– | Исключения - один из множества механизмов С , далеко не самый важный и большой ... текст свёрнут, показать | | |
|
|
| 7.385, Аноним (385), 04:32, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> На C++ никто не предлагает писать операционки
А как же реактос? Им конечно не пользуются даже сами разработчики, но это им не мешает наворачивать ядро на плюсах. Наверное потому что поддержка C VS'ом - уг.
| | |
|
| 6.161, имя_ (?), 17:47, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Какой ещё PHP в XXI веке? Python, Java.
с каждым новым релизом пхп и так движется в сторону питона и явы.
| | |
|
| 5.97, Аноним84701 (ok), 14:15, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Смешно, что мы сравниваем Rust - убийцу C 21 века, с Go - убийцей PHP 21 века.
Кто эти вы и зачем эти "вы" лезут сюда с "выводами" о ЯП после сравнения теплых хелловордов и мягких, дефолтных опций и рантаймов конкретной реализации конкретного компиялтора (или интерпретатора)? o_O
| | |
| |
| 6.396, Аноним (394), 05:44, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Убийство - преступление.
Killall - вообще сплошной геноцид демонов.
| | |
|
|
|
| 3.49, Аноним (54), 11:57, 08/12/2019 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> плюсы уделали бы обоих, еслиб использовали printf/write, а не iostreams
Тогда не было бы отличий от реализаций на C.
| | |
|
| 2.314, Аноним (314), 13:07, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Да, rust язык очень полезный. Программистом, которые пишут код на С++, работающий медленнее написанного на расте дорога одна, переходить на раст. Им ничто уже не поможет
| | |
|
| 1.17, Анони (?), 10:25, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
Как сказал когда-то мой препод: "писать на ассемблере под Линукс - это самоубийство".
| | |
| |
| 2.64, Ordu (ok), 12:26, 08/12/2019 [^] [^^] [^^^] [ответить]
| +6 +/– |
 Что он имел в виду? Под linux писать на асме гораздо приятнее чем под DOS или под Windows.
| | |
| |
| 3.92, Ананимас009 (?), 14:00, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Что он имел в виду? Под linux писать на асме гораздо приятнее
> чем под DOS или под Windows.
¿А что не так с MS/PC/DR DOS?
Ровно два прерывания: одно для вывода текста, второе для завершения процесса.
| | |
| |
| 4.116, Ordu (ok), 15:21, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Что он имел в виду? Под linux писать на асме гораздо приятнее
>> чем под DOS или под Windows.
> ¿А что не так с MS/PC/DR DOS?
> Ровно два прерывания: одно для вывода текста, второе для завершения процесса.
Не, так оно только в первой половине учебника ассемблера для дос. Дальше выясняется, что всё гораздо-гораздо интереснее, и в учебнике не написано как работать с мышью, со звуком так вообще надо с железом общаться напрямую, причём с разными звуковухами по разному, работа с видеокартой -- это отдельная песня, и про неё написаны отдельные книги, и много других очень увлекательных вещей можно узнать.
| | |
| |
| 5.244, Урри (?), 01:05, 09/12/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Для мыши есть int 33. И в учебниках это было описано еще тогда, когда вас у родителей и в планах не было.
| | |
| |
| 6.259, Ordu (ok), 02:10, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Для мыши есть int 33. И в учебниках это было описано еще
> тогда, когда вас у родителей и в планах не было.
Возможно в каких-то и было описано. Я не видел ни в одном, выяснял как работать с мышью дизассемблированием. Когда вас в планах родителей не было, у меня не было не то что интернета, даже и FIDO никакого не было, и поэтому знания приходилось выгрызать.
| | |
| |
| 7.268, Урри (?), 03:48, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
У меня тоже ни интернета, ни фидо не было. Но мне, видимо, повезло - я жил не в ебенях и походы по вычислительным лабораториям местных институтов зачастую приносили хорошие плоды в виде файлов документации (а иногда и распечаток).
| | |
|
| 6.413, Аноним (-), 03:43, 14/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Для мыши есть int 33. И в учебниках это было описано еще
> тогда, когда вас у родителей и в планах не было.
Ага, а у современного железа с IOAPIC это может быть... эээ... у APIC много прерываний. И кстати что такое int33, допустим, в контексте usb? USB как таковой вообще прерываниями не оперирует. Хоть какие-то приколисты и назвали один из типов транзакций interrupt, но это не имеет ничего общего с прерываниями проца.
| | |
|
|
| 4.172, Аноним (166), 18:34, 08/12/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Что он имел в виду? Под linux писать на асме гораздо приятнее
>> чем под DOS или под Windows.
> ¿А что не так с MS/PC/DR DOS?
> Ровно два прерывания: одно для вывода текста, второе для завершения процесса.
У x86 (16-ти разрядный набор команд) нет плоской модели памяти, приходится заморачиваться с сегментами, а регистры "общего назначения" заметно специализированы. Если бы всё было так же просто как в 32-х и 64-х режимах, в то время больше бы писали на ассемблере, поскольку тогда компиляторы заметно отставали по скорости сгенерированного кода.
| | |
| |
| 5.245, Урри (?), 01:11, 09/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– | |
В то время на ассемблере больше и писали. Ассемблер был везде. И никаких "заморочек" с сегментами не было.
Дожили, помнить что "физический адрес = сегмент*16+смещение", это заморочки. Поколение вебмакак уже в элементарную математику второго класса общеобразовательной школы не может.
А селекторы в 32 и 64 - не заморочки? Кто из вас сможет с ручкой в руках привести линейный адрес в физический? Кто из вас вообще в курсе, что в памяти есть специальная таблица трансляции, куда надо обратиться по специальному селектору, чтобы узнать куда и как смещать линейный адрес, какой размер страницы в памяти и присутствуют ли они вообще физически? А перед этим еще надо права доступа проверить... "Заморочки" у них, тьфу.
| | |
| |
| 6.276, Аноним (166), 06:25, 09/12/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
> В то время на ассемблере больше и писали. Ассемблер был везде. И
> никаких "заморочек" с сегментами не было.
Ты ещё заяви, что асм PDP11 столь же прост, как этот ваш 8086.
> Дожили, помнить что "физический адрес = сегмент*16+смещение", это заморочки.
Сразу видно мосье теоретика-математика. Данные занимают 16 байт, адрес 24, что накладывает ряд ограничений на древовидные структуры данных.
> А селекторы в 32 и 64 - не заморочки?
Столь много и красиво написал, и так бездарно слился. Знай: в юзермоде не используются.
> бла-бла-бла
Ну, расскажи нам, зачем нужен префикс lock.
| | |
| |
| 7.296, Урри (?), 11:07, 09/12/2019 [^] [^^] [^^^] [ответить] | +2 +/– | Ахахахах, обезьянка обиделась и с головой бросилась повторно позориться Сразу в... большой текст свёрнут, показать | | |
| |
| 8.347, Аноним (166), 19:57, 09/12/2019 [^] [^^] [^^^] [ответить] | +/– | Да, бомбануло её знатно Под ДОС на асме она исписались, а читать русский язык н... большой текст свёрнут, показать | | |
|
| 7.373, suffix (ok), 00:23, 11/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
 >Ты ещё заяви, что асм PDP11 столь же прост, как этот ваш 8086.
А что там сложного то ?
Кол ассигн по k-ому каналу, по n-ому флагу и т.д.
| | |
| |
| 8.397, Аноним (166), 08:11, 11/12/2019 [^] [^^] [^^^] [ответить] | +1 +/– | В том то и дело, у PDP11 простая и понятная система команд, позволяющая кодирова... текст свёрнут, показать | | |
|
|
|
|
|
| 3.107, Анони (?), 14:53, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Что он имел в виду?
Ух как заминусовали то... А то, что прикладное ПО под линукс предпочтительно должно быть мультиархетиктурным, наверно, забыли.
Под вынь, конечно же, которая до недавнего времени только x86, ясен пень легче, тем более ДОС.
| | |
| |
| 4.125, Ordu (ok), 15:44, 08/12/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Ой, ну это же совершенно отдельный вопрос Это сильно зависит от того, что ты пи... большой текст свёрнут, показать | | |
| |
| 5.246, Урри (?), 01:24, 09/12/2019 [^] [^^] [^^^] [ответить] | +2 +/– | Вы прочитали монолог типичного диванного враля Начиная с того, что у него есть... большой текст свёрнут, показать | | |
| |
| 6.263, Ordu (ok), 02:28, 09/12/2019 [^] [^^] [^^^] [ответить] | –1 +/– | А мне какое дело до того, что он продаётся У меня его нет И покупать его я не ... большой текст свёрнут, показать | | |
| |
| 7.269, Урри (?), 04:11, 09/12/2019 [^] [^^] [^^^] [ответить] | +2 +/– | Если бы вы не писали с таким пафосом, словно вы суперпрофессионал, при этом неся... большой текст свёрнут, показать | | |
| |
| |
| 9.297, Урри (?), 11:08, 09/12/2019 [^] [^^] [^^^] [ответить] | +1 +/– | При чем здесь винапи Я писал про справочник интов - биоса, доса и дополнительно... текст свёрнут, показать | | |
|
| 8.308, Ordu (ok), 12:15, 09/12/2019 [^] [^^] [^^^] [ответить] | –2 +/– | А, вы из этих, кому обязательно повоспитывать окружающих Вы из тех, кто на доро... большой текст свёрнут, показать | | |
|
| 7.356, Ананимас009 (?), 00:43, 10/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Прерываниыми биоса для вывода текста никто и не пользовался. Серьезные поцанчики работали напрямую с видеопамятью, борясь со снегом для CGA. Ну или досовскими, если речь была про хелловорлд.
| | |
|
|
|
|
|
| 2.72, Forth (ok), 12:55, 08/12/2019 [^] [^^] [^^^] [ответить]
| +8 +/– |
Возможно. На ассемблере под Linux не писал, а вот под FreeBSD было дело.
Версия кажется была 4.11, точно не помню.
Я тогда студентом был, а первые появившиеся бесплатные хостинги позволяли либо php4 (как-то выглядело непривлекательно :/ ) либо CGI.
А мы с одногруппником хотели чат сбацать, тогда это было в тренде, свой чатик.
Он на html лепил это всё, а мне досталась серверная часть.
Я, преодолевая отвращение, слепил на php, оно тормозило безбожно и периодически вместо фрейма с чатом вылезала врезка от хостера, что мол ресурсы превышены :))
Не помню как я пришел в этому решению, студент все-таки, времени полно. Я сделал бинарник для CGI на ассемблере. Есстественно он был статический, какие нафиг libc. Три-четыре нужных системных вызова, типа read,write и shared memory вызовов попросту подсмотрел в исходниках libc как оно вызывается, какая конвенция и все такое.
Работало не то слово - летало. Все CGI бинарники писали в общую память, при обновлении страницы попросту выдавался хвост этого кольцевого буфера с текстом чата.
Смутно припоминаю размер ELF результирующий был меньше килобайта и без ld.so запускался, так что куда уж быстрее-то?
| | |
| |
| 3.83, Ананимас009 (?), 13:33, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Во времена четверочки делал перл скрипт, который изображал из себя хттп сервер. Т. к. памяти на эти ваши апачи с похапе не хватало. 128м было на железке и ей нужна была память для более важных вещей, чем мониторинг.
| | |
| |
| 4.91, Forth (ok), 13:54, 08/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Тогда модно было lighttpd, когда апача было чересчур.
На фоне этого безобразия с апачем для статики и nginx как раз поднялся. Конечно, спрос есть есть и предложение.
| | |
| |
| 5.110, Ананимас009 (?), 14:58, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Тот перл скрипт был и сервером и полезной нагрузкой. И занимал копейки памяти.
8ачем сейчас так извращаться - для меня загадка. Уж лучше написать модуль для нжинкс.
| | |
| 5.133, Аноним84701 (ok), 16:14, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ещё в природе существует https://github.com/nemasu/asmttpd
Это про который в опеннетной новости писали
> Интересно, что несмотря на то, что код написан на ассемблере, проведённые (https://news.ycombinator.com/item?id=9571827) пользователями тесты производительности показывают
> существенное отставание по скорости обработки запросов от современных http-серверов, написанных на языке Си.
(а еще сам автор собирался делать:
https://github.com/nemasu/asmttpd/issues/9
My current plan for handling 10k+ connections, will edit as it's improved.
Comments are welcome :)
Idea: Don't block on anything until it's ready. When waiting for I/O, accept more connections.
+Asynchronous I/O.
+Non-blocking sockets.
+Multi-threaded.
+Self contained threads.
| | |
| |
| 6.151, Аноним (151), 17:17, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Может asmhttpd не на производительность заточен, а на потребление памяти. Вон в rwasa бенчмарке от производителя тоже написано что при определенных видах запросов nginx его обгонят.
| | |
| |
| 7.423, Аноним (-), 04:17, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Может asmhttpd не на производительность заточен, а на потребление памяти.
А lwan'а он делает? Этот и на производительность и на потребление памяти смотрит, автор явно шпарит в оптимизациях. И к тому же он может делать более-менее практичные вещи - вплоть до шаблонов и БД (см примеры, там реализации ряда вебапликушных бенчей - даже с базами и ответами в JSON). Правда lwan на си. Да и основная фича - удобный API handler'ов. А coroutines обеспечивают довольно прозрачную работу всего этого.
| | |
|
|
|
|
|
|
| 1.18, Аноним (18), 10:26, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +14 +/– |
Как же бесят все эти бенчмарки на хелловорлдах. Только вводят в заблуждение новичков, которые стоят сейчас перед выбором и черпают информацию у таких вот фанатиков.
| | |
| |
| 2.21, Кирилл (??), 10:39, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
А потом бывшие новички, не попавшие в заблуждение, начинают писать многопоточчный код на джаве, дающий 300% оверхеда на порождение этого самого множества потоков. Т.е. на 6-8 ядерниках оно в принипе выиграет, но отзывчивость...
| | |
| |
| 3.26, Илья (??), 10:59, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вы не знали, что во названных в статье языках можно реализовать любые многопоточные модели?
| | |
| |
| 4.108, qetuo (?), 14:53, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Удачи тебе на гошке реализовывать неродные для нее модели. У нее интероп с сишкой сделан настолько хорошо, что если вставлять sleep(1) в каждый вызов к сишному коду, то получится лишь ненамного хуже.
| | |
|
| 3.69, Crazy Alex (ok), 12:33, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
 И в какой-то момент они узнают, что поток порождается один раз, а потом ему только задания подкидывают. А так же 100500 других приёмов. И что?
Впрочем, с тех пор, как джава оказалась в андроиде, я сам на неё чертыхаюсь. Хотя она была и есть на своём месте в больших сложных приложениях, в которых проблема - сделать, чтобы они просто работали, а скорость - ну это уже как выйдет.
| | |
| |
| 4.214, Vkni (ok), 21:17, 08/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Хотя она была и есть на своём месте в больших сложных приложениях
Только там сложность зачастую искусственная.
| | |
| 4.247, Урри (?), 01:30, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Там другая джава, ее даже джавой называть, наверное, нельзя. Хотя теперь уже и не она тоже.
Напомню, что гугель (точнее ребята, которых он купил), написали свою джаву с блекджеком и мигалками; регистровую(а не стековую!!), просто бинарно совместимую с оракловой.
| | |
|
|
|
| 1.23, Аноним (23), 10:45, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> простейшего приложения (вывод 'hello')
Я не пишу такие простейшие приложения, кому они нужны?
Если же писать что-то более полезное, чем «привет мир», то результаты будут, скажем, другое
| | |
| |
| 2.29, Алексей Михайлович (?), 11:04, 08/12/2019 [^] [^^] [^^^] [ответить]
| –5 +/– |
Так в том и дело, что особой разницы не будет. Жаба, как и гадюка, будут всасывать у всех остальных; разница между нормальными языками будет минимальной.
| | |
| |
| 3.36, Аноним (95), 11:26, 08/12/2019 [^] [^^] [^^^] [ответить]
| –5 +/– |
Конец списка переместится в начало достаточно быстро, просто потому что ты не сможешь оптимизировать ассемблер на лету в зависимости от данных, как это делает жит.
| | |
| |
| 4.39, Алексей Михайлович (?), 11:31, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Конец списка переместится в начало достаточно быстро, просто потому что ты не
> сможешь оптимизировать ассемблер на лету в зависимости от данных, как это
> делает жит.
То есть, ты обожрался диссоциативов и теперь утверждаешь, что жаба обгонит ассемблер и нормальные нативно компилируемые языки? Можно пруфца, что ваше тормозное гуано для копипастеров так может?
| | |
| |
| 5.47, Аноним (95), 11:53, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Изи, надо только взять substratevm и выкинуть гц. Но, как и везде, "есть нюанс".
| | |
| 5.48, A.Stahl (ok), 11:56, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Он про JIT говорит. JIT хорошая штука, которая позволяет генерировать эффективный код, а не ограничиваться кодом "который везде будет работать". Посмотри на гентушников собирающих софт под конкретную машину и радующихся своим нескольким дополнительным процентам производительности. Мелочь, а приятно. И иногда эта мелочь отделяет количественное изменеие от качественного.
| | |
| |
| 6.62, Z (??), 12:23, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ага JIT за те мс которые есть у него делает оптимизации лучше чем статический компилятор, ну да, верьте, верьте.
| | |
| |
| 7.104, Аноним (104), 14:43, 08/12/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
 Существуют опции gcc -fprofile-generate -fprofile-use, что позволяют оптимизировать с учётом той же информации, что имеет JIT. В таком случае никаких даже теоретических преимуществ у JIT не остаётся. Но по личным наблюдениям могу сказать, что может быть как двукратный прирост(php), так и нулевой(zlib).
| | |
| |
| 8.414, Аноним (414), 03:52, 14/12/2019 [^] [^^] [^^^] [ответить] | +/– | У Zlib проблемы производительности просто не там Есть всякие zlib-ng и проч, ра... большой текст свёрнут, показать | | |
|
| 7.120, Аноним (95), 15:33, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Никто не заставляет оптимизировать "вотпрямщас" (хотя есть и такая возможность и в рантайме есть _намного_ больше вариантов), никто не заставляет оптимизировать в 1 проход, никто не заставляет оптимизировать только под 1 вариант входных данных.
| | |
|
| 6.70, Crazy Alex (ok), 12:35, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
JIT довольно дорог сам по себе и выгоден далеко не во всех ситуациях. Собственно, у статически скомпилированного кода он выиграет только на приложениях, которые крутятся очень долго с похожими входными данными.
| | |
| |
| 7.134, Annoynymous (ok), 16:18, 08/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Собственно, у статически скомпилированного кода он выиграет только на приложениях, которые крутятся очень долго с похожими входными данными.
Где, собственно, Java и применяется.
| | |
|
| 6.118, Аноним (95), 15:26, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Там не мелочь, производительность может и на порядки отличаться в результате работы pgo. Это без модификации исходников, да. Ручками тоже можно сделать необычные оптимизации, но они будут не универсальны, профиты жита с аот именно в оптимизации под данные.
| | |
|
|
| 4.189, Алексей Михайлович (?), 19:12, 08/12/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Конец списка переместится в начало достаточно быстро, просто потому что ты не
> сможешь оптимизировать ассемблер на лету в зависимости от данных, как это
> делает жит.
А делает он это бесплатно, посредством привлечения чёрной магии. Пока твой JIT только-только сообразит, как перепилить программу под меняющиеся данные на входе, программа на нормальном языке уже выдаст результат.
| | |
|
|
|
| |
| 2.106, Аноним (104), 14:53, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Справедливости ради на Сишечке можно добиться приблизительно тех же результатов. Но от main придётся отказаться. Как и от большинства функций стандартной библиотеки и некоторых функций компилятора. Конечно, сейчас не так много архитектур процессоров как во времена появления Си, но переписывания кода с x86-64 на ARM по прежнему не приносит радости.
| | |
| |
| 3.231, Michael Shigorin (ok), 23:12, 08/12/2019 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> Конечно, сейчас не так много архитектур процессоров как во времена появления Си
Вообще-то дофига и продолжают появляться новые.
| | |
| 3.416, Аноним (414), 03:58, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> во времена появления Си, но переписывания кода с x86-64 на ARM
> по прежнему не приносит радости.
К счастью на си это можно и не делать. Ну так, глядя на 25519 перепертый 1 в 1 с писючного tweetnacl в микроконтроллер. Да, на асме он будет быстрее...
| | |
|
|
| 1.35, Аноним (31), 11:24, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
1. Исходники не на гитхабе, не на гитлюбе, не в gitwebе, а в каком-то архиве. Даже открывать не буду: автор явно нас не уважает.
2. Сравнение некорректно. На С++ можно писать в стиле C. И е
| | |
| |
| 2.38, Аноним (95), 11:28, 08/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Более того, на си можно писать в стиле ассемблера. Уже по результатам си возникают некоторые вопросы, как-то очевидно шуточное сравнение выходит.
| | |
| |
| 3.40, йййй (ok), 11:33, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Здесь используются рекомендованные языком техники, так что с этим все нормально. То что стримы в C++ тормозные и так все знают. Так-то можно и из PHP С-шный модуль дергать. А вот языки со своими виртуальными машинами действительно могут показать некорректные результаты. Так что тест правда скорей шуточный. Им только растоманов троллить :)
| | |
| |
| 4.249, Урри (?), 01:35, 09/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Пошто заминусили человека, макаки?
Представьте себе, был такой язык. И одно время даже достаточно распространенный. Именно С-- (минус минус).
| | |
|
|
| 2.58, Аноним (54), 12:19, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Исходники не на гитхабе, не на гитлюбе, не в gitwebе, а в каком-то архиве.
Это чтобы заодно подсунуть бинарники в расчёте, что их кто-нибудь да запустит…
| | |
|
| 1.37, ф (?), 11:26, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
ну вот!
a говорили, что лапша на баше тормозит загрузку - а оказывается в первой четверке по скорости ;)
| | |
| |
| |
| 3.215, Vkni (ok), 21:23, 08/12/2019 [^] [^^] [^^^] [ответить] | +1 +/– | В bash echo - это builtin Выжимка strace hello_world sh stat hello_worl... большой текст свёрнут, показать | | |
|
| 2.103, Аноним (102), 14:40, 08/12/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
Системд на С так что Поттеринг все правильно сделал. Слава Леониду.
| | |
| |
| 3.135, Аноним84701 (ok), 16:19, 08/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Системд на С
Как и (ba/da/z/k/c/ok/mk)sh.
Впрочем, как и куча реализаций брейнфака (но там и на асме реализации есть). Ждем переписывания на BF.
| | |
| |
| 4.150, Аноним (151), 17:13, 08/12/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ну и спрашивать зачем все по десять раз интерпретировать, когда можно сразу написать на C хотя системд и интерпретирует свои юнит файлы, зато он делает это с уважением и с благословения Лёни Поттеринга.
| | |
|
|
|
| 1.43, Аноним (45), 11:44, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing, предлагающей в том числе реализации протоколов TLS 1.2 и SSH2
Интересно, как образец, чтобы сделать подобное для микроконтроллеров RV32, RV64, где ограничено количество ПЗУ и ОЗУ.
| | |
| |
| |
| 3.114, Аноним (166), 15:10, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Кто интересуется ассемблером могу еще порекомендовать https://github.com/Number571/asmlib
> набор простых библиотек типа печать строк, чисел.
Ты лучше расскажи, почему иссую не закрыл. Там даже по-русски объяснили, почему либа полурабочая.
| | |
| |
| 4.119, Аноним (102), 15:30, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Я не автор, но от себя скажу что ваши syscall это вкусовщина, а int 0x80 работает и на 32 и на 64 битных системах. Да и тем более исходники открыты.
| | |
| |
| 5.144, Аноним (166), 16:46, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Я не автор, но от себя скажу что ваши syscall это вкусовщина,
> а int 0x80 работает и на 32 и на 64 битных
> системах. Да и тем более исходники открыты.
Да, исходники открыты. Вот возьми их и почитай, посмотри, с какими ограничениями он работает.
| | |
| |
| |
| 7.163, Аноним (166), 17:48, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> С незначительными.
Ну так то да. Всего-то наполовину меньше. Действительных разрядов в адресе. ;)
| | |
|
|
| 5.233, Michael Shigorin (ok), 23:15, 08/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> а int 0x80 работает и на 32 и на 64 битных системах
...прям стесняюсь спросить, Вы точно про ARM, MIPS или даже e2k?..
| | |
| |
| 6.311, Аноним (313), 13:03, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
...прям стесняюсь спросить а в fasm уже подвезли поддержку e2k? Из коробки он и ARM и MIPS тоже не поддерживает. Так что шутка мимо.
| | |
| |
| 7.342, Аноним (166), 19:35, 09/12/2019 [^] [^^] [^^^] [ответить] | +/– | The FASMARM package is a free ARM cross-assembler add-on for FASM Runs under Win... большой текст свёрнут, показать | | |
|
|
|
|
|
|
| 1.57, Аноним (57), 12:17, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Джефф Мэррисон (Jeff Marrison), автор реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing
для каллибриОС штоли
| | |
| |
| 2.200, Аноним (198), 20:34, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
А что, нельзя прилинковать её к сишной программе и дёргать из сишного кода?
| | |
|
| |
| |
| 3.422, Аноним (-), 04:13, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Удивительно, как Питон почти на порядок просел относительно него.
Удивительно - что это говорит разработчик из, кажется, BSD. Который мог бы и догадываться почему.
| | |
|
|
| 1.73, Аноним (73), 13:01, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Попробовал самостоятельно провести тест, исплользуя Си (puts) и tcc. Получил 24 taskclock.
| | |
| |
| 2.74, Аноним (73), 13:02, 08/12/2019 [^] [^^] [^^^] [ответить] | +/– | gentoo code perfomance tcc hello_puts c -o hello_puts gentoo code perfoman... большой текст свёрнут, показать | | |
| |
| 3.417, Аноним (414), 04:01, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
У tcc есть один нюанс: компилим им какую-нибудь алгоритмику... и убеждаемся что gcc его очень сильно обижает с -O2/-O3. И дальше радости с уменьшения числа сисколов будет маловато.
| | |
|
| 2.142, Аноним (54), 16:43, 08/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Попробуй слинковать статически. Лучше с musl. У меня получилось 5 для hello_c_stdio и 4 для hello_c_syscall.
| | |
|
| 1.75, Аноним (102), 13:17, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Делал как-то текстовый парсер на асме и для сравнения тот же парсер сделал на C++ (на самом деле все было наоборот). Код на асме работал в три раза быстрее и при этом 75% времени по strace занимали операции чтения файлов. Самым близким по производительности для моей задачи была реализация xpath из lxml для питона написанная на cython очень близка к коду на C++. А например grep очень сильно отстал. Не претендую на точность и оптимальность алгоритмов поэтому такой новости как сабже и не публиковал.
| | |
| |
| 2.82, Аноним (95), 13:29, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>xpath из lxml для питона написанная на cython очень близка к коду на C++
libxml2 на си написан, не порите чушь - ей больно
| | |
| |
| 3.93, Аноним (102), 14:04, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Начнем с того что lxml это биндинг для libxml2 и libslt https://lxml.de
Заканчивая тем что даже на сайте libxml2 написано применять lxml http://xmlsoft.org/python.html для питона.
Note that some of the Python purist dislike the default set of Python bindings, rather than complaining I suggest they have a look at lxml the more pythonic bindings for libxml2 and libxslt and check the mailing-list.
И в конце концов lxml каким-то мистическим образом работал быстрее применяя cython и выше названные библиотеки.
Вполне вероятно в природе есть более производительные решения я в целом и не настаивал на истину в последней инстанции.
| | |
| |
| 4.101, Аноним (95), 14:24, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Всё ещё не понятно, при чём тут питон и плюсы, если сравнение было с сишечкой.
| | |
|
|
| |
| 3.216, Vkni (ok), 21:26, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тот же Ragel позволяет выдать код лексера, который примерно в 10 раз быстрее сгенерированного flex'ом.
| | |
| 3.287, Anonymoustus (ok), 10:02, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> "Once upon a time my boss asked me to study if we
> should use C++ or Erlang for a specialist XML parser to
> be used in a product (for reasons of speed not energy).
> My recommendations was an FPGA
> We built an FPGA.
> Relative speed of C++/Erlang was irrelevant compared to FPGA."
> https://twitter.com/joeerl/status/1115990630793207808
Ничего, придёт ему на смену задорная молодёжь и перепишет всё это окаменевшее на жлобоскрипте (пихтона они уже знать не будут).
| | |
|
|
| 1.87, ыы (?), 13:38, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Таки да, ассемблер - отличный инструмент для написания хэлловорлдов
| | |
| 1.90, Аноним (90), 13:51, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +10 +/– |
Как этот чел может спать спокойно, осознавая, что все инструменты, которыми он пользовался при записи видео, написаны не на ассемблере?
| | |
| |
| 2.126, VEG (ok), 15:48, 08/12/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Не увидел чтобы автор видео агитировал за написание всего кода на асме. Просто на практике показал что все удобства даются не бесплатно. Обещал ещё показать в следующих частях какие-то преимущества. Скорее всего покажет что компилеры способны генерировать оптимальный код только в простейших случаях, а толково применять SSE/AVX вообще толком не могут, и ручная оптимизация тут рулит на всю катушку. Полагаю, что основной посыл будет использовать асм там где это имеет смысл. Его и используют. Для оптимизации кодеков, например. Надо же чтобы кто-то это рассказал подрастающему поколению, вот автор видео и старается.
| | |
| |
| 3.129, Аноним (90), 16:00, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Компилеры способны генерировать оптимальный код только в простейших случаях
Лол что? Это человек способен генерировать оптимальный код на ассемблере только в простейших случаях. Для большого куска кода у человека от писанины на ассемблере крыша поедет, а о том, чтобы превзойти по оптимальности код компилятора даже речи идти не будет. Современные компиляторы далеко ушли по сравнению с 80-ми, а вы похоже там и остались. Сейчас оптимизация кода производится на многих уровнях, особенно хорошо разработаны оптимизации AST-дерева, которое человек в принципе в голове удержать целиком не способен.
| | |
| |
| |
| 5.210, Аноним (95), 20:58, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Недавно видел историю где слово register (то самое против которого все топят) применённое к переменной-счётчику, ускоряло код в 9999 раз. Компиляторы такие умные сегодня.
| | |
|
| 4.217, VEG (ok), 21:27, 08/12/2019 [^] [^^] [^^^] [ответить] | +2 +/– | Мечтать не вредно, конечно, но компилеры далеки от того, чтобы самостоятельно за... большой текст свёрнут, показать | | |
| |
| 5.252, Урри (?), 01:48, 09/12/2019 [^] [^^] [^^^] [ответить] | +4 +/– | Я делал часть работы по оптимизации libjpeg-turbo Могу объяснить в чем вы правы... большой текст свёрнут, показать | | |
| |
| 6.262, Аноним (260), 02:25, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
"Что же касается оптимизации обычного, не векторизуемого кода - то тут компиляторы дают гарантированную фору человеку. Просто потому, что уже никто не может удержать в памяти весь тот зоопарк сложностей, с которыми работает современный микропроцессор. Все эти микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги и т.д. и т.п."
Вот как раз всего этого компилятор "удержать в памяти" и не может, потому что этой информации у него просто нет и взять ее неоткуда.
Именно этот прискорбный факт и стал основной причиной безвременной кончины интеловского итаниума.
| | |
| |
| 7.271, Урри (?), 04:19, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Ну здрасьте, приехали. Как это нет - у компилятора есть множество того, что мы не сможем сделать; например, возможность построить граф зависимостей по коду и данным; по использованию регистров и самому "попереименовывая" их разбросать в наилучшем порядке.
У gcc специально для вас в асм вставках предлагается использовать не регистры, а условные обозначения с указанием что именно ваша функция (которую гцц не понимает и понимать не должен) использует, что хочет на вход и на выход; после чего гцц с учетом этой инфорации подберет конфигурацию получше, размещая промежуточные данные в одних или других регистрах.
Да много чего есть, чего вам, как человеку, уже недоступно ввиду слишком низкой скорости обработки данных и ограниченности по объему их же.
| | |
| 7.272, Урри (?), 04:22, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Да, кстати. Итаниум умер не поэтому.
Умер он потому, что его время новых инструкций без сохранения обратной совместимости еще не пришло.
Через десять лет время пришло, но повезло в этот раз арму. Итаниум - это же современный арм, разве что с увеличенной адресной шиной.
| | |
|
| 6.285, VEG (ok), 09:49, 09/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Так я как бы о том же о чём и вы говорил в предыдущем комментарии. Хочешь по максимуму задействовать возможности SSE/AVX - переписывай код ручками. На асме или интринсиками в C - уже дело вкуса. А полагаться на то что компилер сам догадается - не приходится. Хотя иногда он таки догадывается как какие-то простые циклы можно векторизовать, но это не точно =)
| | |
|
| 5.327, Аноним (327), 14:16, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Некоторые используют соответствующие различным машинным инструкциям интринсики. Например, такой подход для оптимизации используется в кодеке Opus.
Это все следствие того, что поддержку векторных типов и операций над ними в стандарт С не завезли.
>Но это, по сути, ассемблер с синтаксисом C.
Нет, по сути это не ассемблер. Не нужно вручную распределять регистры, есть проверка типов.
| | |
| |
| 6.421, Аноним (-), 04:11, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Нет, по сути это не ассемблер. Не нужно вручную распределять регистры,
> есть проверка типов.
По сути это возможность использовать почти ассемблерные вещи из типа-сей. Правда, начинаются те же проблемы - а такие интринсики компилятся лишь немногим портабельнее ассемблера, фичи бывают слишком уж специфичными для конкретных архитектур.
| | |
|
|
|
| 3.131, Forth (ok), 16:06, 08/12/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Тут бы лучше взять пример какой-нибудь прикладной задачи, причем не обязательно с плавающей точкой и векторными операциями.
Полно алгоритмов, где важны DMIPS-ы. Тот же поиск короткого пути в графе или например всякие алгоритмы на строках, типа наибольшей общей подпоследовательности.
| | |
| |
| 4.254, Урри (?), 01:51, 09/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Поиск на карте (с частым построением графов), кстати, одна из тех задач, где языки со сборкой мусора уделывают С и плюсами. Кастомные аллокаторы в виде реализации сборки мусора не в счет, естественно.
| | |
| |
| 5.419, Аноним (-), 04:08, 14/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Поиск на карте (с частым построением графов), кстати, одна из тех задач,
> где языки со сборкой мусора уделывают С и плюсами. Кастомные аллокаторы
> в виде реализации сборки мусора не в счет, естественно.
Фича сей и тому подобных в том что если тебе надо GC - его можно сделать. Поэтому кому было надо - у них и си стал довольно высокоуровневым. А вот если в каком-нибудь Go этот самый GC мешается - уже упс.
| | |
|
|
| 3.153, Аноним (31), 17:28, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>а толково применять SSE/AVX вообще толком не могут
OpenCL-компиляторы -- могут.
| | |
| |
| 4.420, Аноним (-), 04:09, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> OpenCL-компиляторы -- могут.
У них даже и не SSE/AVX. У типичного GPU алушек и регистров больше чем у дурака фантиков.
| | |
|
| 3.234, Michael Shigorin (ok), 23:18, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Скорее всего покажет что компилеры способны генерировать оптимальный
> код только в простейших случаях, а толково применять SSE/AVX вообще
> толком не могут, и ручная оптимизация тут рулит на всю катушку.
Вы представляете себе хотя бы количество регистров в нынешних камнях (плюс-минус лапоть)? А таблицы длительности команд под рукой держите?..
Рассказать-то рассказать, да не сказочку, а быль.
| | |
| |
| 4.255, Урри (?), 01:52, 09/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Таблицы, коих на самом деле уже давно нет. Так как конвеер длинный и микрооперации сильно зависят друг от друга и окружающей среды (например, предсказания переходов или кеширования памяти).
| | |
|
|
|
| 1.128, Сергей (??), 15:52, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Интересно, что perl чуть-чуть проиграл bash, с другой стороны все эти тесты говорят об одном - о нагромождение ненужных прослоек в фреймворках.
Вспоминаю молодость, студент, была дадена ес-1840, в качестве задания писал программу на паскале, потом профилирование и переписывание кусков кода с него на ассемблер, благо там это легко было сделать, когда первый раз сделал слегка удивился...
| | |
| 1.141, nc (ok), 16:39, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Это все говорит не о том что надо писать на Ассемблере, а о том, что подходы к компиляции и особенно к "линковке" в языках программирования ужасно устарели. Если на ассемблере программа занимает 9 инструкций, то и на высокоуровневом ЯП она должна занимать 9 инструкций, не больше. А почему занимает больше? А потому что процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нет.
| | |
| |
| 2.146, Аноним (54), 16:49, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нет
Почему же, с разбором. Иди, учи матчасть. Рекомендую: https://linker.iecc.com/ (да, за 20 лет мало что изменилось, но это не значит, что подход устарел).
| | |
| |
| 3.185, Аноним (166), 19:07, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нет
> Почему же, с разбором. Иди, учи матчасть. Рекомендую: https://linker.iecc.com/ (да, за
> 20 лет мало что изменилось, но это не значит, что подход
> устарел).
Напомните, пожалуйста, на какой странице там LTO описано.
| | |
| |
| |
| 5.351, Аноним (166), 20:27, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Зачем ему про LTO? Пусть сначала хоть это осилит.
Автор сообщения #141 описал, какой LTO должна быть. В теории. На практике пока недотягивает... немножко.
| | |
|
|
|
|
| 1.147, Адекват (ok), 16:51, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Не хочу показаться занудным, но в случае с ассемблером он сначала просто запустил бинарик, а потом второй раз через strace. Во время второго запуска программа считывалась из памяти а не с винта. В случае с СИ он сразу запускал бинарик через strace, то есть были доп затраты на чтение с винта. Как-то так.
| | |
| 1.165, Аноним (165), 18:08, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Я просто шокирован как он быстро пишет код в real-time и по памяти может воспроизвести код (пусть и простейший) нескольких языков.
| | |
| |
| 2.256, Урри (?), 01:54, 09/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты уверен что это был первый дубль и без подготовки? И без бумажки?
| | |
|
| 1.176, Главный Ананим (ok), 18:42, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Почему у Си-плюсов на порядок больше инструкций чем у чистого Си? А как же оптимизирующие компиляйторы, которые якобы компилируют код Си и Си++ выполняющий одни и те же действия в одни и те последовательности инструкций? Кто то нам врёт, только вот кто?
| | |
| |
| 2.187, Аноним (166), 19:10, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Почему у Си-плюсов на порядок больше инструкций чем у чистого Си?
Из-за использования потоков ввода-вывода. Иначе говоря, дело в реализации стандартной библиотеки, а не в языке.
| | |
| 2.194, Моржовый (?), 19:54, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Потому что у них разные стандартные загрузчики (stub'ы), у плюсов стандартная библиотека толще.
| | |
| 2.213, erthink (ok), 21:12, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Потому-что в этом тесте запуск приложения на Си требует загрузки ld.so и libc.so, на для приложения на С++ дополнительно требуется libstdc++.so, а также вызова конструкторов и деструкторов для всех статических объектов (включая инфраструктуру Thread Local Storage).
Если различной "магией" избавиться от вышеуказанного, то разницы с ассемблером для C, C++ и Rust не будет _совсем_.
| | |
|
| |
| 2.184, svsd_val (ok), 19:00, 08/12/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Хорошие языки, ничего против не имею, кстати интересно было бы увидеть и их тесты
| | |
| |
| |
| 4.357, svsd_val (ok), 04:25, 10/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Что же в делфи хорошего? Разве что, если с Жавой сравнивать.
В прямых руках не хуже сей++ и скорость разработки П.О. выше и косяков меньше. А если руки из опы тут увы извиняйте нечего на язык пинать коли с головой руки из опы, тут никакой язык не поможет.
В своё время писал на нём игры и 64кб демки, особых проблем не видел. А с применением FPC портировал под Linux и Darwin ...
| | |
|
|
|
| 1.178, svsd_val (ok), 18:49, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Не вижу ничего особого в этих тестах, да это только холодный запуск и выход... Да для каждого языка эти процессы уникальные, хотелось бы видеть расчёт производительности непосредственно... правда тогда эти расхождения не будут столь существенными.
Ассемблер это конечно хорошо и Я сам часто им пользовался в ускорении математических операций, но что то тяжёлое делать на нём я бы всё же не стал, имхо поддерживать это будет очень и очень сложно, да и выстрелить себе в ногу в разы легче чем в том же си...
Теперь подумаем по поводу разумного соотнесения плюшек и производительности. На ассемблере программист должен сам за всё отвечать за каждый пук... Другие языки же решают свои задачи и предоставляют те или иные плюшки чем облегчают работу программисту и уменьшают количество возможных ошибок.
имхо, нужно было бы проверить на циклах, математики к (примеру умножение двух матриц) и работы со строками... тогда можно увидеть более интересную картинку, многие языки будут в этом тесте вести себя одинаково.
| | |
| |
| 2.197, СеменСеменыч777 (?), 20:09, 08/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Еще один хипстор опубликовал видосик. И как я его в Links посмотрю?
на хоткей вешаем связку
youtube-dl | awk '... извлечь имя_видеофайла ...'
mpv имя_видеофайла
echo 1-Удалить видео
echo 2-Еще раз посмотреть видео
echo 3-Выход
accept
| | |
|
| 1.196, Моржовый (?), 19:58, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Вот аналог программы на ассемблере, написанный на C:
/*
*!gcc -e_Main -nostdlib -o "%<" % -lmsvcrt -lkernel32 && "%<"
*/
#include <stdlib.h>
#include <stdio.h>
#include <windows.h>
void Main()
{
char s[] = "hello\n";
const unsigned sSize = sizeof(s)/sizeof(s[0]) - 1;
/*fwrite(s, sSize, 1, stdout);*/
DWORD outCnt;
WriteConsole(
GetStdHandle(STD_OUTPUT_HANDLE), //handle to a console screen buffer
s, //pointer to buffer to write from
sSize, //number of characters to write
&outCnt, //pointer to number of characters written
NULL //reserved
);
/*WriteFile(
GetStdHandle(STD_OUTPUT_HANDLE), // handle to file to write to
s, // pointer to data to write to file
sSize, // number of bytes to write
&outCnt, // pointer to number of bytes written
NULL // pointer to structure needed for overlapped I/O
);*/
}
И, внезапно, окажется что это то же самое что и асм, только приятней и проще.
| | |
| |
| 2.211, Аноним (211), 21:01, 08/12/2019 [^] [^^] [^^^] [ответить]
| +8 +/– |
Mscvrt, windows.h? Это ты так пошутил? Плохое место ты для этого выбрал.
| | |
| 2.219, erthink (ok), 21:30, 08/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
На Windows для всех языков не будет такой большой разницы, т.е. все сильно сместится в сторону Java. Это просто последствия намеренного дизайна Windows, и уже без возможности что-либо существенно изменить.
Но если же предложенное проделать в нормальных ОС, то действительно, для C, C++ и Rust с ассемблером существенных различий не будет. Точнее говоря, разница будет определяться только объемом оставленного "сервиса" (stdio, std::iostream, etc).
| | |
| 2.282, Аноним (166), 07:48, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> /*WriteFile(
> GetStdHandle(STD_OUTPUT_HANDLE), // handle to file to write to
> s, // pointer to data to write to file
> sSize, // number of bytes to write
> &outCnt, // pointer to number of bytes written
> NULL // pointer to structure needed for overlapped I/O
> );*/
> }
> И, внезапно, окажется что это то же самое что и асм, только
> приятней и проще.
Оказывается, ты не понимаешь, что этот "аналог" использует kernel32.dll и ntdll,dll, а вариант для Linux вызывает непосредственно ядро.
| | |
| |
| |
| 4.338, Аноним (166), 19:24, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Не угадал. Вызывает kernel32.dll, то есть API подсистемы Win32. API операционной системы Windows NT является Native API. Впрочем, это не имеет отношения к тому, что подобное сравнение некорректно. В Windows NT так же возможно вызывать ядро, но номера системных вызовов различаются от версии к версии.
| | |
| |
| 5.358, Аноним (327), 04:41, 10/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Нет, это не другое. Подсистема входит в ос, апи публичный, практически все приложения используют его. WriteFile и GetStdHandle от write и open принципиально не отличаются.
| | |
| |
| 6.361, Аноним (166), 10:23, 10/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Нет, это не другое.
Вызов ядра непосредственно через шлюз идентичен динамическому связыванию?))
> Подсистема входит в ос, апи публичный, практически все
> приложения используют его.
Аналогично можно сказать про libc.so
> WriteFile и GetStdHandle от write и open принципиально
> не отличаются.
Вот оно что.))) Пример на асме вызывает не write и open из библиотеки пространства пользователя. Функции определены как sys_write и sys_open макросами, подобными нижеприведённому:
#define SYSCALL_DEFINE0(sname) \
SYSCALL_METADATA(_##sname, 0); \
asmlinkage long sys_##sname(void); \
ALLOW_ERROR_INJECTION(sys_##sname, ERRNO); \
asmlinkage long sys_##sname(void)
https://github.com/torvalds/linux/blob/v5.4/include/linux/syscalls.h#L207
| | |
|
|
|
|
| 2.291, Anonymoustus (ok), 10:39, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
На будущее, анон, пиши код в тегах:
[CODE]
[CODE]
твой говнокод
[/CODE]
[/CODE]
На опеннете негодный парсер, так что запоминай, ибо повторять напряжно.
| | |
|
| 1.220, Vkni (ok), 21:38, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Промерял Ocaml - 59 syscalls. Программа:
let _ = print_string "hello\n"
Компиляция
ocamlopt.opt -O3 -inline 1000 hello_ml.ml -o hello_ml
| | |
| |
| 2.283, Аноним (166), 08:06, 09/12/2019 [^] [^^] [^^^] [ответить] | +/– | Тоже померял code ocamlc hello ml -o hello_ocamlbytecode strace -fc microca... большой текст свёрнут, показать | | |
|
| 1.237, Аноним (237), 23:30, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
assembler - не язык программирования. Это транслятор кода. Вы ведь не пишете на компиляторе? Правильно говорить "язык ассемблера". Традиционная ошибка русскоговорящих.
| | |
| |
| 2.257, Урри (?), 01:58, 09/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Не занудствуй.
И вообще - javac это транслятор, компилятор и/или линковщик? Особенно учитывая, что выходной байткод будет интерпретировать, транслироваться и/или компилироваться в зависимости от фазы луны и настроения jit?
| | |
| 2.261, Аноним (261), 02:12, 09/12/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты же не пишешь на языке программирования, а печатаешь? Хотя возможно с таким синдромом граммар-наци у тебя и есть парочка скриптов, накарябанных на бересте...
| | |
|
| |
| 2.292, Anonymoustus (ok), 10:42, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Кто хочет глянуть на реализацию хелловорлда на 441(четырехста сорока одном!) языке программирования
> - велкам на розеттукод: https://rosettacode.org/wiki/Hello_world/Text
Ты открыл для себя Розеттский Камень, надо же! :)
Там не только хелловорлды, но много всякой разной твари, в том числе игрушки.
ЗЫ
Тем не менее, плюсую за комментарий.
| | |
|
| 1.267, Аноним (267), 03:16, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
А может проблема не в языках и компиляторах, а в том, что x86 просто неадекватна для реализации высокоуровневых ЯП? В 70-х Xerox Alto с тактовой частотой 5,88 МГц и 128-256 Кбайт памяти поддерживал весьма продвинутую мультимедийную ОС с оконным интерфейсом и интерактивной средой разработки, которая была написана на объектно-ориентированном языке с поздним связыванием и динамической типизацией (Smalltalk, кто не слишком представляет, что это за язык, представьте себе ОС полностью на Ruby). Здесь можно почитать, как это все разрабатывалось (и про аппаратную архитектуру): http://worrydream.com/EarlyHistoryOfSmalltalk/
| | |
| |
| |
| 3.300, Урри (?), 11:16, 09/12/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
То, что вы в своем детском саду не знаете, еще не значит что никто не знает.
Почитайте, хотя бы, мануалы интела - можете погуглить по страшным словам "микрооперация", "реордеринг", "бренч предикшн", "конвеер", "переименование регистров", "лейтенси".
Другое дело, что весь этот конвеер настолько сложен, что все сложнее хелловорлда в голове уже не уместится.
| | |
| |
| 4.305, Anonymoustus (ok), 11:35, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> То, что вы в своем детском саду не знаете, еще не значит
> что никто не знает.
> Почитайте, хотя бы, мануалы интела - можете погуглить по страшным словам "микрооперация",
> "реордеринг", "бренч предикшн", "конвеер", "переименование регистров", "лейтенси".
А ты, я гляжу, прямо знаток по всем вопросам. И слова какие умные знаешь, молодец. Ну так расскажи всем: есть внутри интеловских процессоров x86 или нету?
| | |
|
|
| 2.324, Аноним (324), 13:49, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Может в этом то все и дело что создать что-то действительно разухабистое на языке с динамической типизацией достаточно трудно. А работало быстро потому что ничего сложно и не делали. Да и вообще этот Xerox Alto это попытка внедрить разработки Дугласа Энгельбарта в жизнь. https://www.youtube.com/watch?v=yJDv-zdhzMY и как все знают неудачная.
| | |
|
| 1.279, Аноним (279), 06:59, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Спасибо господину Джеффу Мэррисону, теперь я знаю на чём надо писать программу, которая выводит строку "hello".
| | |
| 1.284, Аноним (284), 09:16, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Что сразу бросилось в глаза, у него второй питон а не третий, также не указаны версии интерпретаторов и компиляторов.
| | |
| |
| |
| 3.317, Аноним (313), 13:20, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
От нас скрывают правду микропитон быстрее Go и Rust. Вот это скандалы, интриги, расследования показать все что скрыто. А казалось бы заурядная новость про какие-то левые тесты.
| | |
| |
| 4.329, анонн (ok), 14:49, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
 > От нас скрывают правду микропитон быстрее Go и Rust.
А сказать аноним хотел что? Или в пальцах чесалось, аж мочи терпеть не было?
Вопрос выше был о версиях питона, а прикол тут в том, что у 2.7 при старте задействует заметно больше колов.
| | |
|
| 3.318, Аноним (313), 13:23, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Кстати да релевантнее запускать уже разобраный pyc байт код, а не прост текст еще не разобранный. python -m compileall
| | |
| |
| 4.325, Аноним (95), 13:59, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
Так цель была показать что скрипты это фу и все должны срочно начинать писать на ассемблере (ни в коем случае не на си).
| | |
| 4.330, анонн (ok), 14:53, 09/12/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Кстати да релевантнее запускать уже разобраный pyc байт код, а не прост
> текст еще не разобранный. python -m compileall
Запускай - так и быть, разрешаю! Правда, сисколов будет ровно столько же, но …
| | |
| |
| 5.333, Аноним (334), 18:23, 09/12/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Лол спасибо Только ты очередной раз показал своё незнание Сисколов будет не ст... большой текст свёрнут, показать | | |
| |
| 6.348, анонн (ok), 19:59, 09/12/2019 [^] [^^] [^^^] [ответить] | +/– | Плохая из тебя ванга, аноним Ну и знаток похоже тоже - неважнецкий code t... большой текст свёрнут, показать | | |
|
|
|
|
|
| |
| 2.418, Аноним (-), 04:03, 14/12/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> В Haskell автор не смог? That's a shame.
Ну так смоги ты и выложи результаты, например?
| | |
|
|
