The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Опубликованы тесты простейших приложений на различных языках программирования.

08.12.2019 08:08

Джефф Мэррисон (Jeff Marrison), автор реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing, предлагающей в том числе реализации протоколов TLS 1.2 и SSH2, опубликовал видео под названием «Зачем писать на ассемблере?». В видео приводятся результаты тестирования при помощи утилит perf и strace простейшего приложения (вывод 'hello'), написанного на 13 языках программирования.

Следует отметить, что в тесте сравнивается не эффективность языков, а сопутствующие затраты на загрузку исполняемого образа и инициализацию сред выполнения для языков Assembler, C, C++, Go, Rust, Python 2, Perl, TCL, Java, PHP, NodeJS, Ruby и Bash. Использованные в видео примеры доступны для загрузки.



  1. Главная ссылка к новости (https://2ton.com.au/videos/tvs...)
  2. OpenNews: Сравнение производительности сетевого драйвера в вариантах на 10 языках программирования
  3. OpenNews: Сравнение производительности различных реализаций WebAssembly
  4. OpenNews: Сравнение производительности сетевых подсистем DragonFly BSD, FreeBSD и ядра Linux
  5. OpenNews: Сравнение производительности PHP 7.0, PHP 5.6.16 и HHVM 3.10.1
  6. OpenNews: Сравнения языков программирования с позиции безопасности написанного на них кода
Автор новости: Аноним
Тип: Обобщение
Короткая ссылка: https://opennet.ru/51992-lang
Ключевые слова: lang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (421) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:25, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +21 +/
    А теперь пусть напишет на асемблере бизнес логику
     
     
  • 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 не нужен, это сложно!

     
     
  • 6.113, dd (??), 15:01, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –7 +/
    sqlite это шаг к реестру винды,  no way
     
     
  • 7.122, kai3341 (ok), 15:36, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >  sqlite это шаг к реестру винды,  no way

    То есть вы настаиваете на том, что идейность важнее здравого смысла?
    Кстати, где вы реестр нашли? Хм. Похоже, идейность уже заменила вам здравый смысл.

     
     
  • 8.137, Аноним (54), 16:22, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Где ты нашёл здравый смысл sqlite тормозит сильнее, чем xapian ... текст свёрнут, показать
     
     
  • 9.157, kai3341 (ok), 17:42, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    А чтобы поиск не тормозил, мы в дополнение к базе пакетов на диске добавим xapia... текст свёрнут, показать
     
     
  • 10.190, имя (ok), 19:17, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Xapian 8212 библиотека, а не сервис Вас, видимо, очень больно покусали фанат... текст свёрнут, показать
     
     
  • 11.386, Аноним (-), 04:36, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Более того - xapian-index если это про него некая весьма опциональная штука О... текст свёрнут, показать
     
  • 7.191, имя (ok), 19:21, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > sqlite это шаг к реестру винды,  no way

    Я вам реестров принёс: http://mirror.centos.org/centos-7/7/os/x86_64/repodata/

     
  • 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 на любой ФС  - "как два пальца"?  

     
     
  • 8.227, Ноним (?), 22:43, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    О том что ACID не нужен вам лучше других расскажет очередной адепт NoSQL... текст свёрнут, показать
     
  • 8.387, Аноним (-), 04:39, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Два, не два с базами данных подстава в том что это реально работает у энтерпр... текст свёрнут, показать
     
  • 7.160, kai3341 (ok), 17:47, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?

    Произвольный доступ к диску уже приблизился по скорости к последовательному? Индексы на ФС уже завезли?

     
     
  • 8.167, Аноним (54), 18:15, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да, уже лет много как придумали SSD Apt использует xapian для индексов ... текст свёрнут, показать
     
     
  • 9.173, kai3341 (ok), 18:36, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как говорил Чапаев, есть один нюанс С диска считывается всё равно не менее сект... текст свёрнут, показать
     
     
  • 10.335, Аноним (335), 19:16, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так пишешь, будто sqlite не на той же файловой системе валяется Хранение данных... текст свёрнут, показать
     
     
  • 11.352, kai3341 (ok), 21:29, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Происходит ли поиск файла при каждом обращении к уже открытому файлу Подсказка ... текст свёрнут, показать
     
  • 8.273, Аноним (273), 04:56, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Поиск имени в каталоге давным давно идёт по индексу... текст свёрнут, показать
     
  • 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.399, Аноним (166), 08:31, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Примечательно, что без отключения fdatasync БД всё одно падает, что объясняетс... текст свёрнут, показать
     
  • 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 самый медленный пакетный менеджер из менеджеров ... текст свёрнут, показать
     
  • 8.377, Аноним (-), 04:14, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Когда у меня сдохла база пакетов по OOM в редхате - приключений было никак не на... текст свёрнут, показать
     
  • 5.164, Анонисмус (?), 17:55, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Можно использовать microdnf, который python-free:
    https://github.com/rpm-software-management/microdnf

    Это позволит Вам сэкономить несколько миллисекунд для Вашей личной жизни.

     
     
  • 6.182, Илья (??), 18:59, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно использовать microdnf, который python-free:
    > https://github.com/rpm-software-management/microdnf
    > Это позволит Вам сэкономить несколько миллисекунд для Вашей личной жизни.

    Спасибо, на меня просмотр работы обновления dnf очень положительно влияет. Прихожу домой с работы, sudo dnf upgrade и сижу зачем-то смотрю, как он работает

     
     
  • 7.193, Анонисмус (?), 19:50, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не факт, что в этом виноват именно dnf, а не скорость Вашего интернет-соединения или ширина канала зеркала откуда обновляетесь.
    Ещё не факт, что у Вас не установлено кучу пакетов, о назначении которых Вы даже не догадываетесь.

    Есть возможность выкачивать только дельты пакетов:

    https://stackoverflow.com/questions/30553951/how-to-enable-deltarpm-for-dnf-pa

     
     
  • 8.198, Аноним (198), 20:18, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я так понимаю, тот единственный на данный момент человек, который плюсанул это... текст свёрнут, показать
     
     
  • 9.223, Анонисмус (?), 22:14, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ждём пруфы, которые докажут, что проблема именно в dnf и libsolv, а не во всем в... текст свёрнут, показать
     
     
  • 10.336, Аноним (335), 19:19, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема точно не в libsolv, ибо zypper летает ... текст свёрнут, показать
     
  • 6.376, Аноним (-), 04:11, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно использовать microdnf, который python-free:

    Выковыривать за редхатом непотребное - зачем? Можно просто дебиан взять. Там пакетный менеджер изначально нормально сделан. Они почему-то смогли.

     
  • 4.240, j3t (?), 00:17, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Его усиленно на Си переписывают
     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так запускай, кто тебе мешает-то? Что надо тебе так критично - перепиши. Человек написал на питоне - значит ему было так удобно и с руки. Пользоваться никто не заставляет, это опенсорс. Открыл редактор и гого.
     
     
  • 6.78, Фигноним (?), 13:22, 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 +/
    Уж лучше сразу на плюсах писать чем на динамически типизированном мусоре
     
     
  • 7.138, Аноним (54), 16:24, 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 [^] [^^] [^^^] [ответить]  
  • +/
    > А теперь пусть напишет на асемблере бизнес логику

    Ну, блин, не всем же бизнес-логика нужна. Вот зачем мне твоя бизнес логика например? Спекулянтам ее втюхивай, пока их не раскулачили.

     

     ....большая нить свёрнута, показать (65)

  • 1.2, Ананимас009 (?), 09:34, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему нет lua¿
     
     
  • 2.5, qqqqqq (?), 09:38, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что у lua слишком много версий и трансляторов и весь этот зоопарк вроде как кем-то поддерживаются. А ещё это в первую очередь, имхо, встроенный скриптовый язык, а уже потом что-то самостоятельное.
     
     
  • 3.79, Ананимас009 (?), 13:26, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У луа все три версии, прям как у пихона, если у последнего не больше
     
  • 3.111, Аноним (111), 14:59, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У Lua есть официальный стендэлон.
     
  • 2.33, Аноним (31), 11:17, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +25 +/
    перевёрнутые знаки в начале ставятся.
     
  • 2.353, Аноним (353), 23:37, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    code Free Pascal 3 syscalls 12 taskclock 0,20 instructions 120... большой текст свёрнут, показать
     
     
  • 3.354, Ананимас009 (?), 00:13, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот теперь я доволен :) лучше любого скриптового языка, даже баш обошел, хотя он еще тот тормоз. Обычный sh/csh бы еще.
     
  • 3.363, kek (??), 10:40, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это надо было отдельной веткой комментариев пустить
     
  • 3.369, XXX (??), 16:47, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это откуда циферки?
     
     
  • 4.371, Аноним 353 (?), 21:07, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    запустил скрипт Джеффа, ссылка в статье
     
  • 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.379, Аноним (-), 04:17, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Может, никто не написал? Напишите и доложите.
     

  • 1.4, qqqqqq (?), 09:35, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Технически, это камень в сторону компиляторов.
     
     
  • 2.408, Аноним (-), 03:17, 14/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Технически, это камень в сторону компиляторов.

    Или рантаймов/библиотек.

     

  • 1.6, Аноним (6), 09:41, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    И снова нет Pascal.
     
     
  • 2.13, Anonymoustus (ok), 09:58, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, недоработочка.
     
     
  • 3.85, Аноним (85), 13:36, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    fpc-3.0.0: syscalls - 12... Вот так вот.
     
     
  • 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 +/
    > Считаю, что язык был закопан исключительно по политическим мотивам.

    Скорее — по быдлокодерским. В отрочестве будущих обезьян часто обучают Паскалю, из-за чего они его начинают люто ненавидеть. Это иррациональное, на уровне условного рефлекса. При такой ненависти к Паскалю _эти же_ люди роняют сопли вожделения в адрес жлобоскрипта и пихтона. Лечить только биореактором.

     
     
  • 8.175, Аноним (166), 18:39, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот этих упомянутых умело сыграли политики Как раз в такую среду легко заходит ... текст свёрнут, показать
     
     
  • 9.183, Anonymoustus (ok), 19:00, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На Лурке про это есть lurkmore to Pascal D0 93 D0 BB D1 83 D0 B1 D0 B8 D0 BD D... текст свёрнут, показать
     
     
  • 10.278, Аноним (166), 06:55, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    По-моему, роль России в закапывании Паскаля несколько преувеличена Точнее, у на... текст свёрнут, показать
     
     
  • 11.295, Anonymoustus (ok), 10:58, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На, вот, сам почитай, был уже здесь такой спор https www opennet ru openforum... текст свёрнут, показать
     
     
  • 12.362, Аноним (166), 10:36, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Будто бы именно они что-то решали в комитете по стандартизации, где по понятным ... текст свёрнут, показать
     
  • 12.409, Аноним (-), 03:18, 14/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я вот учился на паскале, но в конце концов перешел на си Системные вещи на паск... текст свёрнут, показать
     
  • 7.355, Ананимас009 (?), 00:24, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если говорить по турбо, он же борланд паскаль, то там имхо было две главных проб... большой текст свёрнут, показать
     
  • 5.380, Аноним (-), 04:19, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Думаю мы раскрыли заговор Паскаль топят за то что он слишком быстрый. И это мешает
    > производителям железа продавать новое железо.

    Он просто glibc наверное не пользуется :). Сишники тоже так могут - просто не все об этом догадываются. Можно вообще стандартные либы не линковать, взял да и сделал сам все syscall()-ы. Ну да, неудобненько и портабельность хромает. Но если с ассемблером зарубаться - на нем еще неудобнее и портабельность еще хуже, так что не аргумент.

     
  • 4.123, Retrosharer (?), 15:39, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот это поворот!
     
  • 2.24, Retrosharer (?), 10:50, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Думаю, на уровне С++.

    А Java впечатляет 👍

     
     
  • 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 годов.

     
     
  • 6.81, Ананимас009 (?), 13:28, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На нетбуке, где geany летает, нетбинс адово тормозит.
     
     
  • 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, а в ноде и Яве есть. Единственное, когда Ява тормознее - запуск. Поэтому одноразовые скрипты (написал, запустил и удалил) лучше писать на ноде или пихоне.  А серьезные долгоиграющие приложения - на Яве. Особенно если важна скорость отклика.
     
     
  • 8.158, Аноним (158), 17:44, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ява, как и Нода, как и Питон всего лишь инструменты Меня всегда поражали умники... текст свёрнут, показать
     
  • 8.159, Аноним (158), 17:46, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это я в общем о тенденции, а не о конкретно вашем комментарии Он, в отличие от ... текст свёрнут, показать
     
  • 6.181, Алексей Михайлович (?), 18:59, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А и я не пишу на этом фекалоиде, у меня хватает ума выбирать инструменты получше... большой текст свёрнут, показать
     
     
  • 7.201, Аноним (88), 20:35, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А прикинь, сколько он бы потратил на программистов, пиши и сопровождай они бизне... большой текст свёрнут, показать
     
     
  • 8.410, Аноним (-), 03:26, 14/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И тем не менее, LSE однажды познали что иной раз проще и дешевле не только писат... текст свёрнут, показать
     
  • 5.171, Anonymoustus (ok), 18:34, 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.238, Илья (??), 23:58, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вам - это вам и вашему супругу?
     
  • 4.346, alienjust (ok), 19:54, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    C#: syscalls:   117

    .net core 3.1

     
     
  • 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 сисколов, между асмом и си.
     

     ....большая нить свёрнута, показать (46)

  • 1.7, Нанобот (ok), 09:43, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Наглядно демонстрирует раздутость современного ПО
     
     
  • 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.

     
     
  • 5.275, Аноним (166), 06:15, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Удачи тебе понять, надо ли ему это. ;)
     
     
  • 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 +/
    Чтобы не поддерживать монополию, у юзеров должна быть возможность приобрести аль... текст свёрнут, показать
     
  • 4.344, Аноним (-), 19:38, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Чтот не вижу его https://www.techempower.com/benchmarks/#section=data-r18
     
  • 3.382, Аноним (-), 04:25, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Наглядно демонстрирует, любителя забивать гвозди микроскопом,
    > и что кроме хелоуворлда на асме ничего не пишется.

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

    Сишники правда немного жульничают сейчас с intrinsics, но по большому счету, это по сути тот же ассемблер и получается, просто чуть более кроссплатформенно и портабельно. Но из-за привязки к особенностям процессоров - именно чуть. Ну то-есть простой фрагмент может быть даже и соберется не только на SSE2 но и на neon каком. Но половина кода завалится за отсутствием потребных эквивалентов команд у железа.

     

  • 1.9, Wfhm (?), 09:44, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Руби как всегда.
     
  • 1.10, Anonymoustus (ok), 09:47, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Восхитительно! :-)

    Удивляет Игогошечка. Всё остальное не удивляет.

     
     
  • 2.16, йййй (ok), 10:10, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, как-же новый системный язык Раст то ей слил по числу инструкций.
     
     
  • 3.341, Аноним (-), 19:34, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Раст использует c runtime library под капотом, но в пару строк конфигруации можно статически прикомпилить себе стандатрную библиотеку rust, естественно со всеми оптимизациями. https://github.com/japaric/xargo
    Тем не менее меньше чем у Си не будет в инструкциях из-за cruntime. Есть также реимплементация, но только для redox и линукс. https://github.com/redox-os/relibc
     
  • 2.76, конь в пальто (?), 13:18, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    игогошечка как и баш - годится только для мелких скриптецов.
     
     
  • 3.383, Аноним (-), 04:26, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    игогошечка годится для мелких серверцов, ну вообще совсем не как баш.
     

  • 1.11, Аноним (11), 09:52, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > результаты бенчмарка
    > 23-минутное видео

    Мда.

     
  • 1.14, анонимчик (?), 10:08, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    rust уделал плюсы по полной, учитывая нафаршированность языка - вывод очевиден
     
     
  • 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)

     
     
  • 8.174, Аноним (95), 18:38, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    rustc --version rustc 1 39 0 Это что же получается, раст продуцирует рандомны... текст свёрнут, показать
     
     
  • 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 конечно еще и не так умеет ... текст свёрнут, показать
     
     
  • 9.404, burjui (ok), 14:53, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Аноним демагогировал-демагогировал, да не выдемагогировал ... текст свёрнут, показать
     
     
  • 10.412, Аноним (-), 03:39, 14/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Признаю в порожней демагогии ты меня сделал как с куста Но маркетинг у тебя вс... текст свёрнут, показать
     
  • 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...
     
  • 3.28, анонимчик (?), 11:02, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    только по количеству инструкций, но не по производительности
     
     
  • 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.61, Анонисмус (?), 12:23, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Дело в том, что даже сами авторы языка С++ не советуют на нём писать.
     
  • 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.265, Аноним (265), 02:57, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.top500.org/
    Где?
     
  • 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

     
  • 5.307, InuYasha (?), 11:48, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Убийство - преступление.
     
     
  • 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 язык очень полезный. Программистом, которые пишут код на С++, работающий медленнее написанного на расте дорога одна, переходить на раст. Им ничто уже не поможет
     

     ....большая нить свёрнута, показать (32)

  • 1.15, Аноним (15), 10:10, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +22 +/
    Это не тестирование, это троллинг недалекого человека.
     
     
  • 2.260, Аноним (260), 02:10, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Жалуешься что тебя затроллили ?
     

  • 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 +/
    Если бы вы не писали с таким пафосом, словно вы суперпрофессионал, при этом неся... большой текст свёрнут, показать
     
     
  • 8.277, Аноним (166), 06:52, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ложное обобщение ... текст свёрнут, показать
     
     
  • 9.298, Урри (?), 11:10, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Попытка съехать на буквоедстве ... текст свёрнут, показать
     
     
  • 10.349, Аноним (166), 20:04, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да лан, расслабься Если ты не способен восстановить алгоритмы сложнее хелловорл... текст свёрнут, показать
     
  • 8.286, Anonymoustus (ok), 09:54, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Речь о справочнике по Win32 API Да, был и есть На сайте Майкрософта можно чита... текст свёрнут, показать
     
     
  • 9.297, Урри (?), 11:08, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    При чем здесь винапи Я писал про справочник интов - биоса, доса и дополнительно... текст свёрнут, показать
     
     
  • 10.326, Совершенно другой аноним (?), 14:02, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Был, да вроде и есть, правда в бумажном виде не видел, Ralf s Brown Interrupt Li... текст свёрнут, показать
     
  • 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.229, Michael Shigorin (ok), 23:09, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда boa был :-)
     
  • 4.96, Аноним (102), 14:12, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У автора сабжа есть тоже вебсервер https://2ton.com.au/rwasa/
    Ещё в природе существует https://github.com/nemasu/asmttpd  
     
     
  • 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) пользователями тесты производительности показывают
    >[B] существенное отставание по скорости обработки запросов от современных http-серверов, написанных на языке Си. [/B]

    (а еще сам автор собирался делать:
    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 обеспечивают довольно прозрачную работу всего этого.

     
  • 5.248, erthink (ok), 01:31, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > У автора сабжа есть тоже вебсервер https://2ton.com.au/rwasa/
    > Ещё в природе существует https://github.com/nemasu/asmttpd

    Не хочу обижать автора, но rwasa - это примерно смесь бутафории и паранойи в духе "назло бабушка на ассемблере пишу".

    В частности, все более-менее сложные функции вовсе не "handmage assembly", а допиленный результат компиляции соответствующих реализации на C (например: https://github.com/floodyberry/curve25519-donna => https://2ton.com.au/library_as_html/curve25519.inc.html).

     
  • 3.100, Аноним (102), 14:23, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Сейчас и форумы на асме делают https://asm32.info/fossil/repo/asmbb/index
     
  • 2.222, Сергей (??), 22:03, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже Преподаватель был не Писателем, а Учителем
     

     ....большая нить свёрнута, показать (39)

  • 1.18, Аноним (18), 10:26, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    Как же бесят все эти бенчмарки на хелловорлдах. Только вводят в заблуждение новичков, которые стоят сейчас перед выбором и черпают информацию у таких вот фанатиков.
     
     
  • 2.20, Аноним (95), 10:35, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Каких фанатиков? Это же просто шутка.
     
     
  • 3.218, цука (?), 21:28, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В каком месте смеяться?
     
  • 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 и применяется.

     
     
  • 8.415, Аноним (414), 03:53, 14/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому она где-то там ... текст свёрнут, показать
     
  • 6.118, Аноним (95), 15:26, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там не мелочь, производительность может и на порядки отличаться в результате работы pgo. Это без модификации исходников, да. Ручками тоже можно сделать необычные оптимизации, но они будут не универсальны, профиты жита с аот именно в оптимизации под данные.
     
  • 4.189, Алексей Михайлович (?), 19:12, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Конец списка переместится в начало достаточно быстро, просто потому что ты не
    > сможешь оптимизировать ассемблер на лету в зависимости от данных, как это
    > делает жит.

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

     
  • 3.230, Michael Shigorin (ok), 23:11, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    go-дюка? 8)
     
  • 2.30, анонимчик (?), 11:05, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    какие? большая программа состоит из тривиальных блоков
     
  • 2.63, ыы (?), 12:25, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ждем ваш тест
     

  • 1.27, Иваня (?), 11:01, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Отлично, спасибо за информацию. Это мотивирует изучать Assembler
     
     
  • 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.56, Аноним (31), 12:15, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В том то и дело, что стримы в  C++ не тормозные. Нужно просто отключить синхронизацию с выводом в stdio. https://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio
     
     
  • 5.65, йййй (ok), 12:26, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спасибо, буду знать
     
  • 3.232, Michael Shigorin (ok), 23:13, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вспомнился c-- :-)
     
     
  • 4.249, Урри (?), 01:35, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Пошто заминусили человека, макаки?

    Представьте себе, был такой язык. И одно время даже достаточно распространенный. Именно С-- (минус минус).

     
     
  • 5.266, aaaaaaaaaaaaaaa (?), 03:12, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    он не просто был https://www.cs.tufts.edu/~nr/c--/
    он и сейчас есть, например в КолбриОСь используется и развивается http://kolibri-n.org/inf/hll/hll#cmm
     
     
  • 6.270, Урри (?), 04:14, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Хех, я был уверен что давным-давно умер.

    Спасибо.

     
  • 2.58, Аноним (54), 12:19, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Исходники не на гитхабе, не на гитлюбе, не в gitwebе, а в каком-то архиве.

    Это чтобы заодно подсунуть бинарники в расчёте, что их кто-нибудь да запустит…

     

  • 1.37, ф (?), 11:26, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    ну вот!
    a говорили, что лапша на баше тормозит загрузку - а оказывается в первой четверке по скорости ;)
     
     
  • 2.44, Антон (??), 11:47, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    там видать парсинг скрипт "echo hello" и вызов echo
     
     
  • 3.215, Vkni (ok), 21:23, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В bash echo - это builtin Выжимка strace hello_world sh stat hello_worl... большой текст свёрнут, показать
     
  • 2.45, Аноним (45), 11:47, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Знатно Поттеринга протроллил.
     
  • 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 хотя системд и интерпретирует свои юнит файлы, зато он делает это с уважением и с благословения Лёни Поттеринга.
     
     
  • 5.250, Урри (?), 01:36, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем, зачем... Десятое правило Гринспена жы!
     

  • 1.43, Аноним (45), 11:44, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing, предлагающей в том числе реализации протоколов TLS 1.2 и SSH2

    Интересно, как образец, чтобы сделать подобное для микроконтроллеров RV32, RV64, где ограничено количество ПЗУ и ОЗУ.

     
  • 1.50, Аноним (54), 11:57, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    вывсеврети джава нитармазит!!11
     
  • 1.51, Илья (??), 12:03, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Почему он свой скрипт писал на баше, а не на ассемблере?
     
     
  • 2.59, Анонисмус (?), 12:20, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Если бы он писал на ассемблере, то ты бы не досмотрел видео до конца.
     
     
  • 3.323, Аноним (95), 13:47, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Можно было хотя бы на си, обожаю смотреть на сишку с https://ioccc.org/
     

  • 1.53, mrprint (?), 12:10, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё неймётся ассемблерщикам
    https://github.com/mrprint/HelloTiny
     
     
  • 2.89, Аноним (102), 13:50, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Кто интересуется ассемблером могу еще порекомендовать https://github.com/Number571/asmlib набор простых библиотек типа печать строк, чисел.

    Да и видосы от автора тоже могу порекомендовать хорошие видосы https://www.youtube.com/watch?v=TuNiVG2hYuU&list=PLd-kTafWJCJN6OpkPAKzmqVnyCFU

     
     
  • 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 битных
    > системах. Да и тем более исходники открыты.

    Да, исходники открыты. Вот возьми их и почитай, посмотри, с какими ограничениями он работает.

     
     
  • 6.149, Аноним (151), 17:12, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    С незначительными.
     
     
  • 7.163, Аноним (166), 17:48, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > С незначительными.

    Ну так то да. Всего-то наполовину меньше. Действительных разрядов в адресе. ;)

     
     
  • 8.313, Аноним (313), 13:06, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тот же nasm текст вида mov rax, 1 syscall оптимизирует до mov eax, 1 sys... текст свёрнут, показать
     
     
  • 9.339, Аноним (166), 19:28, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В eax номер вызова Параметры передаются в других регистрах ... текст свёрнут, показать
     
  • 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... большой текст свёрнут, показать
     
     
  • 8.364, Аноним (364), 10:44, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    То-то я смотрю они из коробки этого франкенштейна боятся распространять Да и те... текст свёрнут, показать
     
     
  • 9.365, Аноним (166), 10:50, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У меня нет телевизора я ем грибы и смотрю ковёр с Он автор у fasm-а один ... текст свёрнут, показать
     

  • 1.57, Аноним (57), 12:17, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Джефф Мэррисон (Jeff Marrison), автор реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing

    для каллибриОС штоли

     
     
  • 2.200, Аноним (198), 20:34, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что, нельзя прилинковать её к сишной программе и дёргать из сишного кода?
     

  • 1.66, Аноним (66), 12:28, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Perl молодец, собственно, как и ожидалось.
     
     
  • 2.202, nuclight (??), 20:38, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Удивительно, как Питон почти на порядок просел относительно него.
     
     
  • 3.251, Урри (?), 01:37, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Совсем не удивительно.
     
  • 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.
     
     
  • 3.334, Аноним (334), 18:25, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это против правил.
     

  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Всё ещё не понятно, при чём тут питон и плюсы, если сравнение было с сишечкой.
     
  • 2.203, Аноним (198), 20:39, 08/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
     
     
  • 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

    Ничего, придёт ему на смену задорная молодёжь и перепишет всё это окаменевшее на жлобоскрипте (пихтона они уже знать не будут).

     
  • 3.315, Аноним (313), 13:11, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Блин, а ларчик то так просто открывался. Вы сделали мой день.  
     

  • 1.84, Грусть (?), 13:34, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    https://github.com/ip1981/gcd
     
  • 1.87, ыы (?), 13:38, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Таки да, ассемблер - отличный инструмент для написания хэлловорлдов
     
  • 1.90, Аноним (90), 13:51, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Как этот чел может спать спокойно, осознавая, что все инструменты, которыми он пользовался при записи видео, написаны не на ассемблере?
     
     
  • 2.94, Аноним (102), 14:05, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Ты еще скажи что они не из машинного кода состоят)
     
     
  • 3.98, Аноним (90), 14:17, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Что?
     
  • 2.126, VEG (ok), 15:48, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не увидел чтобы автор видео агитировал за написание всего кода на асме. Просто на практике показал что все удобства даются не бесплатно. Обещал ещё показать в следующих частях какие-то преимущества. Скорее всего покажет что компилеры способны генерировать оптимальный код только в простейших случаях, а толково применять SSE/AVX вообще толком не могут, и ручная оптимизация тут рулит на всю катушку. Полагаю, что основной посыл будет использовать асм там где это имеет смысл. Его и используют. Для оптимизации кодеков, например. Надо же чтобы кто-то это рассказал подрастающему поколению, вот автор видео и старается.
     
     
  • 3.129, Аноним (90), 16:00, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Компилеры способны генерировать оптимальный код только в простейших случаях

    Лол что? Это человек способен генерировать оптимальный код на ассемблере только в простейших случаях. Для большого куска кода у человека от писанины на ассемблере крыша поедет, а о том, чтобы превзойти по оптимальности код компилятора даже речи идти не будет. Современные компиляторы далеко ушли по сравнению с 80-ми, а вы похоже там и остались. Сейчас оптимизация кода производится на многих уровнях, особенно хорошо разработаны оптимизации AST-дерева, которое человек в принципе в голове удержать целиком не способен.

     
     
  • 4.199, Анонисмус (?), 20:31, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот куда ушли современные компиляторы и технологии:
    How new-lines affect the Linux kernel performance.

    https://nadav.amit.zone/linux/2018/10/10/newline.html


    Думаю, заголовок статьи говорит сам за себя.


     
     
  • 5.210, Аноним (95), 20:58, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Недавно видел историю где слово register (то самое против которого все топят) применённое к переменной-счётчику, ускоряло код в 9999 раз. Компиляторы такие умные сегодня.
     
  • 5.221, Аноним84701 (ok), 21:44, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Думаю, читать все же желательно не только заголовки Разъясняю для опенн... большой текст свёрнут, показать
     
     
  • 6.226, Анонисмус (?), 22:42, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Надеюсь, что ты не много времени потратил на "онализ" статьи:

    https://www.opennet.ru/opennews/art.shtml?num=49412

     
     
  • 7.239, Аноним84701 (ok), 00:08, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну и Ты считаешь, что то перевод оригинала ссылка из новости предыдущая сс... большой текст свёрнут, показать
     
  • 4.217, VEG (ok), 21:27, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мечтать не вредно, конечно, но компилеры далеки от того, чтобы самостоятельно за... большой текст свёрнут, показать
     
     
  • 5.252, Урри (?), 01:48, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Я делал часть работы по оптимизации libjpeg-turbo Могу объяснить в чем вы правы... большой текст свёрнут, показать
     
     
  • 6.253, Урри (?), 01:49, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ох, промахнулся немного комментом.
     
  • 6.262, Аноним (260), 02:25, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    "Что же касается оптимизации обычного, не векторизуемого кода - то тут компиляторы дают гарантированную фору человеку. Просто потому, что уже никто не может удержать в памяти весь тот зоопарк сложностей, с которыми работает современный микропроцессор. Все эти микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги и т.д. и т.п."

    Вот как раз всего этого компилятор "удержать в памяти" и не может, потому что этой информации у него просто нет и взять ее неоткуда.

    Именно этот прискорбный факт и стал основной причиной безвременной кончины интеловского итаниума.

     
     
  • 7.271, Урри (?), 04:19, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну здрасьте, приехали. Как это нет - у компилятора есть множество того, что мы не сможем сделать; например, возможность построить граф зависимостей по коду и данным; по использованию регистров и самому "попереименовывая" их разбросать в наилучшем порядке.

    У gcc специально для вас в асм вставках предлагается использовать не регистры, а условные обозначения с указанием что именно ваша функция (которую гцц не понимает и понимать не должен) использует, что хочет на вход и на выход; после чего гцц с учетом этой инфорации подберет конфигурацию получше, размещая промежуточные данные в одних или других регистрах.

    Да много чего есть, чего вам, как человеку, уже недоступно ввиду слишком низкой скорости обработки данных и ограниченности по объему их же.

     
     
  • 8.303, Аноним (260), 11:32, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И поэтому сплошь и рядом компиляторы устраивают в коде какой-то бл cкий цирк с ... текст свёрнут, показать
     
  • 7.272, Урри (?), 04:22, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да, кстати. Итаниум умер не поэтому.
    Умер он потому, что его время новых инструкций без сохранения обратной совместимости еще не пришло.

    Через десять лет время пришло, но повезло в этот раз арму. Итаниум - это же современный арм, разве что с увеличенной адресной шиной.

     
     
  • 8.301, Аноним (260), 11:20, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Именно поэтому, как и многие другие VLIW процессоры Не получился всемогущий ком... текст свёрнут, показать
     
  • 8.302, Anonymoustus (ok), 11:27, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    История не знает сослагательного наклонения, но мне думается, что если бы Итаниу... текст свёрнут, показать
     
     
  • 9.306, Аноним (260), 11:36, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Бабушка-с-членом-и-усами jpg ... текст свёрнут, показать
     
  • 8.304, Аноним (260), 11:34, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Блин, слона-то я и не приметил Больше вопросов не имею ... текст свёрнут, показать
     
     
  • 9.401, Anonymoustus (ok), 08:51, 11/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 +/
    Таблицы, коих на самом деле уже давно нет. Так как конвеер длинный и микрооперации сильно зависят друг от друга и окружающей среды (например, предсказания переходов или кеширования памяти).
     

     ....большая нить свёрнута, показать (31)

  • 1.109, Аноним (105), 14:55, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Почему нет примера на Форте? Это дискриминация.
     
  • 1.121, Аноним (121), 15:34, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а джава молодец, уцепился таки зубами за последний вагон уходящего поезда
     
  • 1.127, Аноним (127), 15:50, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ассемблер рулез
     
  • 1.128, Сергей (??), 15:52, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Интересно, что perl чуть-чуть проиграл bash, с другой стороны все эти тесты говорят об одном - о нагромождение ненужных прослоек в фреймворках.
    Вспоминаю молодость, студент, была дадена ес-1840, в качестве задания писал программу на паскале, потом профилирование и переписывание кусков кода с него на ассемблер, благо там это легко было сделать, когда первый раз сделал слегка удивился...
     
     
  • 2.205, Аноним (198), 20:41, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ес-1840

    *пустил скупую мужскую слезу*

     
     
  • 3.235, Michael Shigorin (ok), 23:20, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    +1 :-)

    Хотя чего там пускать -- айда опять же в Яндекс-музей, можно со своими ластами.

     
  • 2.332, Аноним (332), 17:26, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Искра-1030(1031)
     

  • 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 описано.

     
     
  • 4.340, Аноним (335), 19:31, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем ему про LTO? Пусть сначала хоть это осилит.
     
     
  • 5.351, Аноним (166), 20:27, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем ему про LTO? Пусть сначала хоть это осилит.

    Автор сообщения #141 описал, какой LTO должна быть. В теории. На практике пока недотягивает... немножко.

     

  • 1.147, Адекват (ok), 16:51, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не хочу показаться занудным, но в случае с ассемблером он сначала просто запустил бинарик, а потом второй раз через strace. Во время второго запуска программа считывалась из памяти а не с винта. В случае с СИ он сразу запускал бинарик через strace, то есть были доп затраты на чтение с винта. Как-то так.
     
     
  • 2.155, Аноним (151), 17:34, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Количество вызовов от этого не меняется в среднем.
     

  • 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.180, svsd_val (ok), 18:58, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что набор вызовов на холодном старте у всех свой.
     
  • 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 не будет _совсем_.

     

  • 1.177, Аноним (177), 18:46, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Delphi Pascal forever!
     
     
  • 2.184, svsd_val (ok), 19:00, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хорошие языки, ничего против не имею, кстати интересно было бы увидеть и их тесты
     
     
  • 3.192, Аноним (192), 19:40, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Выше есть Паскаль обогнал всех кто не ассемблер.
     
  • 3.310, InuYasha (?), 12:20, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что же в делфи хорошего? Разве что, если с Жавой сравнивать.
     
     
  • 4.357, svsd_val (ok), 04:25, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Что же в делфи хорошего? Разве что, если с Жавой сравнивать.

    В прямых руках не хуже сей++ и скорость разработки П.О. выше и косяков меньше. А если руки из опы тут увы извиняйте нечего на язык пинать коли с головой руки из опы, тут никакой язык не поможет.

    В своё время писал на нём игры и 64кб демки, особых проблем не видел. А с применением FPC портировал под  Linux и Darwin ...

     

  • 1.178, svsd_val (ok), 18:49, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не вижу ничего особого в этих тестах, да это только холодный запуск и выход... Да для каждого языка эти процессы уникальные, хотелось бы видеть расчёт производительности непосредственно... правда тогда эти расхождения не будут столь существенными.

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

    Теперь подумаем по поводу разумного соотнесения плюшек и производительности. На ассемблере программист должен сам за всё отвечать за каждый пук... Другие языки же решают свои задачи и предоставляют те или иные плюшки чем облегчают работу программисту и уменьшают количество возможных ошибок.

    имхо, нужно было бы проверить на циклах, математики к (примеру умножение двух матриц) и работы со строками... тогда можно увидеть более интересную картинку, многие языки будут в этом тесте вести себя одинаково.

     
  • 1.186, Аноним (186), 19:10, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Еще один хипстор опубликовал видосик. И как я его в Links посмотрю?
     
     
  • 2.197, СеменСеменыч777 (?), 20:09, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Еще один хипстор опубликовал видосик. И как я его в Links посмотрю?

    на хоткей вешаем связку

    youtube-dl | awk '... извлечь имя_видеофайла ...'
    mpv имя_видеофайла
    echo 1-Удалить видео
    echo 2-Еще раз посмотреть видео
    echo 3-Выход
    accept


     
  • 2.289, Anonymoustus (ok), 10:29, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Еще один хипстор опубликовал видосик. И как я его в Links посмотрю?

    Да, видосики без ссылок для скачивания — это серпом по опенсорсам. Но выковырять можно:

    https://2ton.com.au/videos/tvs_part1/tvs_part1.mp4 (350 МБ)

    https://2ton.com.au/videos/tvs_part1/tvs_part1.webm (155 МБ)

     
     
  • 3.321, Аноним (321), 13:38, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, братиш.
     

  • 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 вызывает непосредственно ядро.

     
     
  • 3.328, Аноним (327), 14:32, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Все правильно, использует API ос.
     
     
  • 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.209, Аноним (209), 20:51, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А чо девять-то? У меня восемь вышло.
     
     
  • 2.212, Аноним (121), 21:09, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ты особенный, гордись этим
     

  • 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.225, vaka (?), 22:26, 08/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    /usr/bin/echo - язык программирования? Внезапно ...
     
     
  • 2.294, Аноним (-), 10:54, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Эта утилитка представлена как образец выводящий хэлоуворлд.
     
     
  • 3.312, анонн (ok), 13:03, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Странная версия, однако code truss -fc bin echo hello hello syscall ... большой текст свёрнут, показать
     

  • 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 +/
    Ты же не пишешь на языке программирования, а печатаешь? Хотя возможно с таким синдромом граммар-наци у тебя и есть парочка скриптов, накарябанных на бересте...
     

  • 1.241, cutlass (?), 00:32, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пых неплох
     
  • 1.258, Урри (?), 02:04, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кто хочет глянуть на реализацию хелловорлда на 441(четырехста сорока одном!) языке программирования - велкам на розеттукод: https://rosettacode.org/wiki/Hello_world/Text
     
     
  • 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/
     
     
  • 2.293, Anonymoustus (ok), 10:46, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    По большому счёту, x86 8212 это только 171 внешняя 187 система команд А ... большой текст свёрнут, показать
     
     
  • 3.300, Урри (?), 11:16, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То, что вы в своем детском саду не знаете, еще не значит что никто не знает.
    Почитайте, хотя бы, мануалы интела - можете погуглить по страшным словам "микрооперация", "реордеринг", "бренч предикшн", "конвеер", "переименование регистров", "лейтенси".

    Другое дело, что весь этот конвеер настолько сложен, что все сложнее хелловорлда в голове уже не уместится.

     
     
  • 4.305, Anonymoustus (ok), 11:35, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > То, что вы в своем детском саду не знаете, еще не значит
    > что никто не знает.
    > Почитайте, хотя бы, мануалы интела - можете погуглить по страшным словам "микрооперация",
    > "реордеринг", "бренч предикшн", "конвеер", "переименование регистров", "лейтенси".

    А ты, я гляжу, прямо знаток по всем вопросам. И слова какие умные знаешь, молодец. Ну так расскажи всем: есть внутри интеловских процессоров x86 или нету?

     
     
  • 5.320, Аноним (313), 13:28, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Есть интеловский манул https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-
     
     
  • 6.322, Anonymoustus (ok), 13:43, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть интеловский манул https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-

    У меня на диске вся пачка этих мануалов, а ещё несколько ревизий документации AMD. На какой странице какого тома написано про место, которое x86 занимает в современном процессоре?

    Ой, а что это у нас там чорненькое белеется в чулане? Это же «80386 Hardware Reference Manual» (1986)! Пока ты ищешь нужную страницу в современных мануалах, я в этой книжке посмотрю.

     
  • 2.324, Аноним (324), 13:49, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Может в этом то все и дело что создать что-то действительно разухабистое на языке с динамической типизацией достаточно трудно. А работало быстро потому что ничего сложно и не делали. Да и вообще этот Xerox Alto это попытка внедрить разработки Дугласа Энгельбарта в жизнь. https://www.youtube.com/watch?v=yJDv-zdhzMY и как все знают неудачная.
     
     
  • 3.368, Аноним (267), 16:17, 10/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Здесь Кэй демонстрирует ту систему из 70-х в эмуляторе, суди сами: https://youtu.be/AnrlSqtpOkw?t=2m37s
     
  • 2.345, Аноним (335), 19:39, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Мультимедийность-то ты там где нашёл?
     

  • 1.279, Аноним (279), 06:59, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Спасибо господину Джеффу Мэррисону, теперь я знаю на чём надо писать программу, которая выводит строку "hello".
     
  • 1.284, Аноним (284), 09:16, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что сразу бросилось в глаза, у него второй питон а не третий, также не указаны версии интерпретаторов и компиляторов.
     
     
  • 2.309, анонн (ok), 12:16, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    code truss -fc python3 6 -c print hello hello syscall ... большой текст свёрнут, показать
     
     
  • 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... большой текст свёрнут, показать
     

  • 1.316, Аноним (316), 13:13, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ууу! Раст затащил ууу!!!!
     
     
  • 2.319, Аноним (313), 13:24, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На дно.
     

  • 1.337, alienjust (ok), 19:23, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    del
     
     
  • 2.343, alienjust (ok), 19:37, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > del

    C#: syscalls:   117 taskclock

     

  • 1.372, Kaiwas (?), 22:56, 10/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    только тут 'hello' могло так взбудоражить умы и быть поводом для сра4eй )
     
  • 1.405, антон (??), 01:51, 12/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В Haskell автор не смог? That's a shame.
     
     
  • 2.418, Аноним (-), 04:03, 14/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В Haskell автор не смог? That's a shame.

    Ну так смоги ты и выложи результаты, например?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру