2 января в 20:52

Писать веб-сайты на ассемблере полезно и приятно из песочницы

Конечно, многие скажут, что это ни-ни и писать для веба нужно только на PHP, ну или на один из модерных языках Питон, Руби, Node.js и т.д.


Но дело в том, что написание сайтов на ассемблере очень полезно, а с подходящими инструментами — легко и приятно.


Вообще-то, это утверждение было лишь гипотезой. Чтобы доказать или отвергнуть ее, этой весной я занялся писать форум на ассемблере.


Раньше у меня уже было веб-приложение на ассемблере — CMS для малого сайта. Только оно работает в режиме "один пишет, многие читают". При том, использует CGI интерфейс и поэтому "многие" читать одновременно тоже не получается.


Техзадание


И так я решил написать веб-приложение, чтобы:


  1. Соблюдался принцип «много читают — много пишут».
  2. Работало очень быстро и не загружало сервер.
  3. Использовало очень мало памяти, опять чтобы не загружать сервер.
  4. Работало на дешевом виртуальном хостинге.

Всем этим условиям отвечает именно веб-форум. Поэтому выбор остановился на нем. Задание выглядит так:


Написать веб-форум, который:


  1. Использует интерфейс FastCGI, чтобы обслуживать заявки быстрее чем CGI и чтобы не было ограничения на число одновременно исполняющихся процессов на сервере (у моего хостинг плана есть такое ограничение в 60 30 процессов).
  2. Использует транзакционную базу данных, чтобы хранить информацию в одном месте и чтобы можно было нескольких посетителей писать одновременно.
  3. Функциональность должна быть достаточной чтобы использовать продукт в реальной жизни для общения пользователей.
  4. Вид форума было можно полностью менять из конфигурации. Скины — наше все. Да и не каждый может редактировать код на ассемблере.

Кроме FastCGI можно было использовать и SCGI, которой даже выглядит несколько проще для имплементации. Только оказалось, что моя хостинговая компания поддерживает только FastCGI.


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


Для базы данных была выбрана SQLite. Во первых, я знаю ее очень хорошо и часто использую ее в связке с ассемблером. Во вторых, используя виртуальный хостинг, хотелось чтобы все приложение находилось в директориях сайта, включая база данных. В третьих, у SQLite есть возможность "Full text search — FTS", которая работает быстро и придется очень кстати для поиска в форуме.


Но здесь появилась проблема. Форум я решил писать на 32 битном ассемблере для x86, чтобы можно было работать и на 32 и на 64 битных серверов. Но дело в том, что 64 битные серверы, как правило, не предусматривают 32 битных библиотек. Для ассемблера это не важно, но SQLite мне тоже нужна 32 битная, а ей нужна стандартная библиотека C. А вот glibc (GNU C library) нельзя скомпоновать статически.


Но решение нашлось — использовать альтернативную библиотеку C — MUSL у которой есть динамический линкер, которого можно поместить в директорию приложения. Дополнительной плюс является и то, что библиотека очень небольшая.


Реализация интерфейса FastCGI писалась так, чтобы ее можно было использовать и в других проектах.


Для разметки постов форума было решено использовать markdown подобную разметку, которая у меня уже была написана для CMS-а.


И так, что в итоге получилось?


Писал я в свободное от работы время. Иногда на работе, иногда дома. Код, конечно открытый. Лицензия распространения: EUPL. Первая версия, сохранена 6-го Марта 2016-го года. Официальная версия 1.0, сохранена 7-го Апреля 2016-го года.


Все это заняло ровно 53 коммита.


Так как ассемблер я знаю, то больше всего затруднений во время работы вызвало незнание веб протоколов. Пришлось читать RFC документы насчет SMTP и FastCGI.


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


Так же, в начале мне совершенно ничего не было известно насчет XSS атаки и других аспектах веб безопасности. В конце, все более-менее изъяснилось. Особенно во время тестов, которые проводили некоторые товарищи из болгарского форума. В результате, появилась защита от ботов, а также тема в которой были 15000 постов.


Приложение получилось очень маленькое. Все файлы в дистрибуции 1.8МБ, от которых 992КБ SQLite и 622КБ MUSL библиотека. Само приложение на ассемблере состоит из одного файла "engine", размером в 68.5КБ (v1.2). Все остальное — темплейты и картинки.


Инсталляция очень простая — архив распаковывается в директорию сайта и настраивается '.httaccess' файл. Ну или 'lighttpd.conf'. Открывается сайт в браузере и создается пользователь-администратор.


Во время исполнения, приложение использует приблизительно 2МБ RAM на сервере, на запущенном процессе. В зависимость от нагрузки, apache сервер может запускать несколько экземпляров процесса.


К сожалению никакие сравнения с другими форумами не могу привести, потому что данных насчет потребления памяти популярных форумов не публикуются (ну или я не нашел) но типовое потребление памяти например cpanel, около 20МБ на PHP процесс — примерно в 10 раз больше.


Демо инсталляция форума доступна для посещения и тестов.


Хостинг план, на котором находится демо, (самый дешевый который я смог взять), виртуальный (shared). Ограничения таковы (согласно спецификации):


  1. Одноядерное CPU
  2. 1GB RAM
  3. 30 минут процессорного времени в сутки.
  4. Максимальное количество работающих процессов — 60.

Slashdot эффект тест.


В Августе совершенно случайно удалось протестировать систему на нагрузке в реальном режиме. Некто (так и не понял кто) опубликовал в Твиттер ссылку на хранилище кода. Сразу несколько десятков перепостили ссылку, а потом опубликовали ее и в reddit и наверное в других социальных сетях.


К большому моему сожалению, ссылка была на хранилище кода. А оно работает на CGI (fossil) и совершенно не держит нагрузки.


В течение суток форум посетили несколько тысяч посетителей — около 8000 на хранилище кода, которое счастливо падало и вставало (из-за превышения лимита процессов).


Но некоторое количество посетителей (около 3000) все-таки попали на форум и сделали более 30000 заявок.


Форум совершенно не почувствовал нагрузку и все время исправно работал без замедления или потери заявок. В эти сутки использовано около 7 минут процессорного времени.


Вердикт гипотезы


Я считаю, что всем этим гипотеза сформулированная в начале моего рассказа, была доказана.


Веб программирование на ассемблере возможно, не очень сложно, а результаты получаются весьма хорошие. В результате, такая работа весьма повышает общую культуру разработчика и позволяет ему получит глубокое понимание протоколов Интернет и как все работает на самом деле.


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


Заключение


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


И в конце некоторые ссылки:


» Хранилище кода проекта
» Демо инсталляция
» Как качать и инсталлировать
» Как зарегистрироваться без почты

John Found @johnfound
карма
78,0
рейтинг 0,0
Инженер автоматизации
Самое читаемое Разработка

Комментарии (428)

  • 0
    Блин, неужели так трудно проверить статью перед публикацией или попросить об этом кого-нибудь, чтобы потом не кровоточило из глаз при чтении? Это уже за гранью. Безотносительно к содержанию.
    • +13
      Насколько я понял, русский для автора не родной язык.
      • –7
        При всем понимании.
        • +13
          Почему мы злые?

          вычитать и отправить автору корректировки отняло у меня не больше 20 минут.
          • –8
            Это действительно очень здорово и похвально, что у вас нашлось 20 минут на корректировки и отправку оных автору. Но, мне представляется, бы еще чуточку лучше, если бы читатели прочитали данную статью уже после их внесения перед публикацией для чего бы и пригодилась инициатива со стороны автора. Суть того, что я написал — пожелание уделять несколько больше внимания к подготовке материала, потому что читать такое тяжело, не говоря уже об остальном. Никакой злости со своей стороны я лично в этом не усматриваю и не вкладываю, и хочется верить, что только вы увидели здесь то, что захотели (кстати, по вашей ссылке совсем другая история, касающаяся конкретно содержания, а не корректности его изложения, обратите внимание — это разные вещи).
            Когда статья подготовлена нормально, таких комментариев не появляется. Не зря классики говорили «Кто ясно мыслит, тот ясно излагает.»
            • +7
              Не переживайте, большинство прочитали уже после исправления.
              Вопрос, почему мы такие злые все-таки остается актуальным.
              • +10
                Я прочитал ещё начальный вариант и ничего, что было бы «за гранью» и от чего бы «кровоточило из глаз при чтении» не заметил. Ну да, в паре мест падежи не согласованы, может где речевые обороты не такие гладкие, но для изложения на иностранном языке вполне прилично. Кто писал, тот понимает. Англоговорящим и не такое приходится читать. Реакция не заслуженная и, главное, не по существу.
                • 0
                  Ну вот прямо сейчас прямо в первом предложении статьи — ошибки согласования падежей («писать на один из языках»).
                  Было ещё хуже?
                  • 0
                    Нет, примерно такие же ляпы.
                • +1
                  Непонятно, почему «мы такие злые», ведь даже то же самое, можно было изложить гораздо аккуратнее.
                  «При все моем уважении к тому, что для автора русский — это не родной язык, он поторопился, выкладывая данную статью без вычитки. К сожалению, я не смог прочитать даже первые пару абзацев. Думаю, вычитка и исправление помогло бы раскрыть суть статьи полнее для многих читателей.»
                  Смысл тот же, а отношение лучше.
            • +6
              >Это действительно очень здорово и похвально, что у вас нашлось 20 минут на корректировки и отправку оных автору.

              Речь шла не обо мне. Это был тонкий намек на то что возможно и у Вас ушло бы сопоставимо времени на это. Но вы предпочли возмущаться тем что человек для которого русский не является родным осмелился публиковаться, не выучив язык на уровне натива. Россияне ведь все как один владеют языками лучше носителей, да что там — носители свой язык учат по постам россиян на форумах. Оттого и требования у нас высокие, не злые мы, совсем нет. А еще мы воспитанные.
              • –1
                Да, я прекрасно понял ваш «намек обо мне» и, пожалуй, оставлю без внимания ваши Д'Артаньяновские слова в мой адрес и не буду намекать вам в ответ. Просто повторюсь и подытожу:
                Я бы с удовольствием помог автору, если бы он, зная, что у него возможны проблемы с изложением на русском обратился ко мне с просьбой глянуть черновик перед публикацией. И я, в принципе, не против делать это в будущем.
                Мне хотелось бы видеть здесь более качественные публикации (хотя бы в плане изложения) — к сожалению, в последнее время таковых все меньше. Чтобы не возникало отторжения при чтении — даже если материал интересный, то качество изложения может весьма сильно подпортить впечатление, а в некоторых случаях и исказить его понимание, не говоря уже о желании читать.
                Раз уж писать статью, то писать ее для людей — понимая кто ее будет читать и хоть немножко уважать читателя. Не надо говорить мне, что я преувеличиваю — читать то, что было предложено было реально тяжело.
                Такова моя позиция, пространные рассуждения про злость или не злость совершенно не к месту — разве что только высказывание своего мнения карается у нас минусами в карму — это весьма по-доброму, при всем при том, что вроде бы на личности не переходил и просто высказал мнение с которым имеются и солидарные.
                В конце концов, объективно — для ресурса статья была подготовлена ненадлежащим образом и, обращаясь к автору/авторам — уделяйте чуть больше внимания к подготовке материала, чтобы всем было хорошо, на крайний случай попросите кого-нибудь.
                С наступившим.

                • 0
                  >Я бы с удовольствием помог автору, если бы он, зная, что у него возможны проблемы с изложением на русском обратился ко мне с просьбой глянуть черновик перед публикацией. И я, в принципе, не против делать это в будущем.

                  И что же помешало сделать это в прошлом?
                  • +1
                    Даже приведенная вами цитата содержит ответ на этот вопрос — видимо по причине того, что автор опубликовал «как было» и не обратился. По-моему выше я довольно четко сформулировал свою мысль.
                    Однако, вас я не пойму — вы чего-то от меня хотите или ждете? Вроде как, уже все прояснено, я дал развернутый ответ и обозначил свою позицию, а вы продолжаете за что-то цепляться.
                    Так я уже даже похвалил вас без всякого сарказма — быть может вам самому стоит вспомнить про ту ссылку, которую вы приводили?
                    • +5
                      видимо по причине того, что автор опубликовал «как было» и не обратился.

                      Не думал комментировать, но как это "обратится"? К кому? Есть песочница, там можно писать в черновики, а потом публиковать и ждать модератора и приглашения (ну или неприглашения). Я просто не понимаю где в этом процессе можно попросить помощь и от кого?


                      Потом, когда статью одобрили к публикацию, вот gearbox сразу написал на ЛС, что и где не так. А я исправил. Кстати, я даже не знал что есть ЛС.

                      • 0
                        Кстати, я даже не знал что есть ЛС.

                        Кстати, дайте ответ в ЛС. Пожалуйста!
                      • –1
                        Приветствую.
                        Думаю, что вы уже прочитали ветку и понимаете о чем идет речь.
                        Раньше модераторы просматривали статьи и сами корректировали их при необходимости, а в некоторых случаях и не допускали к публикации, если в большем количестве присутствовали ошибки (даже несмотря на интересный материал).
                        Но с тех времен, к сожалению, многое изменилось, в частности, сейчас ответственность за качество статей почти полностью лежит на руках самих авторов.
                        Зная, что у вас возможны проблемы с написанием статьи на русском, к кому обратиться — вопрос не технический (с учетом отсутствия такого механизма на хабре, насколько я знаю), а эстетический, чтобы быть уверенным в своей публикации и что она будет понятна читающим.
                        Думаю, в просьбе пробежаться по статье и поправить ошибки перед публикацией нашлось бы немало тех, кто был бы не против, и это могли бы быть люди не обязательно с этого сайта. Если готовится публикация на широкую публику, а не у себя в блоге, то почему бы не сделать ее доступнее и на нормальном уровне? Ведь все от этого будут только в плюсе.
                        Здесь есть даже правила для публикаций, с которыми было бы крайне желательно ознакомиться перед самой публикацией: https://habrahabr.ru/info/help/posts/
                        Там, как раз, и изложены принципы и пожелания о которых идет речь, и ваша публикация была бы только лучше, если бы вы, зная, что возможны ошибки в таком большом объеме уделили бы им внимание. Ничего личного — то, что я писал направлено не только к вам, но к авторам в целом и к носителям языка тем более. Ребят, просто хочется видеть приемлемый уровень, а не ломать мозг при чтении.
                        • +2
                          Вы выставили себя занудой. Написали очень много бесполезного текста, т.е. текста, который неинтересно читать никому. И, вероятно, утомили не только меня. Лучше бы Вы вообще ничего не писали.
                          • 0
                            Вынужден признать, что вы правы — именно так оно теперь и выглядит.
                            Нашло что-то — слово за слово, ответ на ответ, конечно же стоило ограничиться первым комментарием и не разводить это болото.
                            Но, к сожалению, уже ничего не поделаешь.
                • 0
                  Ну так если у вас нашлось бы время почитать черновик и указать на недочеты, то почему не нашлось почитать готовый уже материал и отправить автору исправления, как это сделал предыдущий оратор?
  • +11
    С одной стороны интересно, эдакая потивоположность современным языкам с тонной фреймворков и детяском уровней абстракций.
    Но с другой стороны, плюсов никаких. С точки зрения производительности, разницы особо думаю не будет — 99% у тебя займёт шаблонизатор и база данных, или 95%.
    • +4
      Без тестов я не стал бы утверждать что разницы не будет. Беда в том, что непонятно, с чем сравнивать — в зависимости от движка форума результат будет разным. Но я бы напротив, ожидал ускорения на порядок.

      Беда в другом. Никому не нужен хороший и оптимизированный софт. Стоит взглянуть на любой продукт крупных компаний — это становится ясно. Важна скорость и стоимость разработки. Ассемблер при всей любви к нему не может похвастаться хорошими показателями в этих категориях. Увы, так устроено наше общество.
      • +1
        Ну при налачии библиотек на ассемблере и написание сайта может достоточно быстро получиться. Но вот что делать с переносимостью между процессорами и их разрядностью? Не проще ли использовать язык C? Так, хотя бы, можно будет быстро перекомпилировать сайт под новую среду.
      • +9
        Никому не нужен хороший и оптимизированный софт.

        Дело в том, что 95% на С и 5% критичного кода на асме покажет результаты не хуже практически на любой задаче. Чистый асм не нужен

        • +3
          У меня есть сильное подозрение, что если критичный код написать на С так же, как писали бы на асме, то выйдет быстрее, чем на асме руками.
          • 0

            Не всегда. Под "5% критичного кода на асме" я подразумеваю "используя при необходимости асм в 5% критичного кода"

            • 0
              Я понимаю, но ещё не видел, чтобы ручной асм был быстрее правильно написанного С, оптимизированного компилятором.
              • +4
                Я видел. Неоднократно.
                Я его сам пишу, собственно.
                Но это безусловно не во всех случаях так.
                P.S. Заранее извиняюсь, но приводить примеры мне лень. В основном это simd-ы и/или упихивание алгоритма в доступные регистры общего назначения.
              • 0

                ffmpeg вроде как классический пример, там прилично асма, и не думаю что просто так

              • 0

                Сам писал, правда, не асм, а SSE/AVX-интринсики, но это ближе к асму, чем к кроссплатформенному С.


                Надо бы про это статеечку наваять, кстати.

                • 0
                  Справедливости ради, это и я писал, но интринсики — это, всё-таки, не ассемблер.
        • 0
          Чистый асм не нужен

          А здесь, кстати, и нет чистого асм-а. Большая часть кода (и по объёму — автор это упоминает, и по ресурсу процессора, я уверен) — отжирает SQLite, который написан на C.
      • +4

        Перед fcgi еще работает apache, плюс движек базы данных, так что разница в производительности на порядок, вряд ли.

        • +3

          Надо просто и сервер написать на асме. И БД.


          И файловую систему поверх сырого block device, на всякий случай.

          • +20
            Ага, что не начни писать на асме, в конце всё равно получается операционная система.
          • 0

            А сервер уже есть: RWASA.
            Весь flatassembler.net работает на нем.


            Там у меня сайт тоже на ассемблере: https://fresh.flatassembler.net
            Правда, там MiniMagAsm работает.

            • +2
              А мы с вами даже знакомы. На том самом форуме обсуждали написание веб сервера. Но потом я «скатился» до node.js
      • +8
        А я буду утверждать, что будет медленнее, чем даже на Java.

        Оптимизация компилятора, использование неоптимальных алгоритмов на асме из-за того, что они проще, игнорирование сложных особенностей при написании своего велосипеда — всё это делает код на асме медленнее.

        Однако в итоге асм будет медленнее на величину, которая меньше погрешности измерения. Основное время программы будет ожиданием ответа от СУБД и подобных сервисов.
        • +5
          Я не видел пока что ничего, что было бы медленнее чем на Java. Не холивара ради, просто наблюдение.
          • 0
            Могу подсказать.
            Node.js, PHP, Ruby, Python и т.д.
            Все это гораздо медленнее джавы (чем дальше к концу списка — тем медленнее).

            Быстрее джавы из применяемых в вебе языков лишь Go. На том же уровне — C#.

            Java vs. Go: https://benchmarksgame.alioth.debian.org/u64q/go.html
            Java vs. C#: https://benchmarksgame.alioth.debian.org/u64q/csharp.html
            • +2
              с трудом верится что бы нода или седьмой пых были медленнее явы. Можно взглянуть на тесты — как и что меряли?
              • 0
                https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=fannkuchredux

                https://benchmarksgame.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=go&id=1

                https://benchmarksgame.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=java&id=1

                https://benchmarksgame.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=csharpcore&id=4
                • +2
                  — один тест
                  — лютая синтетика
                  — transliterated from Mike Pall's Lua program — то есть с LUA перевели на javascript и php (что характерно, для java код писали ручками)
                  — var вместо let или const
                  — for вместо forEach, map и прочего

                  Нормальный тест, чо.
                  • 0

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


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

                  • 0

                    Если что, в V8 let и const сейчас медленней, чем var: https://youtu.be/BstzvS2xd5U?t=1166
                    А forEach медленней for: https://twitter.com/jsunderhood/status/585372287077081089

                    • 0
                      lol
                      https://gist.github.com/srikumarks/1431640
          • 0

            Это обычно сочетание множества факторов, но конкретно Java и JVM там ближе к концу списка. Вот неэффективные фреймворки, да ещё и неправильно и неуместно применённые, ORM с избыточными выборками и N+1 problem, неэффективные модели данных, просто индусский код — это да. Сам пишу на ней, родимой, уже пять лет, и всё это знаю не понаслышке. Ещё на Java пишут как правильно большие и сложные системы, так что если оно тормозит, возможно, на другом языке оно тормозило бы ещё сильнее (хоть и не факт, т.к. см. выше).

          • 0
      • +2

        Движки форумов тоже разные по степени навороченности бывают. Если честно сравнивать, то затраты на SQL будут одинаковые. А дальше идет разница: время ответа HTTP-сервера (не более 0.02 мс везде), шаблонизатор (тут большую часть времени отожрёт Markdown, так что тоже будет примерно одинаково), оверхэд на ORM/QueryBuilder (в данном случае он небольшой, т.к. запросы тривиальные), вспомагательные мидлвары.
        Другими словами, я бы не ожидал ускорения за счёт применения ассемблера более, чем на 20-30% при честном сравнении на данном классе задач.

        • –5
          Интерпретатор проигрывает маш.коду в 100 раз. Это на 9900%

          Можно легко проверить на PyStone
          • 0
            Допустим, машкод выполняется за 10 единиц, интерпретируемый код за 1000 (мы опустим JIT). Накладные расходы при этом — 10000. На этом фоне что 10, что 1000 — все одно.
            • –6
              Допустим, не допустим. Я не пишу «допустим», а интерпретатор питона действительно в 100 раз медленнее С на конкретном тесте, который называется Drystone, а вы говорите «допустим, скорость не всегда нужна».

              Это чистой воды ответ «да зелен виноград».

              Лучше писать код, который будет работать быстро всегда.

              В плане веб серверов есть общие тесты производительности, и там тоже показатели скорости разнятся на порядок
              • +3
                «Допустим» — это фигруа речи, призванная зафиксировать модель, при помощи которой я пытаюсь донести определенную точку зрения.

                Лучше писать код, который будет работать быстро всегда.

                Смысл, если это — не бутылочное горлышко?

                Это чистой воды ответ «да зелен виноград».

                Нет, это чистой воды ответ «экономить на спичках — глупо».
              • +3
                Во-первых, на одном конкретном тесте, который не без недостатков.
                Во-вторых, лучше писать код как можно быстрее и качественнее, так чтобы он укладывался в нужные рамки производительности. Сама по себе абстрактная производительность никому не нужна.

                А «код, который будет работать быстро всегда» это какой-нибудь ассемблер с диким количеством ручных оптимизация под конкретное железо. Да он будет работать быстрее всего в том числе Си, делают так? Крайне редко. Тут все упирается в стоимость разработки и сэкономленное железо, если железо дешевле работу программиста — смысла в быстром коде нет никакого.

                В-третьих, если производительность кода на производительность системы не влияет — нужен ли быстрый код?
                • 0
                  >Сама по себе абстрактная производительность никому не нужна.
                  Это не верно. Она нужна очень много кому, а точнее — всем, кто является конечным пользователем этого кода (в случае бекэнда — владельцу сайта). Другой вопрос, что платить за эту абстрактную производительность никто не готов. Но «экономически не целесообразна» и «не нужна» — всё же разные вещи.
                  • +2
                    Другой вопрос, что платить за эту абстрактную производительность никто не готов. Но «экономически не целесообразна» и «не нужна» — всё же разные вещи.

                    Иногда не нужна. При типичном бекэнде веб приложения количество одновременных соединений с серверу ограничено, сервер имеет ограниченную скорость записи/чтения на диск, то есть работа с базой данных, записью файлов не может быть быстрее скорости работы с жестким диском, а канал связи с инетом тоже не безлимитный. Производительность кода на ресурсы сервера для веб бека может не влият практически никак, так как сервер 100% времени будет заниматься записью/чтением с диска, а процы будут загружены на 10-20%. Либо он упрется в трафик или количество открытых соединений. Смысл супер оптимизировать код, если процы и так не работают в полную силу и лимит достигнут совсем в другом?
                    • +1
                      Не спорю. Но «иногда не нужна» — это всё же далеко от посыла «никому не нужна», на который я отвечал.
                • 0
                  1. На многих тестах, это лишь один пример.

                  2. Нет понятия «абстрактная производительность». Какую платформу выберешь, такую производительность будешь иметь _всегда_

                  Дело не в оптимизации, точнее далеко не только в ней. Просто на языках, скажем так, пост-ЯВУ, невинно-выглядящая операция может тянуть сумасшедшие накладки, о которых средний программист, которому нужно «быстрее и качественнее» может не задумываться или даже игнорировать. Когда все пишется руками, контроль выше, как впрочем и цена.

                  3.Так не бывает в реальности. В одном месте — может и не влияет, а в другом…
                  • +4
                    Просто на языках, скажем так, пост-ЯВУ, невинно-выглядящая операция может тянуть сумасшедшие накладки, о которых средний программист, которому нужно «быстрее и качественнее» может не задумываться или даже игнорировать. Когда все пишется руками, контроль выше, как впрочем и цена.

                    Да, это правда. И что отсюда следует?
                    «на ЯВУ легче написать плохой код, чем на ассемблере» — да, и это правда.
                    «на ассемблере легче написать хороший код, чем на ЯВУ» — нет, и это неправда.
                    «на ассемблере легче написать хороший код, чем плохой» — нет, и это неправда.
                    • 0
                      С третьим я не согласен, как и автор статьи. Внизу есть его пояснения.

                      Речь идет об структуре и алгоритмах, конечно, а не о количестве ошибок.
                      • +1
                        Речь идет об структуре и алгоритмах, конечно, а не о количестве ошибок.

                        Т.е. «хороший код» для вас — это «код, доставляющий эстетическое удовлетворение», а не «код, полностью решающий поставленную задачу»?
                        • 0
                          Красивый код, эффективно выполняющий поставленную задачу.

                          На самом деле, это связанные вещи.
          • –2
            Интерпретатор проигрывает маш.коду в 100 раз. Это на 9900%

            Какая у Вас интересная версия математики… в 100 раз быстрее == на 99% быстрее.
            Только причём тут это вообще? Я же написал "на данном классе задач", т.е. рендеринг простеньких HTML-страниц на основании данных, полученных из реляционной СУБД.
            Каким боком тут Dhrystone, актуальность которого осталась где-то в 80-х? Или при взгляде на великолепные результаты ассемблера в синтетическом бенчмарке у вас автомагически SQL быстрее работать начинает?

            • 0
              Не умеете считать, беда современного образования. В 2 раза быстрее = на 100% быстрее, в 3 раза быстрее = на 200% быстрее…

              Это тест вычислений с плавающей точкой. Весьма актуален в настоящее время, потому что данные операции подешевели и все больше заменяют целочисленные.

              Тест устарел, но он легко доступен и легко перепроверяется. Можно взять другие тесты.
              • –6

                Не выдумывайте! Считать не умеете Вы… Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.


                Можно взять другие тесты.

                Можно, только зачем, если в среднестатическом случае (для вышеописанного класса задач) 70% времени всё равно придётся на запросы к БД. Даже если весь остальной код будет выполняться за пару наносекунд, Вы всё равно получите лишь 30% ускорения. Учитывайте матчасть, а не только синтетику.

                • 0
                  ОК. На 9900% медленнее (так и было написано первоначально), так лучше стало?

                  И давайте представим, что БД тоже написал «эффективный программист», на PHP…
                  • +1

                    Стало лучше. Но, справедливости ради, первоначально речь шла о потенциале ускорения от переписывания на асме. Фиг знает, причём тут потенциал замедления от обратного переписывания и к чему вдруг Вы начали его считать..


                    И давайте представим, что БД тоже написал «эффективный программист», на PHP…

                    Вы понимаете смысл оптимизации узких мест? Хранилище данных очень часто оказывается узким местом, именно поэтому в оптимизацию СУБД вложено столько человеко-лет. И несмотря на это когда нужна действительно высокая пропускная способность всё равно приходится отходить от реляционной модели.
                    Проблема в том, что ассемблер не поможет написать отзывчивый высоконагруженный веб-сервис… вроде и потенциал есть, но по факту граблей больше. И даже отличные знания асма, на уровне автора статьи, не застрахуют Вас от performance-ляпов, как у автора получилось со страницей тредов по тегу (20-30 мс там, где должно быть 7-8 мс). При использовании ЯВУ такие performance-ляпы встречаются реже, т.к. можно сконцентрироваться на оптимизации узких мест, не распыляясь на оптимизацию каждой функции.

                    • +2
                      Согласен. Лучшая оптимизация — алгоритмическая. А лучшие алгоритмы получаются сложными, и их плохо писать на ассемблере.

                      Но я бы разделил ЯВУ на три класса
                      — быстрые компилируемые языки, как примеры c++, d, rust, go, даже фортран, паскаль и ада
                      — байт-машинные с динамической компиляцией jvm, pvm, net
                      — скриптовые php, js итп

                      С каждой ступенькой повышается уровень абстракции и понижается производительность.

                      К сожалению, есть тенденция писать быстро и лениво. А вместо оптимизации, замены фреймворка/языка, заниматься массовой демагогией и пропагандой типа «скорость языка неважна, все равно задержки в другом месте», «это сложно и дорого», «дешевле не стараться, а купить новый сервер»

                      И в итоге, используется, например Yii, который в 30 раз медленнее топов
                      • 0

                        С делением ЯВУ на классы я согласен, хотя там можно ещё интерпретаторы с JIT в отдельный класс выделить. А вот с тенденцией не согласен. Наоборот, тенденция писать на скриптовых языках слабеет с каждым годом. Народ активно смотрит в сторону Go, Elixir, Crystal, Nim, Clojure, etc.
                        Другое дело, что необязательно бросать все существующие наработки на PHP, Ruby, Python и JS. Во многих случаях достаточно выделить узкие места в отдельные сервисы на более быстрых языках, а ненагруженную часть проекта оставить, как есть.


                        P.S. Мне лично тоже нравится писать быстрый код, но опыт работы показывает, что в первую очередь бизнесу быстро нужен код, а не быстрый код.

                      • –2
                        А лучшие алгоритмы получаются сложными, и их плохо писать на ассемблере.

                        Нет с этим я не согласен. Сложными они получаются, когда пишут их на ЯВУ. Потому что лучшие алгоритмы, такие, которые ближе к CPU. Нативнее что ли. А таких намного легче писать на ассемблере. На ассемблере они и читаются лучше.


                        Правда, надо язык знать хоть немного. Но это для каждого языка в силе.

                        • +5
                          Ну смотрите, вы делаете сверхбыстрый веб Фреймворк, при этом:

                          1. Используете базу данных, которая физически не может вытянуть большое количество пользователей и данных,
                          2. Каждый раз заново парсите markdown, вместо хранения скомпилированного варианта,
                          3. Имеете непонятные баги перфоманса, когда страница сильно тормозит,
                          4. Не кешируете html страницы в памяти или диске для ускорения работы,

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

                          Вы же выигрываете копейки на скорости кода проигрываете тысячи на алгоритмах и архитектуре.
                          • 0
                            1. Каждый раз заново парсите markdown, вместо хранения скомпилированного варианта,

                            А сколько времени вы думаете отнимет чтобы сделать эту функцию? Моя оценка — около двух часов. Ничего сложного там нет. Понадобится, сделаю.


                            А кстати, этим можно протестировать насколько плохо поддерживается ассемблерный код.


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


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

                            • 0

                              Сделать миграцию, добавить заполнение поля при сохранении модели, заменить название поля при выводе — 10 минут. А может и меньше.


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

                              Во-во. На ЯВУ сложность вхождения в проект гораздо ниже.

                              • 0
                                Во-во. На ЯВУ сложность вхождения в проект гораздо ниже.

                                Совсем не факт. Это зависит от того насколько программист знает тот язык и фреймворк.

                                • +5

                                  Любой проект зависит от знания языка. Речь не идет об уровне знаний, подразумевается, что знание языка достаточное.


                                  Добавить поле на сайт — это типичная задача за 10-20 баксов на фрилансе. Думаете, там люди незнакомый проект неделями изучают? Да нет, просто берут и делают за пару часов. А у вас пара часов нужна даже на хорошо знакомый проект.

                      • 0
                        — байт-машинные с динамической компиляцией jvm, pvm, net
                        — скриптовые php, js итп

                        Странное деление, потому что PHP и JS перед выполнением точно так же компилируются в байт-код, как и JVM и .NET.
                        Скриптовые языки, которые не компилируются перед выполнением — это, например, bash и awk.
                        • 0
                          Делим так — с компиляцией JIT/AOT и без нее.

                          Только чтобы действительно был заметен эффект JIT, а не как раньше в Питоне — вроде и JIT, а толку 0
                        • +1
                          Мало того, трансляторы JS уже вовсю используют полноценную компиляцию в нативный код, есть такие трансляторы для PHP, а в референсном трансляторе вовсю идёт работа над ней.
                          • 0
                            Да, технологии движутся вперед. Возможно, скоро все будут иметь JIT.

                            Но это трейдофф за счет памяти, да и динамическая типизация мешает оптимизатору.

                            Так что обычные компилируемые языки со строгой типизацией будут всегда иметь некоторую фору.
                            • 0
                              На самом деле нет: у JIT-оптимизатора есть возможность «затачивать» код под фактически используемые пути выполнения, тогда как AOT-компилятор вынужден предугадывать, какие пути выполнения будут чаще использоваться.

                              Есть примеры, когда код на Java обгоняет аналогичный код на Си, потому что JIT-компилятор заменяет «заглушками» редко используемые ветви условий внутри часто выполняемых процедур, и в результате тело процедуры сокращается по размеру и помещается в кэш целиком.

                              То же самое и с динамической типизацией: если в некой переменной 99% времени хранится целое число и 1% времени — более сложный объект, то JIT-оптимизатор может сгенерировать эффективный код для работы с целым числом, который при получении объекта бросит исключение, которое виртуальная машина обработает в «медленном режиме». AOT-компилятор, напротив, вынужден при каждом обращении к такой переменной сгенерировать код для обработки всех возможных случаев; так что размер кода сильно разбухнет.
                              • 0
                                Теоретически да, но вот используются ли такие хинты современными JIT на самом деле?

                                Собственно, я и сказал «за счет памяти», а не скорости.

                                Про влияние кэша очень сомневаюсь, что его можно оценить.
                                Кроме того и современные кэши огромные, и код JITа кусок себе отъест — он же тоже исполняется в этот или близкий момент.
                                • 0
                                  Теоретически да, но вот используются ли такие хинты современными JIT на самом деле?
                                  Естественно.
                                  Кроме того и современные кэши огромные, и код JITа кусок себе отъест — он же тоже исполняется в этот или близкий момент.
                                  Практически всё время выполнения программы приходится на скомпилированный код; иначе бы смысла в JIT-компиляции не было.
                                  Т.е. JIT-движок вытесняется из кэша сразу после очередного этапа компиляции, и уступает кэш скомпилированному коду.
                • 0

                  Ускорить на 200% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость.

                  • –4

                    Правильный вариант Вашего комментария звучит так:
                    "Ускорить на 66.(6)% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость."


                    P.S. Любая величина изначально принимается за 100% при расчётах. Допустим, после оптимизации стало в 3 раза быстрее, т.е. (100/3)% от начального значения, значит мы ускорили на (100 — 100/3)%.

                    • 0
                      Любая величина изначально принимается за 100% при расчётах. Допустим, после оптимизации стало в 3 раза быстрее, т.е. (100/3)% от начального значения, значит мы ускорили на (100 — 100/3)%.
                      А вы не путаете скорость вычислений и время вычислений?
                      • –3

                        Ничего я не путаю, увеличение скорости вычислений в 3 раза — это и есть сокращение времени вычислений на 67%… И то и то упрощенно называется ускорением.
                        А если хотите морфологией заняться, то не забывайте, что ускорение — это производная от скорости по времени, удачи в трактовке ;-)

                        • 0
                          увеличение скорости вычислений в 3 раза — это и есть сокращение времени вычислений на 67%
                          и увеличение операций в единицу времени (скорости вычислений) на 200%
                          • –2

                            И что? Мы измеряем время в рамках бенчмарков, ips — это производная (вычисляемая, а не измеряемая) характеристика. Ускорить алгоритм == сократить время его выполнения. Это общепринятая трактовка.
                            Другими словами, ускорение на 67% == ips вырос на 200%.
                            Поймите простую вещь, "рост ips" и "ускорение" — это не синонимы ни разу.

                    • 0
                      Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.

                      "автомобиль ускорился на 200%" = "автомобиль увеличил скорость в 3 раза".
                      "автомобиль замедлился на 200%" = ???


                      P.S. Изначально производительность была N исполнений в секунду. После оптимизации стала 3N исполнений в секунду. Была 100%. Стала 300%. Изменилась на 200%.

                      • –5

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

                        • 0

                          Ох-х-х, кунсткамера ты моя родная, скучал по тебе...

                    • –1
                      Что-то я перечитывал-перечитывал, но так и не понял, откуда взялось "(100/3)%"…
                      «x стало в три раза больше» означает «x*3», почему Вы делите-то? О_о
                      • –1

                        Было 100 ms, стало в 3 раза быстрее, т.е. стало 33 мс. Так понятнее?
                        Слово "ускорился" в контексте быстродействия синоним слова "подешевел".
                        Функция ускорилась в 2 раза == Функция подешевела в 2 раза == Стала занимать в 2 раза меньше времени.
                        Функция ускорилась на 50% == Функция подешевела на 50% == Стала занимать на 50% меньше времени.
                        Аллюзии к слову "скорость" тут совсем не в тему. У меня странное ощущение, от того, что мне приходится разжевывать такую базовую тему на Хабре… Причём эффекта ноль, никто даже не пытается задуматься над неверным пониманием этого аспекта.

                        • +1
                          Скорость это в любом случае величина обратно пропорциональная времени.
                          Функция ускорилась в 2 раза == скорость выполнения функции стала больше в 2 раза == функция стала быстрее на 100% == функция стала занимать на 50% меньше времени. Вы пытаетесь подменять понятия, и говоря о быстродействии но подразумевать скорость. Это такая же ошибка, как говорить что частота измеряется в секундах, хотя задав период в секундах мы однозначно определяем частоту.
                          • 0

                            Ну, ё-моё, опять 25… Забудьте Вы уже про скорость… Абстрагируйтесь от неё, если морфологическое сходство слов вас так сильно запутывает. Тем более, что такого термина как "скорость выполнения" в принципе нет в бенчмарках.
                            Бенчмарки меряют время ожидания (latency в секундах) и считают пропускную способность (throughput в ips или в rps).
                            При этом изменения latency обычно считают в процентах, а изменения throughput — в разах.
                            Ускорилось на 50% = latency уменьшилось на 50% = throughput вырос в 2 раза = ускорилось в 2 раза.
                            Вы же пытаетесь ввести какую-то свою терминологию, и не понятно откуда Вы её вообще взяли… Мне прям даже интересно на базе чего Вы так упорствуете… Дайте хоть ссылку на какую-нибудь benchmark-утилиту, которая вашей методологии подсчётов придерживается.

                            • 0
                              Забудьте Вы уже про скорость…
                              А как тогда производительность процессора измерять: в секундах или гигафлоппс?
                            • –3
                              >>Мне прям даже интересно на базе чего Вы так упорствуете…
                              На базе знания русского языка и математики. Их, знаете, в младшей школе изучают. Вам пора бы уже их изучить, а то как-то плохо выглядит их полное незнание у взрослого (я надеюсь) человека.
                            • 0
                              А как вы так смешали latency и throughput? Это вообще не связанные два параметра. Общего у них только то, что иногда некоторые приёмы оптимизации влияют сразу на оба параметра, так что один улучшают, а другой ухудшают — и приходится выбирать что важнее.
                    • –1
                      Если стало в 3 раза быстрее — то это 100*3%, а никак не 100/3%. Если скорость 1000 операций в секунду, то ускорение в три раза — это 3000 операций в секунду, а не 333.(3) операции в секунду. Передавайте привет своей учительнице математики в младшей школе, и передайте что она проф. непригодна.
              • 0
                Это тест вычислений с плавающей точкой. Весьма актуален в настоящее время, потому что данные операции подешевели и все больше заменяют целочисленные.

                Вы его с чем-то путаете, потому что это как раз тест целочисленных вычислений.
                The Dhrystone benchmark contains no floating point operations, thus the name is a pun on the then-popular Whetstone benchmark for floating point operations.

                Весьма актуален в настоящее время, говорите?
                • 0
                  Верно, это целочисленные, строки и скорость вызова подпрограмм. Перепутал

                  Вот исходник
              • +1
                > Это тест вычислений с плавающей точкой. Весьма актуален в настоящее время, потому что данные операции подешевели и все больше заменяют целочисленные.

                Это где интересно? Разве что в играх. В бизнес-логике в основном строки и целочисленные айдишники.
                • 0
                  И в этой бизнес-логике критически важна скорость операций над строками и целочисленными айдишниками?
                  • +1
                    А что есть html? Строки. Что есть json и xml? Строки. Что есть sql запросы? Cтроки. Что есть деньги? Целочисленный тип, так как типы с плавающей точкой не подходят для хранения денежных сумм. Вычисления с плавающей точкой в бизнес логике тоже встречаются, но их редко бывает очень много.
                    • 0
                      Речь-то шла не про деньги, а про целочисленные айдишники.
                      И не про обработку html / json / xml / sql — ею, я надеюсь, занимается бэкенд — а про бизнес-логику.
                      • +1
                        ею, я надеюсь, занимается бэкенд — а про бизнес-логику.

                        Ооо, а что такое, по вашему, бэкенд? Где у вас живет бизнес логика в классической трехзвенке? Во фроненде или базе данных?
                    • +1
                      А что есть html? Строки. Что есть json и xml? Строки. Что есть sql запросы? Cтроки.

                      Это всё форматы представлений и запросов. Бизнес-логика обычно оперирует числами и идентификаторами (по сути не важно в какой форме).
                  • 0
                    Нет, но и вопрос мой не об этом. Хотя быстро обрабатывать строки тоже не помешает.
                • 0
                  В бизнес-логике в основном строки и целочисленные айдишники.

                  Это что же за бизнес-логика такая? Обычно бизнес-логика считает количества, цены и стоимости.
                  • 0

                    Количество — целое число. Цену и стоимость во флоатах не считают. Разве что в статистических отчетах и графиках, но там и раньше так считали, то есть нельзя сказать, что там операции с плавающей точкой заменяют целочисленные. Оттого и вопрос.

          • 0
            Машкод х86 — это интерпретируемый процессором в элементарные операции язык.
    • 0
      Память, в первую очередь. Все эти «современные CMS» совсем ухи наелись.
  • +9

    Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба ассемблер можно превратить в троллейбус язык веб-программирования… Но зачем?

  • +6
    Писать веб-сайты на ассемблере полезно и приятно

    Жесть


    Для базы данных была выбрана SQLite.

    Жестокая жесть


    Ну, вот и все. Если кому понравилось, используйте на здоровье.

    Спасибо, как нибудь в другой раз. В другой жизни.

    • +8
      Ты скучный. Наверняка, даже не пытался никогда написать программу опкодами.
    • +10
      Писать веб-сайты на ассемблере полезно и приятно
      Жесть

      Не очень понятно — человек взял написал и говорит, что это полезно и приятно.
      А у вас как-то не аргументировано.
    • –1
      Для базы данных была выбрана SQLite.
      Жестокая жесть

      А что с SQlite не так? Или коллега привык на каждый чих развертывать MSSQL?
      • 0

        Насколько понимаю, SQlite поддерживает одного писателя, а когда имеем несколько писателей, то получаем SQLITE_BUSY, который приходится обрабатывать вручную.


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

        • +1
          По умолчанию. Но её можно перевести в режим WAL.
          • +1

            При WAL читатели не блокируют писателей, а писатели не блокируют читателей. Т.к. WAL один, то и писатель может быть только один. И все равно есть пункт: Sometimes Queries Return SQLITE_BUSY In WAL Mode.

      • +4

        Я привык, что у меня развернут постгрес и я просто добавлю новую базу в кластер.
        К чем смысл страдать с асмом ради первоманса и экономии памяти а, в итоге, подключить тормозок sqlite'a.


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

        • +2
          А вообще у автора много свободного времени и запасная жизнь. Я бы столько времени не тратил непонятно на что.

          Зачем идти в пеший поход на неделю, если можно до конечного пункта доехать на поезде за два часа?
          Зачем рисовать картину красками, если можно щёлкнуть айфоном и распечатать?
          Вот и тут как-то так.
        • 0
          SQLite скорее всего будет быстрее.
  • +20
    Надо было публиковать это в хаб «Ненормальное программирование» :)
    • 0
      Пора заводить хаб «Ненормальный back-end», ну а там и «ненормальный front-end» подтянется.
      • +9

        Для неопытного фронтендчика — весь современный фроеюнтенд кажется ненормальным)

  • +5
    > Использование веб программы на ассемблере может сэкономить много денег от хостинга

    [sarcasm] Хостинг-провайдеры кусают локти и ждут обрушения рынка. [/sarcasm]

    Ничего. Левша вон блоху подковал, и тоже не взлетело — бывает.
  • +1
    Free text search — FTS

    Full Text Search же :-)

  • +2
    С одной стороны, писать сайт на ассемблере — не-кост-эффективно.

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

    В ту же копилку — любой SQL также не особо эффективен по отношению к конкретной задаче. Но до определенного предела (SQL кстати, забывают что погрешим), весьма удобен.

    А что потом? Ищем оптимальные, или используем подставные планы исполнения, пытаемся как то обмануть абстрактные машины типа sql, jvm и прочие байт код интерпретаторы.

    Это тлен, во имя «быстро написать и сдать».

    Дальше скупые платят уже нам вдвойне, «за оптимизацию»

    Просто бизнес
  • +1
    Это и забавно и круто одновременно…

    Хотя пожалуй больше всё-таки забавно.
  • +4
    Ассемблер — и какие то внешние библиотеки? Как то фу. Интереснее было бы ограничиться каким-то объемом как на спектруме, и чтобы его на всё хватало — и на код, и на данные. Без базы, только с набором подпрограмм, редуцированных до обслуживания постохранилища. Ну и загружать-выгружать это целиком.
  • –5
    Браво! Наконец-то кто-то это сделал.
    Я С/С++ программист в свободное время изучаю (пока только изучаю) современные веб-фреймворки, и это туши свет! Мало того что php/python/ruby etc. сами по себе интерпретируемые языки, так разработчики еще и внутрь умудряются напихать каких-то бешеных абстракций! ORM — «птичий» язык доступа к БД, зачем когда есть SQL? Шаблонизаторы — еще один птичий язык. Я когда смотрю на это и понимаю какое количество пустопорожнего кода там выполняется, сколько раз происходят бессмысленные переаллокации памяти и перекачивание данных между буферами прежде чем они попадут в HTTP поток…
    А если еще вспомнить как работает веб сервер — активизируется заново для каждого обращения, выполняет каждый раз 99% одних и тех же действий и только 1% отличающихся для каждого запроса… это тоже непаханное поле для оптимизации, и какое нибудь кэширование байт-кода php только слегка затрагивает эту тему.
    Конечно писать именно на Ассемблере… может быть просто just for fun, но на Си — вполне разумное решение.
    • +5
      php/python/ruby etc. сами по себе интерпретируемые языки

      неправда. Они компилируются в байткод, который потом исполняется виртуальной машиной.


      умудряются напихать каких-то бешеных абстракций

      которые нужны, чтобы код от разных вендоров работал "искаропки" и имел одинаковые интерфейсы.


      ORM — «птичий» язык доступа к БД, зачем когда есть SQL

      затем, чтобы вы могли выбрать данные из одной СУБД (например MySQL), "сджойнить" их с данными из другой (например MongoDB, мне это приходилось делать), закешировать на некоторое время, и всё это без кучи бойлерплейт кода каждый раз. Для любителей SQL есть Query Builder'ы, которые генерят запросы для разных диалектов SQL.


      Шаблонизаторы — еще один птичий язык

      а что вы предлагаете взамен? Только PHP, насколько я знаю, позволяет инлайнить код прямо в HTML, остальным языкам (React не рассматриваем) нужны шаблонизаторы. Хорошо, что есть широкоиспользуемые языки для шаблонов (Mustache, Jade/Pug и т.д.), которые позволяют не учить 100500 разных синтаксисов, а везде делать одинаково (имел несчастье работать с angular1 на фронте и php на бэкенде, один шаблонизатор немного сгладил боль).


      переаллокации памяти и перекачивание данных между буферами

      оверхед неизбежен, но это плата за скорость разработки.


      как работает веб сервер — активизируется заново для каждого обращения

      это не так. Какой-нибудь apache ещё может порождать по процессу на запрос, но, к счастью, к нему прибегают всё реже. nginx, например, имеет пул процессов, которые обрабатывают запросы пользователей. Здесь можно мне возразить, что процесс всё же порождается, но только это не веб-сервер, а какой-нибудь PHP-интерпретатор. Да, это так, но только если вы не используете fastCGI. В остальных языках чаще используется какой-нибудь встроенный в веб-фреймворк (Node.JS, Ruby Unicorn и т.д.) HTTP сервер (хотя мне тоже такое решение не особо нравится).


      на Си — вполне разумное решение

      нет. Это очень опасное занятие. Даже матёрые программисты допускают глупые ошибки, которые могут очень дорого обойтись. Все эти "интерпретируемые языки" зачастую неплохо отлажены и не имеют таких багов, по крайней мере, их сложнее эксплуатировать. Если хотите убер-скорость, но чтобы было безопасно, взгляните на Rust, с его zero-cost abstractions, и какой-нибудь веб-фреймворк для него или на Go и его решения.


      P.S. Сам я веб-разработчик и сейчас, как раз, изучаю Rust, но всё равно не стал бы на нём писать веб.

      • +1
        Только PHP, насколько я знаю, позволяет инлайнить код прямо в HTML, остальным языкам (React не рассматриваем) нужны шаблонизаторы.

        Java тоже может, либо в серлетах генерить HTML просто как текст, либо инлайнить код прямо в HTML это JSP технология. Но в большинстве случаев оно не несет особого смысла, так как по сравнению с любым запросом в БД шаблонизатор практически не требует времени и ресурсов.
      • 0
        оверхед неизбежен, но это плата за скорость разработки.

        Ага, рассказывайте, скорость разработки ) Автор топика написал за месяц с нуля форум на ассемблере, даже не зная что такое FastCGI. А вкурить во все эти тонны абстракций, все эти ORM и шаблонизаторы, изучить какой-нибудь фреймворк - займёт куда поболее месяца. При этом, как не знал, что такое FastCGI, так и не узнаешь.
        • +4

          Автор конечно крут, но надо учитывать сколько лет он до этого писал на ассемблере… Я думаю, если взять такой же опыт в веб-программировании, то все абстракции будут уже давно вкурены и изучить какой-нибудь ещё один фреймворк можно будет за день :-)

          • –1
            В целом, да. Не досконально, но типа форума написать на незнакомом фреймворке и даже на незнакомом языке вполне можно за день. Если не выходить за рамки привычных парадигм типа ООП и иметь приличную документацию.
    • +9
      Это кажется ненужным, пока пилишь <h1>Hello world</h1>. Я сам ориенитровался на low-level, и мне тоже было не понятно, зачем всё это. Но так получилось, я попал на работу в качестве веб программиста. Там пилят один облачный проект уже далеко не один год (т.е. он работает и его пилят одновременно). Там производительность не на первом месте точно, т.к. имеется два жирных сервера. Зато на первом месте поддерживаемость. И, собственно, стало понятно почему. Когда пилишь что-то для себя, обычно помнишь, что как робит. Когда приходишь в новый для тебя проект, плюс нужно читать чужой код, то понимаешь необходимость всего этого. Без этой мишуры какая-нибудь вшивая правка на два часа работы может обернуться недельным выносом себе мозга.
      • 0
        Если язык разработки будет статически и строго типизированным и компилируемым, то значительная часть вшивых правок приведет к нормальным ошибкам на этапе компиляции, а не недельным выносом себе мозга.
        • +2
          Если язык разработки будет статически и строго типизированным и компилируемым

          Отличная идея! Только причём тут low-level? В ассемблере типизации вообще нет, в Си она слабая… А под Ваш критерий лучше подходит Haskell, или Idris, или на крайний случай Crystal.

          • 0
            Или Go, самый очевидный тут вариант, который вы почему-то пропустили.
            • 0

              Да, тоже вариант. Он мне просто по субъективным причинам (не относящимся к типизации) меньше нравится, чем вышеуказанные языки.

            • +1

              У Go грустная система типов по сравнению с каким-нибудь Idris.

        • 0
          Смотря как организовать. В плюсах динамическую типизацию частично объединения заменяют. Что действительно сложно заменить из PHP — это символические ссылки на классы. Т.е. конструкция вида:
          $object = new $class; неплохо так вынесет мозг рядовому C++ программисту. Но, как заметил, такие штуки нечасто используются.
          • +2

            не хочу вас расстраивать, но довольно часто во всяких фабриках и прочих порождающих шаблонах)

            • +1
              Именно в них и видел. Говорил относительно того проекта, где я участовал. Там фабрики не столь частое явление. К тому же зачастую они очевидны. Особое веселье данная конструкция доставляет, когда имена классов подтягиваются откуда-то из анналов, каким-нибудь образом меняются и объявляются. Потом тебя просят убрать какой-нибудь из этих классов из проекта.
    • +6

      Все эти абстракции и птичие языки нужны для делегирования работы между разными специалистами, экономии вменении разработки, упрощения поддержки и тестирования.
      В один прекрасный момент ресурсы у любого железа кончаются и поднимается вопрос о распределении нагрузок. Так уж получается, что основное время ваша система, пусть даже на С будет тупо ждать ответ. С этого ракурса — написав web систему на C вы не особо выиграете. Если же взять во внимание время, которое вы потратите на разработку — это будет на много дороже.

    • 0
      На Ассемблере конечно не очень технологично, но если подойти фундаментально и написать целый Web Framework на нем с уже отработанными(на высокоуровневых инструментах) кейсами, тогда есть возможность попытать чего то в этом, Но разработка будет — долгой, и мы не всегда успеваем за тенденциями, в то время как производится разработка, начав серьезный «поход» трудно его на лету «корректировать», чтобы такой проект «выстрелил» и уже готовый появился на свет «вовремя», сейчас разработка «велосипедов», оправдывает себя только если это делается Очень быстро при условии что «парадигма» будет реально эффективна с точки зрения юзабилити, охватываемых кейсов и производительности, но одно другому мешает в данном сравнении.
  • 0
    Заметил, что время выполнения скрипта линейно возрастает от кол-ва постов в теме (1 пост ~ 2ms, 15 постов ~ 13ms) с чем это связано? Не с базой же.

    UPD: хотя судя по всему именно с базой. Статистику по запросам интересно было бы посмотреть. Изучать какие запросы в коробке как-то трудновато, учитывая незнание asm
    • 0

      Это из за рендеринга markdown. Каждый пост обрабатывается отдельно. А markdown вообще транслируется весьма сложно — там два прохода по тексту и сложные правила. BBcode было бы на порядок быстрее.

      • +3
        А почему вы не храните у себя два варианта? Транслированный вариант и оригинал?
        • 0

          Можно конечно. Только для прототипа это было не нужно. Производительность пока хватит с избытком. А если понадобится сделать можно очень быстро.

          • +4
            Ну я так скажу, у нас коммерческая црм, написанная на php (+phalcon) работает не сильно хуже, когда речь идет о большом кол-ве постов. Понятное дело не 2мс, но 20, по памяти выходит близко к вашему (2-4мб, если замерять средствами php).

            К чему это я? Можно было бы сделать реально что-то очень быстрое, чтобы показать реальные преимущества, а не только теоретические.
            • +1
              Ну я так скажу, у нас коммерческая црм, написанная на php (+phalcon) работает не сильно хуже, когда речь идет о большом кол-ве постов. Понятное дело не 2мс, но 20, по памяти выходит близко к вашему (2-4мб, если замерять средствами php).

              Между 2 и 20мс разница в 10 раз. А кстати, на каком сервере работает этот php+phalcon? Параметры моего хостинга даны в статье.

              • +3
                Между 2 и 20мс разница в 10 раз, я согласен. А вот разницы между 20мс и 20мс нет :)

                Сервер конечно лучше вашего, я просто хотел показать что это не какие-то ВАУ числа. 20мс даже на таком хостинге как у вас не вызывают восторга. Да, быстро, но не более того.
  • +6

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

    • 0
      Переписать в виде модуля апача.
  • +1
    Для полноты эксперимента осталось запихать все это в микроконтроллер.
    • +5
      >я решил писать на 32 битном ассемблере для x86
      Только вот не «запихать», а «нахрен с нуля переписать».
      На мой взгляд Си, а то и Си++ (можно обмазаться STL и перестать бояться возни со строками практически без штрафов производительности) куда лучше подходят под такие задачи хотя бы из-за своей кроссплатформенности.
    • 0

      Первая мысль при прочтении)

    • +1

      Esp8266 !!!

  • +8
    На мой взгляд, эта статья доказывает не тот факт, что на Assembler можно разрабатывать веб-приложения — это и так понятно, просто дурака не нашлось, который это сделает, а то, что у программиста присутствует страх выхода из зоны комфорта (боязнь обучения новым технологиям и языкам).

    А теперь давайте спросим сколько времени потребовалось сделать такой форум на Assembler, и сколько времени потребуется на эту же задачу «порочным» «PHP, ну или на один из модерных языках Питон, Руби, Node.js и т.д.» программистам.
    • 0
      Ну, если задача стоит сэкономить «на спичках», предельно минимизировав нагрузку на сервер, ASM, конечно, неоптимален, но как замечено чуть выше, C или С++ вполне себе выбор, благо под второй я знаю несколько веб-фреймворков, да и под чистый C, вроде, есть какие-то наработки.
    • 0
      А теперь давайте спросим сколько времени потребовалось сделать такой форум на Assembler, и сколько времени потребуется на эту же задачу «порочным» «PHP, ну или на один из модерных языках Питон, Руби, Node.js и т.д.» программистам.

      Я написал сколько времени потребовалось мне. Но ничего не могу сказать насчет Питон и Руби. Если вы можете, то скажите и сравним.


      Но мне кажется, что на ЯВУ, очень грязно и с багами, написать будет быстрее, а вот вылизать все и выдать работающий продукт уже будет вполне сравнимо.

      • +2
        На Java, с использованием веб Фреймворков, ORM и т.п., подобный функционал грязно и с багами можно сделать за два дня (за день если очень спешить).

        Вылизать все и выдать работающий продукт, то есть работающий на любой базе данных, с сотнями и тысячами unit, интеграционных, e2e и перфоманс тестов, который можно продавать за реальные деньги — может быть будет сравнимо по времени с вашей разработкой, только это совсем другой класс продуктов чем ваш форум. Уж поверьте, ваш форум находится тоже в категории «грязно и с багами», просто потому что его оттестировать по-настоящему долго и дорого.
        • 0

          А без веб Фреймуърков?


          Потому что, если считать AsmBB веб фреймуърком, то теперь я тоже за два дня могу чего нибудь подобное написать — например блог или cms.

          • +2

            А что-то более серьезное?)

            • +1

              Не вопрос. :D

              • 0
                Ну оцените для начала, сколько займет реализация HTTPS? :)
                • +2
                  Ну оцените для начала, сколько займет реализация HTTPS? :)

                  А она уже реализована. Давал выше ссылку на RWASA, но опять дам, не жалко: https://2ton.com.au/rwasa/


                  Замечательный сервер 100% на ассемблере с TLS и FastCGI.

                  • +1
                    Не, ну это же не вы написали.

                    Вообще SSL тут просто в качестве примера — сколько времени займет реализация скажем прокотола SPDY или HTTP 2.0, на асме?

                    Таких тонких мест в web достаточно много — например, были попытки вызвать DDOS путем передачи сервису заголовков, вызывающих множественные коллизии в hash map, где обычно хранят заголовки сервера на Java. Вы же храните http заголовки? Насколько вам легко поменять тип контейнера?

                    И так в общем на каждом углу будет — либо все будет в виде библиотек, а тогда зачем ассемблер?

                    Вот скажем не очень быстрый язык groovy, для JVM. Насколько я помню, на достойном железе, за счет некоторых несложных оптимизаций, безо всякой магии, на нем получали результат порядка полумиллиона http запросов в секунду. Сколько у вас один запрос, 1мс? Так вы значит в 500 раз отстаете, или я что-то неправильно считаю?
                    • +1
                      Не, ну это же не вы написали.

                      На ЯВУ пишется быстро и легко именно потому что многое уже написали не мы. То что требовалось доказать.


                      Насколько я помню, на достойном железе...

                      Не знаю. Всегда запускал только на очень недостойном железе. Если у вас, есть "достойное", попробуйте запустите и скажите.

                      • +2
                        Не, ну берем простой ActiveMQ. Это чистая Java. Он на вполне обычном недорогом двухядерном железе выдает порядка 2000 сообщений в секунду.

                        Это не http а немного другое — но тем не менее, это получение сообщения из сети, складирование его в базу, некоторая маршрутизация, отдача клиенту снова по сети. Т.е. тут есть все основные компоненты, типичные и для http тоже, кроме разве что шаблонизаторов.

                        В итоге — меньше 1 мс на сообщение. Память сэкономили? В большинстве практически интересных случаев дополнительная память стоит просто такие копейки, которые с зарплатой программиста несравнимы.

                        И потом — вы в курсе, что сегодня html страница бывает порядка мегабайта, и зачастую делает много чего интересного на сервере? Т.е. сожрать всю вашу экономию памяти — это просто подключить скажем svg процессор какой-нибудь, или imagemagic, или еще какую-то фигню для генерации контента?

                        Ну и ради чего стоило так стараться? Разве что из спортивного интереса.
                        • 0
                          Т.е. сожрать всю вашу экономию памяти — это просто подключить скажем svg процессор какой-нибудь, или imagemagic, или еще какую-то фигню для генерации контента?

                          Надо просто и это переписать на ассемблере.

          • +3
            я тоже за два дня могу чего нибудь подобное написать — например блог или cms.

            Хорошо, а за сколько вы напишите простой сайт онлайн банкинга с транзакциями и необходимой надежностью?
            За сколько напишите интеграцию по Rest и Soup с другими сервисами, прикрутите к вашему форуму Ajax, работу с json и xml?
            Загрузку и выгрузку в Excel/Word?

            Все это грязно и с багами тоже делается на Java за 2 дня (все вместе). А у вас за сколько? Особенно без хаков с чужими библиотеками.

            А без веб Фреймуърков?

            А это бессмысленно предложение, серлеты, JSP, orm это официальная часть Java технологии, её вам предоставит любой веб.сервер на Java, это равносильно сказать, за сколько вы сделаете свой сайт без вебсервера.Так или иначе, веб фреймворк, хотя бы на уровне серлета (то есть генератора HTML из текста, на Java будет).
            • +3
              А у вас за сколько? Особенно без хаков с чужими библиотеками.

              Странно почему на Java можно использовать чужие библиотеки, а на ассемблере, видите ли, нельзя ???

              • +6
                Потому что теряется всякий смысл использования ассемблера. Ну подключите вы библиотеку на Java для работы с Excel/Word, базу данных на C++, шаблонизатор на PHP и что останется у вас от ассемблера? Только код не переносимый между процессорами и как бы сайт на ассемблере. Можно вообще весь код написать на C или Java, а потом одним вызовом подключить «библиотеку».

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

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

                Производительнее в том плане что используя многопоточность, нормальные базы данных, кэширование получиться отклик страницы намного быстрее чем вы сможете достичь на ассемблере Так как скорость кода вовсе не означает скорости ответа.
                • +2
                  Хорошо, уточню: без хаков с чужими библиотеками, написанными на высокоуровневых языках. На Java можно обойтись библиотеками, созданными только на Java, а на ассемблере?
                  А что, есть JVM, написанная на Java, которой можно пользоваться?
                  В целом, как забивание микроскопом гвоздей разработка забавная, но на любом языке (хоть Java) можно сделать лучше, быстрее и даже производительнее.
                  Ваша Java на таком хостинге, да и на очень многих подобных, даже не запустится
                  Производительнее в том плане что используя многопоточность, нормальные базы данных, кэширование получиться отклик страницы намного быстрее чем вы сможете достичь на ассемблере Так как скорость кода вовсе не означает скорости ответа.
                  Надо сравнивать технологии с одинаковым стеком
                  • +6
                    Ваша Java на таком хостинге, да и на очень многих подобных, даже не запустится

                    Запустится, Java 8 требует 128 МБ памяти и 126 МБ на диске.

                    Надо сравнивать технологии с одинаковым стеком

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

                    Ну да, Java обгонит по производительности Си если подключить библиотеку на ассемблере и делать всю критическую по производительности работу в ней. Только так нечестно сравнивать производительность и нечестно сравнивать скорость разработки ассемблере, если 99% функционала на самом деле будут выполняться на высокоуровневом языке.

                    • +1
                      Запустится, Java 8 требует 128 МБ памяти и 126 МБ на диске.
                      Я имел в виду аналогичный сайтик на Яве, а не просто JVM.
                      Проблема скорее в прожорливости фреймворка, чем в JVM.
                      • +1
                        Проблема скорее в прожорливости фреймворка, чем в JVM.

                        Значит надо не использовать такие фреймворки. Tomcat или Jetty (это веб серверы для Java) требуют около 12Mb памяти и диска, примерно столько же сколько Апач, при этом дают возможность использовать сервлеты и всякие jsp. Для данной задачи этого с головой хватит.
                        • 0
                          Ну прямо чудеса какие то.

                          Но почему то дефолтная установка Tomcat 8 прописана с Xms256Mb.

                          Я уже молчу про размер виртуальной памяти для Java фреймворка — VSZ в 2.5Гб — то что она намерена сожрать (по необходимости).
                          • +2
                            Но почему то дефолтная установка Tomcat 8 прописана с Xms256Mb.

                            Дефолтная установка и минимальная установка это совсем разные вещи. Дефолтная установка не предполагает экономию памяти и вообще предназначена для больших EE приложений, то есть она прописана с огромным запасом (там принцип — память дешевле процессора, поэтому лучше сожрать больше памяти, но работать чуть быстрее).
                            К тому же я говорил про Tomcat 6/7, они едят чуть меньше памяти чем 8. По дефолту Java приложение съест столько памяти сколько ей «хочется», но можно заставить работать её с и меньшим кол-вом памяти. Тем более если там не будет ничего серьезного вроде транзакций, а простейшие сервлеты, вида сгенерировать html из строк и простых jdbc запросов к базе.
                            • 0
                              Так Вы в состоянии продемонстрировать минимальное потребление?

                              Запустить минимальное серверное приложение, заставить его «прогреться» запросами и показать вывод RSS и VSZ для Java-tomcat процесса
                              • 0
                                Эээ, вы правда считаете что мне больше в жизни делать нечего? Продемонстрировать в состоянии, но тратит свое время на это не собираюсь. Мне, в принципе, все равно верите мне или нет. Если вам это важно, гугл в помощь.
                                • –5
                                  Очевидно, ты простой дилетант, если для тебя элементарная задача подтвердить свои слова хелловорлдом существенно «тратит свое время».

                                  А то, что ты писал про базовое потребление, я на стековерфлоу тоже видел.

                                  Толку от тебя 0.
                                  • +3
                                    Угу, демагогия прием «ad hominem» — переход на личности.

                                    Задача элементарная, но все эти «сделай бенчмарк», дай отчет об «использовании памяти» в Инете всегда заканчивается одним и тем же: это неправильный отчет/ты исправил цифры в блокноте/ты померил не то и не там/ты запустил на Linux, а надо было на Windows, не на 32 битном процессоре, а на 64битном, не в включенном Compressed Oops, а с выключенном/твоя конфигурация слишком минимальна. И вообще твой Hello World слишком простой, давай сразу форум как у автора напиши.

                                    Не хочу заниматься сомнительной игрой «Докажи, что не верблюд» и тратить время на установку и настройку Tomcat 6/7 в минимальной конфигурации. Плюс если делать исследование по уму, то любой элементарный бенчмарк требует учитывать много моментов и проверять его работу на разном железе/операционках. Если мне нужно будет засунуть tomcat или Jetty в хостинг с минимальными характеристиками, тогда проведу полноценное исследование и напишу статью, но на это придется потратить пару дней, если делать все по уму.

                                    Если у вас есть реальный интерес, а не просто холивары разводить — подскажу на сайте tomcat'а море работающих примеров, скачиваете tomcat, примеры и тестируйте сами.
                                    • +1
                                      Это не бенчмарк, это простая проверка порядка — 10мб в действительности потребляется минимально, или все же 200. Точность бенчмаркинга здесь не нужна.
                                      Тем более, речь идет о простом минимуме.

                                      Я, например, не поленился скачать виртуалку с Томкатом и посмотреть, например.
                                      • +1
                                        Я, например, не поленился скачать виртуалку с Томкатом и посмотреть, например.

                                        И ваши результаты?
                                        • 0
                                          133 Mb RSS минимум только для процесса Томката8, Java8
                                          • 0
                                            Уточните это включая JVM Java 8 или нет? Если да, то учитывая что её минимум 128 Mb (как я говорил выше) это вполне ожидаемо.
                        • +1
                          Да не рассказывайте сказки, сейчас работаю над проектом одним - там надо разворачивать кучи виртуалок с этой жабой на этом томкате - вполне радостно ради вшивого интернет-магазинчика по 2 гигабайта каждый инстанс кушает. И тормозит нещадно. Молчу уже про то, что просто для того, чтобы весь этот зоопарк запустить, надо подождать, пока томкат две минуты занимается каким-то индексированием. Тьфу, в этом плане даже php в разы быстрее, экономичнее и удобнее.
                          • 0
                            Аналогично, Питон тоже весьма компактен.
          • +8
            Напишите точно такой же форум, только с базой MySQL. 2 дня точно хватит?)
    • 0

      На bash в конце концов.

      • 0
        Дык, https://archive.org/details/bashttpd
  • +6
    «Писать веб-сайты на ассемблере полезно и приятно» — что? Сайты на современных языках типа php или java скорее получат бутылочное горлышко в бд или сетевых протоколах, чем в языке. Чтобы не быть голословным — работаю на ну оочень немаленьком проекте на php. И несмотря на мощную бд на амазоне — мы постоянно упираемся в её скорость. Недавно перешли на php7 — а заметно скорости не прибавилось. Скажете «вы просто говнокодеры»? Возможно. Но врядли вот эти ребята (разработчики mysql) тоже говнокодеры. А их нанимал клиент для оптимизации нашей бд. Вывод из этого всего? А он простой — при огромной кодовой базе написанной несколькими командами разработчиков — сайт упирается во всё что можно, только не в скорость кода. Чем бы тут помог ассемблер, кроме как лишними проблемами?
  • +11
    Итого. Вы переизобрели обработчик FastCGI, парсер HTTP, GET и POST, решали проблемы с разрядностью и библиотеками, все это вместо того, чтобы решать задачу. Вы месяц писали простой форум, и написали 12000 строк кода, который сложно поддерживать. Писать сайты на ассемблере можно для себя, если охота, но для бизнеса это неприемлемо.
  • 0
    Как и многие другие сервера, к сожалению кладётся с помощью старого-доброго slowHttp read
    • 0

      Насколько я понимаю, это проблема веб сервера, а не AsmBB. Но я не заметил чтобы демо форум падал сегодня.

  • +1

    Интересная идея.
    Насчет применения в коммерческих целях не уверен, но как проект для демонстрации возможностей и эксперимента очень крут.

  • +4
    Нет ничего глупее, чем тратить свою жизнь на изобретение велосипедов и думать что ты самый умный. Людские ресурсы намного более важны сейчас. И лишь несколько процентов организаций могут похвастаться какими-то супер оптимизациями за счет своих денег/людских ресурсов, когда они уже достигли успеха, большинство лишь используют тонны чужого кода и правильно делают, иначе они были бы трупами в бизнесе. PS. Пишу на PHP, Java, C#, ранее делал игры под Z80 игры имея 8kb видео памяти и 64 кб вообще в системе!
  • +13

    Всем привет. Извините насчет плохого Русского языка. Некоторые товарищи отредактировали и прислали исправления. Постараюсь все исправить как можно быстрее.

    • +14

      Вот, кажется все отредактировано хотя бы грамматически. Наверное некоторые предложения все-таки звучат не по русски, но я здесь ничего не могу сделать — Русский я учил в школе, примерно 35 лет назад. Читаю много, понимаю все, но падежи для меня очень сильное колдунство :D (их в Болгарском языке нет).


      Большое спасибо: gearbox и Protonicus! Ребята, вы мне помогли очень сильно!

  • +6
    Так как ассемблер я знаю, то больше всего затруднения во время работы вызвало незнание веб протоколов. Пришлось читать RFC документы насчет SMTP и FastCGI.


    Имхо, это одна из самых больших проблем такой разработки. На «обычном» языке оно ж как — понадобился, например, smtp — подключил библиотеку и погнал. Надо сокеты? Без проблем. Надо изображения обрабатывать (сжатие, обрезка, ит.д.)? Да в 4 строчки. Надо архивы паковать? Да легко. А на асме для этого надо строить свои велосипеды, которые, к тому же, смогут ездить только по определённой дороге. А потом даже для использования уже готовой библиотеки — городить 3 экрана кода. Всё вылизать, вычистить, радоваться точному управлению регистрами, и… понять что жёсткий диск сервера всё равно не позволяет сделать такую-то операцию быстрее чем обычный язык. Или понять что бд до лампочки какой там ассемблер к ней достучался.
    • 0
      Надо сокеты? Без проблем. Надо изображения обрабатывать (сжатие, обрезка, ит.д.)? Да в 4 строчки. Надо архивы паковать? Да легко

      Так никто не мешает прикрутить библиотеку на том же Си. Это ж спортивный интерес у автора.
  • 0

    А меня заинтересовали параметры хостинга. Такого ада я ещё не видел, чтобы было ограничение на потребление процессорного времени, да ещё посуточно + ограничение на процессы, но при этом можно запускать свой бинарный код, т.е. не PHP/MySQL-only. Как я понял, хостится ваше приложение на https://www.superhosting.bg (судя по IP), но похожего плана у них не видно. Просто интересно, сколько такое может стоить.


    По теме: если кого-нибудь интересует веб-разработка на сравнительно низкоуровневых языках, могу посоветовать взглянуть на Wt — приятный виджетоориентированный фреймворк на C++, fullstack. На хабре немного было про него, но довольно старое всё. Я переписал один небольшой проект «для своих» с Java на Wt, сэкономил кучу памяти, т.к. на VDS её всего 1 Гб. Сейчас ест примерно 10 Мб, не течёт.


    Понятно, что какие-то личные проекты можно писать на чём угодно, в том числе и на ассемблере, но в современном мире ценится не потребление памяти или скорость работы, а поддерживаемость продукта, т.к. человеческое время ценится на порядки дороже машинного. Этим можно быть недовольным, но остаётся лишь смириться.

    • 0

      Я на Wt делал CloudBerry Backup for NAS. На мой взгляд Wt оправдан в двух случаях:


      1. вы мало что знаете про html, js, css;
      2. нужно цепляться к C++ коду.
      • 0

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


        Wt вряд ли подойдёт для крупномасштабных приложений, в частности, потому что почти любое действие на клиенте вызывает запрос к серверу. Отзывчивость приложения напрямую зависит от пинга до сервера. Но для embedded это то, что доктор прописал. Компактно, быстро, а если располагается в локалке, то пинг можно считать близким к нулю. Но в целом, фреймворк любопытный и стоит того, чтобы его хотя б потыкать.

        • 0
          Я в основном пишу веб-приложения, т.е. не сайты, а именно аналог десктопа, но в вебе.

          Именно этим я занимался в CloudBerry Lab. Делал веб интерфейс к десктопному продукту.


          Там чем меньше знаешь и используешь вышеперечисленное, тем лучше.

          Не получается. Приходит начальство, приносит крутой дизайн интерфейса на картинке и ставит задачу сделать. В таких ситуациях прибегал к помощи front end разработчиков, которые верстали html/css страницу, которую потом шаблонизировал через WTemplate.

          • 0

            Ну, зависит от конторы. У нас нет фронтэндщиков, дизайнеров, верстальщиков, пишем программы вдвоём. Главный критерий — чтобы выполняло поставленную задачу (преимущественно учёт всех сортов, иногда задачи типа хелпдеска или системы оповещения населения). Дизайна из бутстрапа более чем хватает. Конечно, если делать на продажу и вообще на экспорт, всё сложнее, и с таким мне пока сталкиваться не доводилось.

          • 0
            Именно этим я занимался в CloudBerry Lab. Делал веб интерфейс к десктопному продукту.

            Забавно. Когда мы выбирали изначальное имя для одного своего веб-клиента для десктопного приложения, тоже назвали его Cloudberry, независимо от вашего проекта. Потом поменяли, чтобы не было путаницы. А название какое-то… витающее в воздухе, видимо.
    • 0
      А меня заинтересовали параметры хостинга.

      Это план "СуперСтарт". Официально 6.75лв в месяц (3.4€). Я плачу несколько меньше (2.5€) потому что покупая когда есть "акция".

      • 0

        Спасибо. Но это действительно неоправданные ограничения какие-то (если было бы 5€ в год, тогда ещё можно понять), за эти деньги можно взять полноценную VDS без лимитов на процессы и время. Я сам покупаю у LeaseWeb, там 4.95€. У OVH можно взять за 2.99€, да, чуть дороже, но зато свой сервер для чего угодно. Я к тому, что ассемблер для сайта был выбран всё же не только потому, что это было интересно, но и для того, чтобы вписаться в отведённые ресурсы. Сейчас можно примерно за те же деньги получить сервер с намного более хорошими характеристиками и ни в чём себе не отказывать.

        • 0
          У scaleway тариф получше за те же 2,99€.
          • 0
            Да у тех же ruvds меньше доллара в месяц.
            • 0
              А теперь характеристики сравните.
              • 0
                Я не знаю, что там за vps SuperStart - на сайте не увидел, увидел такое название только в разделе шаред-хостинга. У ruvds по сравнению с самым простым vps из этого хостера спеки конечно пониже - 1 ядро, 512 оперативки и всего 10 гб диска, но он и стоит более чем в три раза меньше, и безо всяких ограничений. Хотя на просторах можно, конечно, найти записи о том, что они выключают слишком активных пользователей - меня пока не затрагивало.
                • 0
                  Я не знаю, что там за vps SuperStart - на сайте не увидел, увидел такое название только в

                  Так, у меня не VPS, а именно SuperStart shared hosting.

                  • 0
                    Дорого как-то, на мой взгляд.
                    • 0

                      Я могу себе его позволит. Компания отечественная. Поддержка на Болгарском.

                      • 0
                        https://www.vps.ag/ вот 2€ — 1ГБ оперативы, 10ГБ места, сервера в Болгарии.
                • 0
                  Ну я в сравнении с scaleway имел ввиду.
                  Так-то если поискать всякие «секретные» тарифы у хостингов то можно найти за 10-15$ в год впску, правда памяти там будет 512 и вроде 5ГБ диска.
                  • 0
                    Там, конечно, всё красиво, ну разве что кроме arm на самом дешёвом тарифе. Но для меня, например, важнее дешевизна, и в итоге самое дешёвое, что я нашёл - это ruvds. Причём, мне достаточно понравилась работа техподдержки у них. Если знаете дешевле, подскажите )
                    • 0
                      Там есть на x86 за 3€. ARM там на голом железе без всякой виртуализации.
                      Ну да, за 65р в месяц найти альтернативу сложно. Я у eomy.net секретный тариф за такую стоимость видел. Но у time4vps.eu есть тарифы за 0,99€ за пол года или 0,66€ за год, в чём-то даже лучше чем у ruvds.
  • 0

    Проект впечатляет, хотя скорее тем, что целиком на асме, а не скоростью работы.
    Непонятно почему выбран SQLite, а не PostreSQL или MySQL. Очевидно же, что SQLite — далеко не самая быстрая СУБД.
    Кроме того заметил, что поиск тредов по тегу сильно проседает: ~ 20 мс против ~ 7 мс на показ списка всех тредов. Проверьте индексы в таблице пересечения (ThreadTags), думаю, добавление индекса по Tag улучшит ситуацию.

    • –1

      PostgreSQL и MySQL иногда трудно использовать на виртуальном хостинге. А так, все файлы находятся в одном месте.


      И не так медленна SQLite как принято считать. Когда все настроено правильно (WAL, работает очень шустро.


      Производительность на демо сервере сравнивать не очень удобно. Там у провайдера есть какое-то распределение ресурсов и иногда все начинает работать 2..3 раза медленнее. Конечно, вполне возможно, что некоторые индексы надо добавить и/или исправить.

      • 0
        PostgreSQL и MySQL иногда трудно использовать на виртуальном хостинге.

        Это наверно большая редкость… Хоть я уже лет 7 вирутальным хостингом не пользуюсь, но не помню, чтобы с этим хоть раз были проблемы… Неужели за предыдущие 7 лет ситуация с виртуальным хостингом так ухудшилась?


        Производительность на демо сервере сравнивать не очень удобно. Там у провайдера есть какое-то распределение ресурсов и иногда все начинает работать 2..3 раза медленнее.

        Не, дело не в этом. Да, иногда по тегу и больше 100 мс ответ занимает, но чаще всего попадает в диапазон 20-30 мс и тут явно есть performance-bug.


        P.S. Ещё на порядок сортировки тредов обратите внимание: image

        • 0
          P.S. Ещё на порядок сортировки тредов обратите внимание:

          Первые 3 завинчены шурупом наверх. ;)

          • 0
            Их бы тогда как-то выделить, а то нипанятнаааа.
          • 0

            Ok, шляпка шурупчика не особо привлекает внимание.

      • +2

        Найти хостинг без mysql это надо постараться.

        • –1

          Нет, MySQL у меня есть. Только там свои лимиты и на CPU и на количество запросов. Я точно не считал, но если AsmBB был на MySQL, то в результате хабра-еффекта, лимит был бы уже достигнут.

  • –1
    А чем хуже разрабатывать в компилируемых языках, например в тех же ASP.Net или Java?
    • –1
      И давно эти языки стали компилируемыми?
      • –2
        От тех кто минусует — с нетерпением жду загрузчик ос на Java или .NET. Ну компилируемые же языки, да?
        • +1
          Это терминологический спор, скучный как не знаю что. Компилятор — по определению это транслятор в машинный код. Если мы считаем байт-код джавовской ВМ машинным кодом, то транслятор джавы — вполне себе компилятор.
          • –3
            А если мы считаем таракана птицей, то что?
            Сочтут идиотом

            Поскольку дальше есть этап компиляции Java байт кода в машинный — то еще терпимо. Но есть и интерпретаторы байт кода (другого, не JVM), которые медленные как все прочие интерпретаторы.
            • 0
              А если мы считаем таракана птицей, то что?
              Сочтут идиотом

              Нет, это корректное допущение. У нас гипотетически может быть «железный» процессор, работающий с байт-кодом. Если у вас есть виртуальная машина, скажем, bochs или что-то аналогичное, работающее с x86 кодом, который является продуктом компилтора gcc, вы же не будете говорить, что мы имеем дело не с компиляцией, поскольку код исполняется виртуальной машиной.

              Но есть и интерпретаторы байт кода (другого, не JVM), которые медленные как все прочие интерпретаторы.

              И что? Машинный код многих процессоров тоже интерпретируется.
              • –1
                AFAIK bochs интерпретирует чужой машинный код, потому очень медленный.

                Но речь идет о конкретной платформе, на которой JVM не родной код, так что не надо заниматься софистикой.

                Железный Java-процессор кстати, уже был, еще и не один
                • +1
                  AFAIK bochs интерпретирует чужой машинный код, потому очень медленный.

                  Замечательно. Значит то, что некий машинный код — интерпретируется, не делает транслятор в этот код не-компилятором?

                  Железный Java-процессор кстати, уже был, еще и не оди

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

                  Но речь идет о конкретной платформе, на которой JVM не родной код, так что не надо заниматься софистикой.

                  Не додумывайте условий про «заданную платформу». Компилируемость не определяется «конкретной платформой», иначе у нас не было бы кросс-компиляторов.
                  • +1
                    Напоминаю, что эта ветка началась с утверждения
                    А чем хуже разрабатывать в компилируемых языках, например в тех же ASP.Net или Java?
                    И нет платформ, ну кроме музея, где байт код JVM был бы родным для процессора.

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

                    Мне надоело.

                    Про кросс-компиляторы — в учебник.
                    • +4
                      И в Java и в C# есть компиляторы в машинный код, так что это языки могут быть и компилируемыми и интерпретируемыми (и вообще, эти языки — в первую очередь спецификации и могут быть реализованы хоть на механических «компах», см. компьютеры из костяшек домино).
                      • –1
                        И где там .NET?

                        Про экселсиор я забыл, но там ценник…
                        • +1
                          И где там .NET?

                          По С# не специалист, но вроде технология NET Native, описана в MSDN

                          Про экселсиор я забыл, но там ценник…

                          Это уже совсем другой вопрос. Технологии есть, а бесплатно или нет — не принципиально. Тот же Delphi никогда не был полностью бесллатен (не в курсе что сейчас с оплатой .Net студии, когда с ней работал она тоже стоило прилично для нашей фирмы).
                          • 0
                            Для .Net есть бесплатный VS Community (хотя там вроде нельзя коммерческие приложения больше одного разработчика писать), еще есть райдер (пока что без ограничений). Подписка группы разработчиков сравнительно дешевая (по крайней мере относительно зарплат этих самых разработчиков).

                            Так что пробовать можно бесплатно, разрабатывать — ну чуть-чуть придется работодателю заплатить, но тут уже речь идет о нескольких процентах с ЗП разработчика.
                            • +1
                              Community можно писать впятером и если оборот компании за год меньше миллиона, что ль, баксов.
                        • 0
                    • +1
                      Потому есть различие — нативный код — не нативный код.

                      Такое различие есть, но оно мало отношения имеет к компиляции.
                    • 0
                      И нет платформ, ну кроме музея, где байт код JVM был бы родным для процессора.

                      Байт код — родной для виртуальной машины JVM. Ваши требования «нативности» — волюнтаризм, к градации «компиляция-не компиляция» не имеют отношения.

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

                      Упор на производительность — это демагогия, см. пример с компиляцией и Bochs. Компилируемый язык или нет — не зависит от того, нативный ли код на выходе. Если вы, условно, транслируете программу на платформе Win32 / x86 под Linux/Itanium, то вы выполняете компиляцию, хоть тресни. Кросс-компиляцию, но тем не менее.

                      Мне надоело.
                      Про кросс-компиляторы — в учебник.

                      Для начала разберитесь в определениях, которые отличаются от ваших хотелок, потом вернемся к разговору.
                      • 0
                        >Байт код — родной для виртуальной машины JVM.
                        Тогда интерпретируемых языков нет — поскольку любой текст программы является родным кодом для её интерпретатора.
                        • 0
                          1) В таком случае двоичный код x86 запушенный в эмуляторе — Bochs — это не скомпилированная программа, ведь она исполняется эмулятором.
                          Тут надо разделить эмулятор машины и интерпретатор языка. Что bochs, что JVM — эмуляторы машин, кмк.
                          2)железные JVM
                          • 0
                            Забейте, мужики. Со времен книги дракона многое поменялось. Бинарник вида байт-код + интерпретатор является исполнимым, опкоды на процессорах транслируются в микрокоманды, LLVM можно настроить как на компиляцию в бинарники так и на транспайлинг в другие ЯВУ. Нет четкой границы, мужики, все в тумане.
                            • 0
                              Поэтому я с самого-самого начала сказал, что «это скучный терминологический спор». Потому как не впервой.
                          • 0
                            Не вижу противоречия. Скажем бейсик — исходно был интерпретируемым языком, что не мешает существованию компиляторов. В моём понимании, исполняемый в интерпретаторе код в данном случае интерпретируемый, а если тот же код собрали компилятором — то уже вполне компилированный. Логично же, нет?
                            Java, исполняемая на железном JVM — компилируемая. Удачи в поиске такого сервера. В остальных случаях — нифига.
                            двоичный код x86 запущенный в эмуляторе — да, интерпретируемый. Ну мало ли что он бинарно совпадает с точно таким же компилированным кодом на реальной x86 машине.

                            А, и ещё. Хотя я не признаю java компилируемой (кроме случая железной JVM, да), интерпретируемой (во всяком случае в привычном понимании) — я её пожалуй тоже поостерегусь называть. Благодаря JIT она является чем-то средним.
                            • 0
                              JIT уж точно внутренняя оптимизация, к самому языку мало отношения имеющая.
                            • 0
                              В моём понимании, исполняемый в интерпретаторе код в данном случае интерпретируемый, а если тот же код собрали компилятором — то уже вполне компилированный. Логично же, нет?

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

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

                              Он интерпретируется, но он скомпилирован.
                            • 0
                              Не вижу противоречия. Скажем бейсик — исходно был интерпретируемым языком, что не мешает существованию компиляторов. В моём понимании, исполняемый в интерпретаторе код в данном случае интерпретируемый

                              Поясню еще.
                              У нас на работе используется свой внутренний скриптовый язык в одном из продуктов. Так вот, в языке есть конструкция вида [] которая перед интерпретацией строки подставляет/вычисляет значение something и замещает квадратные скобки им.
                              Например:

                              set %b := 1

                              loop
                              set %a := arr[%b]
                              set %b := %b + 1
                              while…
                              что эквивалентно:
                              %a := arr1

                              %a := arr2

                              и так далее по ходу исполнения.

                              Вот это — интерпретируемый язык, потому что данную конструкцию невозможно скомпилировать — строка кода изменяется во время выполнения программы, эту конструкцию можно только интерпретировать. Данный язык — интерпретируемый потому что он в принципе некомпилируем.
                      • 0
                        Предлагаю изучить что такое транслятор, и особенно задавшему исходный вопрос.

                        И прекратить заниматься демагогией.
                        • 0
                          Предлагаю кое-кому посмотреть определение, например, по ГОСТу на ЕСПД, а не википедии.
              • 0
                У нас гипотетически может быть «железный» процессор, работающий с байт-кодом.

                Не гипотетически, а вполне реально у нас может быть процессор, выполняющий байт-код Java «в железе» — например:
                Но с тех пор технологии JIT-компиляции развились настолько, что аппаратные реализации JVM утратили практическую ценность.
                • 0
                  Да на здоровье. Это никак не отменяет компилируемости Java.
        • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Поясните мне, может я некоторые тонкости «компиляций» не знаю.

        Вот допустим есть проект на C#, я в VS нажимаю «Build» — получаю на выходе EXE файл, который могу запустить. Это не компиляция?

        Допустим есть проект на ASP.Net, я в VS нажимаю «Publish» — получаю на сервере DLL файл. Это не компиляция?
        • +1
          Компиляция. Но внутри твоих бинарников — не нативный процессорный код, а байт код для .net виртуальной машины.
        • –1
          Вы простите великодушно, но доказательство убогое.
          Давайте проверим — в случае php я на выходе получаю PHP файл, который могу запустить. Это теперь тоже компилируемый язык? А почему нет? Три буковки не те? А вот в проекте под линукс я получаю на выходе файл без EXE и без DLL — значит он уже интерпретиреумый, да? Ну нет же расширения.
          На самом деле, правильно выше написал MacIn — это терминологический спор. Я не считаю, что превращение код для виртуальной машины — это компиляция. Именно потому, что машина виртуальная. Если бы речь шла о некоем реальном процессоре, выполняющем байткот — тогда да, я бы согласился, что это таки компиляция. Поясню на примере, почему я так считаю — если мы запускаем виндовый запускаемый файл под линуксом через wine — он не становится нативным приложением, ведь так? Хотя и выполняется под линуксом. Значит разница в том, что в этом случае имеет место виртуальная среда исполнения. Так и в случае с java и .net — это можно назвать «виртуальной компиляцией». Напомню, что виртуальный — значит «Возможный; условный, кажущийся». Кажется, что это компиляция. Но на самом деле нет.
          • +1
            Так и в случае с java и .net — это можно назвать «виртуальной компиляцией». Напомню, что виртуальный — значит «Возможный; условный, кажущийся». Кажется, что это компиляция. Но на самом деле нет.

            Выше уже несколько раз сказано, что есть компиляторы в машинный код с этих языков. Есть и вполне реальные существующие процессоры (и их можно купить и использовать) для байткода Java. Java это только спецификация, а JVM может быть на любых принципах…
          • 0
            если мы запускаем виндовый запускаемый файл под линуксом через wine — он не становится нативным приложением, ведь так?

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


            Кстати, сама ОС может быть виртуализирована. Вы же не говорите, что от этого все приложения в ней стали не нативными? А они могут все исполняться в режиме эмуляции, на виртуальной машине эмулирующей требуемый процессор.


            Более того, тот же .Net в нормальных случаях не предполагает исполнения в режиме эмуляции, весь код исполняется нативно.


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

            • –1
              Ок, значит можно не заморачиваться с кросплатформенностью, раз все мои приложения и так нативно исполняются на линукс. Спасибо.
          • +1
            То есть получается, программы на С скомпилированные под конкретное ядро на Линуксе — тоже не компиляция? Т.к. на другом ядре скорее всего не заработают, и уж тем более на другой ОС. И все остальные «компиляторы» — тоже на самом деле не компиляторы, т.к. не обеспечивают полную кроссплатформенность?
            • 0
              Скомпилированные программы не обязаны быть независимы от стороннего софта. Но они отличаются тем, что могут быть независимыми. На Си — можно написать под голое железо программу, которая будет загружаться и стартовать без всякой ОС. В этом и отличие. Хотя, как уже не раз тут отмечали — в случае аппаратной реализации java-машины java таки будет являться компилируемой. Но на другом железе — извините, нет.
          • 0
            Компиляция — трансляция программы, составленной на исходном языке высокого уровня, в эквивалентную программу на низкоуровневом языке, близком машинному коду (абсолютный код, объектный модуль, иногда на язык ассемблера).

            Компилировать — проводить трансляцию машинной программы с предметно-ориентированного языка на машинно-ориентированный язык.

            Compile — составлять, собирать.
            • +1
              Тут главный вопрос — что считать машинно-ориентированным языком.
              Вот например если мы интерпретатор бейсика назовём «виртуальная машина бейсик», ну и заодно превратим все команды — в последовательность байт, а не ascii-представление (а на zx-spectrum кстати так и было, там для каждой команды был один байт), бейсик станет компилируемым языком? Ну а что, машина есть — интерпретатор. машинно-ориентированный язык есть. Ну подумаешь команды вычитываются и превращаются в реально-исполняемый код по одной, мелочи какие.
              • +3
                подкину дровишек — на x86 все команды внутрях транслируются в uops-ы, так что если компилятор в них не компиляет — то незачет.
                • +1
                  тонко)
              • +2
                Вообще да. Именно с тех времён разделение языков на компилируемые и интерпретируемые всё меньше имеет смысла — это особенности реализации транслятора и среды исполнения. Гораздо больше имеет значение типизация: статическая или динамическая (некоторые даже путают статическую типизацию с компилируемостью, а динамическую — с интерпретируемостью), строгая или слабая. А сейчас с JIT для интерпретаторов и виртуальных машин для компиляторов — ещё меньше. Особенно если вспоминать про интерпретацию машинных кодов на аппаратном уровне в последовательности элементарных операций, которая была уже сильно развита на том же Z80 по сравнению с i8080, где она тоже присутствовала в командах типа CD 03 F8 :), осуществляющей минимум три элементарных операции (копирование IP в память по адресу из SP, уменьшение SP, копирование операнда в IP).
              • 0
                бейсик станет компилируемым языком

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

    А так получается что статья — «я написал форум на ассемблере — вот он»
    • 0
      Почему легко и приятно — можно понять, посмотрев код автора. Он написал ряд библиотек и многие задачи вырождаются просто в вызов по шаблону функций одну за одной. Потому и легко — скрывается абстракцией.
      • +6
        Посмею поспорить, но это не легко и приятно. Легко и приятно — это высокоуровневый код в котором есть конструкции типа
        $user = User::getById(42);
        
        $user->setNewPassword('123456')->save(); 
        

        при беглом просмотре такого кода даже программист который не знаком с данным языком сможет интуитивно понять что мы получаем пользователя по айди, меняем ему пароль, и сохраняем. А что лёгкого и понятного в коде типа вот такого? Да ничего. Работа с таким кодом — это лишние человеко-часы которые сейчас ценятся гораздо больше чем железяка, ибо за окном не начало 2000х.
        cmp eax, [.pEnd]
        jae .error_unexpected_end

        stdcall DataCRC32, esi, edx
        bswap eax
        cmp eax, [esi+edx]
        jne .error_checksum
        • –2
          Легко и приятно — это высокоуровневый код в котором есть конструкции типа

          Бесполезное сравнение. Это, на минутку, разные парадигмы. В одном случае мы имеем императивное, в другом — ООП. Сейчас придет какой-нибудь функциональщик и скажет свое «фи» на ваше ООП.

          $user->setNewPassword('123456')->save();

          Это субъективно — спору о конвейере Vs проверке кодов ошибок с последовательным исполнением — множество машинных тиков в обед. Мне, например, наоборот, некомфортна такая запись.

          А что лёгкого и понятного в коде типа вот такого? Да ничего.

          Да всё.
          • +4
            Как может быть понятен код, в котором даже нельзя наименовать переменную так как мне надо (точнее можно, но в том случае если это именно своя переменная а не системный регистр)? И парадигма тут ни при чём. Вот смотрите — как бы там не было, но в моём коде чётко понятно что в $user — очевидно хранятся данные пользователя. И это одна строка кода, урывок из контекста. Теперь берём отрывок асма.
            bswap eax

            откуда мне знать что мы храним в eax в данный момент?

            Или же
            cmp eax, [esi+edx]

            А почему сравниваем это? Что такое esi и edx? Сравните какое-нибудь
            if(user.type == UserTypes.Admin)
            

            с
            cmp eax, [esi+edx]
            Где тут понятность? И ооп тут ни при чём — изменить user.type (ооп, объект) на user[«type»] (массив, более функциональный подход) — менее понятно не станет.
            • –1
              Вы пытаетесь доказать, что писать на асме подобные приложения сложно по сравнению с ЯВУ. Это бесполезная борьба с ветряными мельницами. Говоря об удобстве, имеется в виду, что «все не так плохо, как казалось», не более. ИМХО.

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

              Да элементарно: область видимости сокращается, парой строк выше можно увидеть, что именно задается в esi или какой там регистр использовался. Ну, будет у вас вместо
              if(abc* ==…

              mov esi, abc

              cmp [esi],…

              И парадигма тут ни при чём. Вот смотрите — как бы там не было, но в моём коде чётко понятно что в $user — очевидно хранятся данные пользователя. И это одна строка кода, урывок из контекста.

              Ну так и что-то вроде
              mov esi, user
              mov eax, [esi+_user.name]
              не бог весть какая сложность.

              Теперь берём отрывок асма.
              bswap eax
              откуда мне знать что мы храним в eax в данный момент