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

Конечно, многие скажут, что это ни-ни и писать для веба нужно только на 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 минут процессорного времени.


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


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


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


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


Заключение


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


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


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

Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 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 пишут как правильно большие и сложные системы, так что если оно тормозит, возможно, на другом языке оно тормозило бы ещё сильнее (хоть и не факт, т.к. см. выше).

                                    • +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
                                                                                                        Если язык разработки будет статически и строго типизированным и компилируемым, то значительная часть вшивых правок приведет к нормальн