Конечно, многие скажут, что это ни-ни и писать для веба нужно только на PHP, ну или на один из модерных языках Питон, Руби, Node.js и т.д.
Но дело в том, что написание сайтов на ассемблере очень полезно, а с подходящими инструментами — легко и приятно.
Вообще-то, это утверждение было лишь гипотезой. Чтобы доказать или отвергнуть ее, этой весной я занялся писать форум на ассемблере.
Раньше у меня уже было веб-приложение на ассемблере — CMS для малого сайта. Только оно работает в режиме "один пишет, многие читают". При том, использует CGI интерфейс и поэтому "многие" читать одновременно тоже не получается.
Техзадание
И так я решил написать веб-приложение, чтобы:
- Соблюдался принцип «много читают — много пишут».
- Работало очень быстро и не загружало сервер.
- Использовало очень мало памяти, опять чтобы не загружать сервер.
- Работало на дешевом виртуальном хостинге.
Всем этим условиям отвечает именно веб-форум. Поэтому выбор остановился на нем. Задание выглядит так:
Написать веб-форум, который:
- Использует интерфейс FastCGI, чтобы обслуживать заявки быстрее чем CGI и чтобы не было ограничения на число одновременно исполняющихся процессов на сервере (у моего хостинг плана есть такое ограничение в
6030 процессов). - Использует транзакционную базу данных, чтобы хранить информацию в одном месте и чтобы можно было нескольких посетителей писать одновременно.
- Функциональность должна быть достаточной чтобы использовать продукт в реальной жизни для общения пользователей.
- Вид форума было можно полностью менять из конфигурации. Скины — наше все. Да и не каждый может редактировать код на ассемблере.
Кроме 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). Ограничения таковы (согласно спецификации):
- Одноядерное CPU
- 1GB RAM
- 30 минут процессорного времени в сутки.
- Максимальное количество работающих процессов — 60.
Slashdot эффект тест.
В Августе совершенно случайно удалось протестировать систему на нагрузке в реальном режиме. Некто (так и не понял кто) опубликовал в Твиттер ссылку на хранилище кода. Сразу несколько десятков перепостили ссылку, а потом опубликовали ее и в reddit и наверное в других социальных сетях.
К большому моему сожалению, ссылка была на хранилище кода. А оно работает на CGI (fossil) и совершенно не держит нагрузки.
В течение суток форум посетили несколько тысяч посетителей — около 8000 на хранилище кода, которое счастливо падало и вставало (из-за превышения лимита процессов).
Но некоторое количество посетителей (около 3000) все-таки попали на форум и сделали более 30000 заявок.
Форум совершенно не почувствовал нагрузку и все время исправно работал без замедления или потери заявок. В эти сутки использовано около 7 минут процессорного времени.
Вердикт гипотезы
Я считаю, что всем этим гипотеза сформулированная в начале моего рассказа, была доказана.
Веб программирование на ассемблере возможно, не очень сложно, а результаты получаются весьма хорошие. В результате, такая работа весьма повышает общую культуру разработчика и позволяет ему получит глубокое понимание протоколов Интернет и как все работает на самом деле.
Использование веб программы на ассемблере может сэкономить на хостинге и позволит использовать дешевый виртуальный хостинг там, где другие используют выделенные серверы и другие дорогие решения.
Заключение
Ну, вот и все. Если кому понравилось, используйте на здоровье. Всякие тесты на уязвимость и производительность весьма приветствуются. Новый код и исправления багов принимаются. Новые хорошие скины тоже весьма нужны.
И в конце некоторые ссылки:
» Хранилище кода проекта
» Демо инсталляция
» Как качать и инсталлировать
» Как зарегистрироваться без почты
Комментарии (427)
kAIST
02.01.2017 21:36+11С одной стороны интересно, эдакая потивоположность современным языкам с тонной фреймворков и детяском уровней абстракций.
Но с другой стороны, плюсов никаких. С точки зрения производительности, разницы особо думаю не будет — 99% у тебя займёт шаблонизатор и база данных, или 95%.
Jogger
02.01.2017 22:44+4Без тестов я не стал бы утверждать что разницы не будет. Беда в том, что непонятно, с чем сравнивать — в зависимости от движка форума результат будет разным. Но я бы напротив, ожидал ускорения на порядок.
Беда в другом. Никому не нужен хороший и оптимизированный софт. Стоит взглянуть на любой продукт крупных компаний — это становится ясно. Важна скорость и стоимость разработки. Ассемблер при всей любви к нему не может похвастаться хорошими показателями в этих категориях. Увы, так устроено наше общество.igorch96
03.01.2017 00:41+1Ну при налачии библиотек на ассемблере и написание сайта может достоточно быстро получиться. Но вот что делать с переносимостью между процессорами и их разрядностью? Не проще ли использовать язык C? Так, хотя бы, можно будет быстро перекомпилировать сайт под новую среду.
Randl
03.01.2017 01:49+9Никому не нужен хороший и оптимизированный софт.
Дело в том, что 95% на С и 5% критичного кода на асме покажет результаты не хуже практически на любой задаче. Чистый асм не нужен
VioletGiraffe
03.01.2017 10:44+3У меня есть сильное подозрение, что если критичный код написать на С так же, как писали бы на асме, то выйдет быстрее, чем на асме руками.
Randl
03.01.2017 11:04Не всегда. Под "5% критичного кода на асме" я подразумеваю "используя при необходимости асм в 5% критичного кода"
VioletGiraffe
03.01.2017 11:08Я понимаю, но ещё не видел, чтобы ручной асм был быстрее правильно написанного С, оптимизированного компилятором.
old_bear
03.01.2017 13:53+4Я видел. Неоднократно.
Я его сам пишу, собственно.
Но это безусловно не во всех случаях так.
P.S. Заранее извиняюсь, но приводить примеры мне лень. В основном это simd-ы и/или упихивание алгоритма в доступные регистры общего назначения.
Randl
03.01.2017 14:10ffmpeg вроде как классический пример, там прилично асма, и не думаю что просто так
0xd34df00d
10.01.2017 19:49Сам писал, правда, не асм, а SSE/AVX-интринсики, но это ближе к асму, чем к кроссплатформенному С.
Надо бы про это статеечку наваять, кстати.
VioletGiraffe
10.01.2017 19:52Справедливости ради, это и я писал, но интринсики — это, всё-таки, не ассемблер.
il--ya
03.01.2017 16:03Чистый асм не нужен
А здесь, кстати, и нет чистого асм-а. Большая часть кода (и по объёму — автор это упоминает, и по ресурсу процессора, я уверен) — отжирает SQLite, который написан на C.
kAIST
03.01.2017 01:54+4Перед fcgi еще работает apache, плюс движек базы данных, так что разница в производительности на порядок, вряд ли.
0xd34df00d
03.01.2017 02:05+3Надо просто и сервер написать на асме. И БД.
И файловую систему поверх сырого block device, на всякий случай.
TheDeadOne
03.01.2017 08:14+20Ага, что не начни писать на асме, в конце всё равно получается операционная система.
Light_Metal
03.01.2017 11:40Kolibri в роли серверной ОС еще никто не пробовал?
А Веб-сервер на ассемблере на Хабре уже писали, да
Ждем еще до кучи реализацию БД на асме )
Siemargl
03.01.2017 18:54Колибри на роль серверной ОС не годится. Нет многопроцессорности и многопоточности.
johnfound
03.01.2017 14:15А сервер уже есть: RWASA.
Весь flatassembler.net работает на нем.
Там у меня сайт тоже на ассемблере: https://fresh.flatassembler.net
Правда, там MiniMagAsm работает.yesasha
03.01.2017 20:59+2А мы с вами даже знакомы. На том самом форуме обсуждали написание веб сервера. Но потом я «скатился» до node.js
OnYourLips
03.01.2017 10:23+8А я буду утверждать, что будет медленнее, чем даже на Java.
Оптимизация компилятора, использование неоптимальных алгоритмов на асме из-за того, что они проще, игнорирование сложных особенностей при написании своего велосипеда — всё это делает код на асме медленнее.
Однако в итоге асм будет медленнее на величину, которая меньше погрешности измерения. Основное время программы будет ожиданием ответа от СУБД и подобных сервисов.Jogger
03.01.2017 15:20+5Я не видел пока что ничего, что было бы медленнее чем на Java. Не холивара ради, просто наблюдение.
OnYourLips
03.01.2017 15:52Могу подсказать.
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.htmlgearbox
03.01.2017 16:03+2с трудом верится что бы нода или седьмой пых были медленнее явы. Можно взглянуть на тесты — как и что меряли?
igouy
03.01.2017 21:01https://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=4gearbox
03.01.2017 22:14+2— один тест
— лютая синтетика
— transliterated from Mike Pall's Lua program — то есть с LUA перевели на javascript и php (что характерно, для java код писали ручками)
— var вместо let или const
— for вместо forEach, map и прочего
Нормальный тест, чо.rkfg
04.01.2017 01:53Тестов там много для разных языков. Не для всех выведены ссылки, но минимальная смекалка приводит к сравнению PHP против Java. Тесты могут быть не идеальны, и не стоит делать поспешных выводов. Если есть идеи, как переписать тест, чтобы он стал эффективнее и переиграл другие языки, можно прислать свой вариант.
Сайт не претендует на истину в последней инстанции, но позволяет неплохо прикинуть потенциал производительности по CPU и RAM для популярных языков на вполне практических, пусть и не повседневных задачах. А так никто не спорит, что без конкретного приложения, по которому неоднократно прошлись профайлером, абстрактные споры смысла не имеют.
SVGen
08.01.2017 16:19Если что, в
V8letиconstсейчас медленней, чемvar: https://youtu.be/BstzvS2xd5U?t=1166
АforEachмедленнейfor: https://twitter.com/jsunderhood/status/585372287077081089
rkfg
03.01.2017 15:55Это обычно сочетание множества факторов, но конкретно Java и JVM там ближе к концу списка. Вот неэффективные фреймворки, да ещё и неправильно и неуместно применённые, ORM с избыточными выборками и N+1 problem, неэффективные модели данных, просто индусский код — это да. Сам пишу на ней, родимой, уже пять лет, и всё это знаю не понаслышке. Ещё на Java пишут как правильно большие и сложные системы, так что если оно тормозит, возможно, на другом языке оно тормозило бы ещё сильнее (хоть и не факт, т.к. см. выше).
DarthVictor
04.01.2017 03:22Вот по веб-фреймворкам
http://www.techempower.com/benchmarks/#section=data-r13&hw=ph&test=query
Source
03.01.2017 13:56+2Движки форумов тоже разные по степени навороченности бывают. Если честно сравнивать, то затраты на SQL будут одинаковые. А дальше идет разница: время ответа HTTP-сервера (не более 0.02 мс везде), шаблонизатор (тут большую часть времени отожрёт Markdown, так что тоже будет примерно одинаково), оверхэд на ORM/QueryBuilder (в данном случае он небольшой, т.к. запросы тривиальные), вспомагательные мидлвары.
Другими словами, я бы не ожидал ускорения за счёт применения ассемблера более, чем на 20-30% при честном сравнении на данном классе задач.Siemargl
03.01.2017 18:29-5Интерпретатор проигрывает маш.коду в 100 раз. Это на 9900%
Можно легко проверить на PyStoneMacIn
03.01.2017 18:40Допустим, машкод выполняется за 10 единиц, интерпретируемый код за 1000 (мы опустим JIT). Накладные расходы при этом — 10000. На этом фоне что 10, что 1000 — все одно.
Siemargl
03.01.2017 20:14-6Допустим, не допустим. Я не пишу «допустим», а интерпретатор питона действительно в 100 раз медленнее С на конкретном тесте, который называется Drystone, а вы говорите «допустим, скорость не всегда нужна».
Это чистой воды ответ «да зелен виноград».
Лучше писать код, который будет работать быстро всегда.
В плане веб серверов есть общие тесты производительности, и там тоже показатели скорости разнятся на порядокMacIn
03.01.2017 20:23+3«Допустим» — это фигруа речи, призванная зафиксировать модель, при помощи которой я пытаюсь донести определенную точку зрения.
Лучше писать код, который будет работать быстро всегда.
Смысл, если это — не бутылочное горлышко?
Это чистой воды ответ «да зелен виноград».
Нет, это чистой воды ответ «экономить на спичках — глупо».
terryP
03.01.2017 20:25+3Во-первых, на одном конкретном тесте, который не без недостатков.
Во-вторых, лучше писать код как можно быстрее и качественнее, так чтобы он укладывался в нужные рамки производительности. Сама по себе абстрактная производительность никому не нужна.
А «код, который будет работать быстро всегда» это какой-нибудь ассемблер с диким количеством ручных оптимизация под конкретное железо. Да он будет работать быстрее всего в том числе Си, делают так? Крайне редко. Тут все упирается в стоимость разработки и сэкономленное железо, если железо дешевле работу программиста — смысла в быстром коде нет никакого.
В-третьих, если производительность кода на производительность системы не влияет — нужен ли быстрый код?Jogger
03.01.2017 21:09>Сама по себе абстрактная производительность никому не нужна.
Это не верно. Она нужна очень много кому, а точнее — всем, кто является конечным пользователем этого кода (в случае бекэнда — владельцу сайта). Другой вопрос, что платить за эту абстрактную производительность никто не готов. Но «экономически не целесообразна» и «не нужна» — всё же разные вещи.terryP
05.01.2017 11:54+2Другой вопрос, что платить за эту абстрактную производительность никто не готов. Но «экономически не целесообразна» и «не нужна» — всё же разные вещи.
Иногда не нужна. При типичном бекэнде веб приложения количество одновременных соединений с серверу ограничено, сервер имеет ограниченную скорость записи/чтения на диск, то есть работа с базой данных, записью файлов не может быть быстрее скорости работы с жестким диском, а канал связи с инетом тоже не безлимитный. Производительность кода на ресурсы сервера для веб бека может не влият практически никак, так как сервер 100% времени будет заниматься записью/чтением с диска, а процы будут загружены на 10-20%. Либо он упрется в трафик или количество открытых соединений. Смысл супер оптимизировать код, если процы и так не работают в полную силу и лимит достигнут совсем в другом?Jogger
05.01.2017 14:22+1Не спорю. Но «иногда не нужна» — это всё же далеко от посыла «никому не нужна», на который я отвечал.
Siemargl
03.01.2017 23:241. На многих тестах, это лишь один пример.
2. Нет понятия «абстрактная производительность». Какую платформу выберешь, такую производительность будешь иметь _всегда_
Дело не в оптимизации, точнее далеко не только в ней. Просто на языках, скажем так, пост-ЯВУ, невинно-выглядящая операция может тянуть сумасшедшие накладки, о которых средний программист, которому нужно «быстрее и качественнее» может не задумываться или даже игнорировать. Когда все пишется руками, контроль выше, как впрочем и цена.
3.Так не бывает в реальности. В одном месте — может и не влияет, а в другом…
tyomitch
04.01.2017 13:51+4Просто на языках, скажем так, пост-ЯВУ, невинно-выглядящая операция может тянуть сумасшедшие накладки, о которых средний программист, которому нужно «быстрее и качественнее» может не задумываться или даже игнорировать. Когда все пишется руками, контроль выше, как впрочем и цена.
Да, это правда. И что отсюда следует?
«на ЯВУ легче написать плохой код, чем на ассемблере» — да, и это правда.
«на ассемблере легче написать хороший код, чем на ЯВУ» — нет, и это неправда.
«на ассемблере легче написать хороший код, чем плохой» — нет, и это неправда.Siemargl
04.01.2017 15:24С третьим я не согласен, как и автор статьи. Внизу есть его пояснения.
Речь идет об структуре и алгоритмах, конечно, а не о количестве ошибок.tyomitch
04.01.2017 15:38+1Речь идет об структуре и алгоритмах, конечно, а не о количестве ошибок.
Т.е. «хороший код» для вас — это «код, доставляющий эстетическое удовлетворение», а не «код, полностью решающий поставленную задачу»?Siemargl
04.01.2017 16:31Красивый код, эффективно выполняющий поставленную задачу.
На самом деле, это связанные вещи.
Source
03.01.2017 22:26-2Интерпретатор проигрывает маш.коду в 100 раз. Это на 9900%
Какая у Вас интересная версия математики… в 100 раз быстрее == на 99% быстрее.
Только причём тут это вообще? Я же написал "на данном классе задач", т.е. рендеринг простеньких HTML-страниц на основании данных, полученных из реляционной СУБД.
Каким боком тут Dhrystone, актуальность которого осталась где-то в 80-х? Или при взгляде на великолепные результаты ассемблера в синтетическом бенчмарке у вас автомагически SQL быстрее работать начинает?Siemargl
03.01.2017 23:15Не умеете считать, беда современного образования. В 2 раза быстрее = на 100% быстрее, в 3 раза быстрее = на 200% быстрее…
Это тест вычислений с плавающей точкой. Весьма актуален в настоящее время, потому что данные операции подешевели и все больше заменяют целочисленные.
Тест устарел, но он легко доступен и легко перепроверяется. Можно взять другие тесты.Source
03.01.2017 23:36-6Не выдумывайте! Считать не умеете Вы… Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.
Можно взять другие тесты.
Можно, только зачем, если в среднестатическом случае (для вышеописанного класса задач) 70% времени всё равно придётся на запросы к БД. Даже если весь остальной код будет выполняться за пару наносекунд, Вы всё равно получите лишь 30% ускорения. Учитывайте матчасть, а не только синтетику.
Siemargl
03.01.2017 23:51ОК. На 9900% медленнее (так и было написано первоначально), так лучше стало?
И давайте представим, что БД тоже написал «эффективный программист», на PHP…Source
04.01.2017 00:47+1Стало лучше. Но, справедливости ради, первоначально речь шла о потенциале ускорения от переписывания на асме. Фиг знает, причём тут потенциал замедления от обратного переписывания и к чему вдруг Вы начали его считать..
И давайте представим, что БД тоже написал «эффективный программист», на PHP…
Вы понимаете смысл оптимизации узких мест? Хранилище данных очень часто оказывается узким местом, именно поэтому в оптимизацию СУБД вложено столько человеко-лет. И несмотря на это когда нужна действительно высокая пропускная способность всё равно приходится отходить от реляционной модели.
Проблема в том, что ассемблер не поможет написать отзывчивый высоконагруженный веб-сервис… вроде и потенциал есть, но по факту граблей больше. И даже отличные знания асма, на уровне автора статьи, не застрахуют Вас от performance-ляпов, как у автора получилось со страницей тредов по тегу (20-30 мс там, где должно быть 7-8 мс). При использовании ЯВУ такие performance-ляпы встречаются реже, т.к. можно сконцентрироваться на оптимизации узких мест, не распыляясь на оптимизацию каждой функции.Siemargl
04.01.2017 01:04+2Согласен. Лучшая оптимизация — алгоритмическая. А лучшие алгоритмы получаются сложными, и их плохо писать на ассемблере.
Но я бы разделил ЯВУ на три класса
— быстрые компилируемые языки, как примеры c++, d, rust, go, даже фортран, паскаль и ада
— байт-машинные с динамической компиляцией jvm, pvm, net
— скриптовые php, js итп
С каждой ступенькой повышается уровень абстракции и понижается производительность.
К сожалению, есть тенденция писать быстро и лениво. А вместо оптимизации, замены фреймворка/языка, заниматься массовой демагогией и пропагандой типа «скорость языка неважна, все равно задержки в другом месте», «это сложно и дорого», «дешевле не стараться, а купить новый сервер»
И в итоге, используется, например Yii, который в 30 раз медленнее топовSource
04.01.2017 01:14С делением ЯВУ на классы я согласен, хотя там можно ещё интерпретаторы с JIT в отдельный класс выделить. А вот с тенденцией не согласен. Наоборот, тенденция писать на скриптовых языках слабеет с каждым годом. Народ активно смотрит в сторону Go, Elixir, Crystal, Nim, Clojure, etc.
Другое дело, что необязательно бросать все существующие наработки на PHP, Ruby, Python и JS. Во многих случаях достаточно выделить узкие места в отдельные сервисы на более быстрых языках, а ненагруженную часть проекта оставить, как есть.
P.S. Мне лично тоже нравится писать быстрый код, но опыт работы показывает, что в первую очередь бизнесу быстро нужен код, а не быстрый код.
johnfound
04.01.2017 01:58-2А лучшие алгоритмы получаются сложными, и их плохо писать на ассемблере.
Нет с этим я не согласен. Сложными они получаются, когда пишут их на ЯВУ. Потому что лучшие алгоритмы, такие, которые ближе к CPU. Нативнее что ли. А таких намного легче писать на ассемблере. На ассемблере они и читаются лучше.
Правда, надо язык знать хоть немного. Но это для каждого языка в силе.
terryP
04.01.2017 11:59+5Ну смотрите, вы делаете сверхбыстрый веб Фреймворк, при этом:
1. Используете базу данных, которая физически не может вытянуть большое количество пользователей и данных,
2. Каждый раз заново парсите markdown, вместо хранения скомпилированного варианта,
3. Имеете непонятные баги перфоманса, когда страница сильно тормозит,
4. Не кешируете html страницы в памяти или диске для ускорения работы,
У меня был сайт с миллионом просмотров в день на старом медленном PHP и хостинге подобном вашему и он не падал, только потому что там большинство запросов кэшировалось и php просто большинству пользователей отдавал готовый html, а запросы на изменения писались сначала в файл, а потом сразу скидывались из файла в таблицу.
Вы же выигрываете копейки на скорости кода проигрываете тысячи на алгоритмах и архитектуре.johnfound
04.01.2017 13:30- Каждый раз заново парсите markdown, вместо хранения скомпилированного варианта,
А сколько времени вы думаете отнимет чтобы сделать эту функцию? Моя оценка — около двух часов. Ничего сложного там нет. Понадобится, сделаю.
А кстати, этим можно протестировать насколько плохо поддерживается ассемблерный код.
Нужен доброволец, который хоть немного знает ассемблер и синтаксис FASM. Даем ему задание, чтобы сделал кеширование компилированного markdown-а и посмотрим сколько времени ему отнимет.
Конечно эму будет нужны намного больше 2-х часов, хотя и потому что понадобиться почитать исходники и ориентироваться в проекте с нуля. Но я считаю, что получится все очень быстро.
michael_vostrikov
04.01.2017 19:40Сделать миграцию, добавить заполнение поля при сохранении модели, заменить название поля при выводе — 10 минут. А может и меньше.
Конечно эму будет нужны намного больше 2-х часов, хотя и потому что понадобиться почитать исходники и ориентироваться в проекте с нуля.
Во-во. На ЯВУ сложность вхождения в проект гораздо ниже.
johnfound
04.01.2017 20:03Во-во. На ЯВУ сложность вхождения в проект гораздо ниже.
Совсем не факт. Это зависит от того насколько программист знает тот язык и фреймворк.
michael_vostrikov
04.01.2017 20:59+5Любой проект зависит от знания языка. Речь не идет об уровне знаний, подразумевается, что знание языка достаточное.
Добавить поле на сайт — это типичная задача за 10-20 баксов на фрилансе. Думаете, там люди незнакомый проект неделями изучают? Да нет, просто берут и делают за пару часов. А у вас пара часов нужна даже на хорошо знакомый проект.
tyomitch
04.01.2017 14:40— байт-машинные с динамической компиляцией jvm, pvm, net
— скриптовые php, js итп
Странное деление, потому что PHP и JS перед выполнением точно так же компилируются в байт-код, как и JVM и .NET.
Скриптовые языки, которые не компилируются перед выполнением — это, например, bash и awk.Siemargl
04.01.2017 15:22Делим так — с компиляцией JIT/AOT и без нее.
Только чтобы действительно был заметен эффект JIT, а не как раньше в Питоне — вроде и JIT, а толку 0
VolCh
05.01.2017 09:34+1Мало того, трансляторы JS уже вовсю используют полноценную компиляцию в нативный код, есть такие трансляторы для PHP, а в референсном трансляторе вовсю идёт работа над ней.
Siemargl
05.01.2017 10:36Да, технологии движутся вперед. Возможно, скоро все будут иметь JIT.
Но это трейдофф за счет памяти, да и динамическая типизация мешает оптимизатору.
Так что обычные компилируемые языки со строгой типизацией будут всегда иметь некоторую фору.tyomitch
05.01.2017 10:58На самом деле нет: у JIT-оптимизатора есть возможность «затачивать» код под фактически используемые пути выполнения, тогда как AOT-компилятор вынужден предугадывать, какие пути выполнения будут чаще использоваться.
Есть примеры, когда код на Java обгоняет аналогичный код на Си, потому что JIT-компилятор заменяет «заглушками» редко используемые ветви условий внутри часто выполняемых процедур, и в результате тело процедуры сокращается по размеру и помещается в кэш целиком.
То же самое и с динамической типизацией: если в некой переменной 99% времени хранится целое число и 1% времени — более сложный объект, то JIT-оптимизатор может сгенерировать эффективный код для работы с целым числом, который при получении объекта бросит исключение, которое виртуальная машина обработает в «медленном режиме». AOT-компилятор, напротив, вынужден при каждом обращении к такой переменной сгенерировать код для обработки всех возможных случаев; так что размер кода сильно разбухнет.Siemargl
05.01.2017 11:31Теоретически да, но вот используются ли такие хинты современными JIT на самом деле?
Собственно, я и сказал «за счет памяти», а не скорости.
Про влияние кэша очень сомневаюсь, что его можно оценить.
Кроме того и современные кэши огромные, и код JITа кусок себе отъест — он же тоже исполняется в этот или близкий момент.tyomitch
05.01.2017 12:31Теоретически да, но вот используются ли такие хинты современными JIT на самом деле?
Естественно.
Кроме того и современные кэши огромные, и код JITа кусок себе отъест — он же тоже исполняется в этот или близкий момент.
Практически всё время выполнения программы приходится на скомпилированный код; иначе бы смысла в JIT-компиляции не было.
Т.е. JIT-движок вытесняется из кэша сразу после очередного этапа компиляции, и уступает кэш скомпилированному коду.
Azoh
04.01.2017 00:39Ускорить на 200% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость.
Source
04.01.2017 01:05-4Правильный вариант Вашего комментария звучит так:
"Ускорить на 66.(6)% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость."
P.S. Любая величина изначально принимается за 100% при расчётах. Допустим, после оптимизации стало в 3 раза быстрее, т.е. (100/3)% от начального значения, значит мы ускорили на (100 — 100/3)%.
GennPen
04.01.2017 01:20Любая величина изначально принимается за 100% при расчётах. Допустим, после оптимизации стало в 3 раза быстрее, т.е. (100/3)% от начального значения, значит мы ускорили на (100 — 100/3)%.
А вы не путаете скорость вычислений и время вычислений?Source
04.01.2017 02:24-3Ничего я не путаю, увеличение скорости вычислений в 3 раза — это и есть сокращение времени вычислений на 67%… И то и то упрощенно называется ускорением.
А если хотите морфологией заняться, то не забывайте, что ускорение — это производная от скорости по времени, удачи в трактовке ;-)GennPen
04.01.2017 02:52увеличение скорости вычислений в 3 раза — это и есть сокращение времени вычислений на 67%
и увеличение операций в единицу времени (скорости вычислений) на 200%Source
04.01.2017 14:03-2И что? Мы измеряем время в рамках бенчмарков, ips — это производная (вычисляемая, а не измеряемая) характеристика. Ускорить алгоритм == сократить время его выполнения. Это общепринятая трактовка.
Другими словами, ускорение на 67% == ips вырос на 200%.
Поймите простую вещь, "рост ips" и "ускорение" — это не синонимы ни разу.
Azoh
04.01.2017 02:11Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.
"автомобиль ускорился на 200%" = "автомобиль увеличил скорость в 3 раза".
"автомобиль замедлился на 200%" = ???
P.S. Изначально производительность была N исполнений в секунду. После оптимизации стала 3N исполнений в секунду. Была 100%. Стала 300%. Изменилась на 200%.
Source
04.01.2017 02:31-5Я понял Вашу отсылку к физическому понятию "скорость", но, к сожалению, как физик, вынужден отметить, что Ваши формулировки безграмотны с точки зрения физики и знак "=" там не уместен, т.к. у слова "ускорение" совершенно иной физический смысл, и ни в процентах, ни в разах оно в физике не измеряется.
godlin
04.01.2017 03:19-1Что-то я перечитывал-перечитывал, но так и не понял, откуда взялось "(100/3)%"…
«x стало в три раза больше» означает «x*3», почему Вы делите-то? О_оSource
04.01.2017 13:55-1Было 100 ms, стало в 3 раза быстрее, т.е. стало 33 мс. Так понятнее?
Слово "ускорился" в контексте быстродействия синоним слова "подешевел".
Функция ускорилась в 2 раза == Функция подешевела в 2 раза == Стала занимать в 2 раза меньше времени.
Функция ускорилась на 50% == Функция подешевела на 50% == Стала занимать на 50% меньше времени.
Аллюзии к слову "скорость" тут совсем не в тему. У меня странное ощущение, от того, что мне приходится разжевывать такую базовую тему на Хабре… Причём эффекта ноль, никто даже не пытается задуматься над неверным пониманием этого аспекта.Jogger
04.01.2017 16:03+1Скорость это в любом случае величина обратно пропорциональная времени.
Функция ускорилась в 2 раза == скорость выполнения функции стала больше в 2 раза == функция стала быстрее на 100% == функция стала занимать на 50% меньше времени. Вы пытаетесь подменять понятия, и говоря о быстродействии но подразумевать скорость. Это такая же ошибка, как говорить что частота измеряется в секундах, хотя задав период в секундах мы однозначно определяем частоту.Source
05.01.2017 01:06Ну, ё-моё, опять 25… Забудьте Вы уже про скорость… Абстрагируйтесь от неё, если морфологическое сходство слов вас так сильно запутывает. Тем более, что такого термина как "скорость выполнения" в принципе нет в бенчмарках.
Бенчмарки меряют время ожидания (latency в секундах) и считают пропускную способность (throughput в ips или в rps).
При этом изменения latency обычно считают в процентах, а изменения throughput — в разах.
Ускорилось на 50% = latency уменьшилось на 50% = throughput вырос в 2 раза = ускорилось в 2 раза.
Вы же пытаетесь ввести какую-то свою терминологию, и не понятно откуда Вы её вообще взяли… Мне прям даже интересно на базе чего Вы так упорствуете… Дайте хоть ссылку на какую-нибудь benchmark-утилиту, которая вашей методологии подсчётов придерживается.GennPen
05.01.2017 02:11Забудьте Вы уже про скорость…
А как тогда производительность процессора измерять: в секундах или гигафлоппс?
Jogger
05.01.2017 06:54-3>>Мне прям даже интересно на базе чего Вы так упорствуете…
На базе знания русского языка и математики. Их, знаете, в младшей школе изучают. Вам пора бы уже их изучить, а то как-то плохо выглядит их полное незнание у взрослого (я надеюсь) человека.
soniq
05.01.2017 15:39А как вы так смешали latency и throughput? Это вообще не связанные два параметра. Общего у них только то, что иногда некоторые приёмы оптимизации влияют сразу на оба параметра, так что один улучшают, а другой ухудшают — и приходится выбирать что важнее.
Jogger
04.01.2017 03:20-1Если стало в 3 раза быстрее — то это 100*3%, а никак не 100/3%. Если скорость 1000 операций в секунду, то ускорение в три раза — это 3000 операций в секунду, а не 333.(3) операции в секунду. Передавайте привет своей учительнице математики в младшей школе, и передайте что она проф. непригодна.
tyomitch
04.01.2017 13:54Это тест вычислений с плавающей точкой. Весьма актуален в настоящее время, потому что данные операции подешевели и все больше заменяют целочисленные.
Вы его с чем-то путаете, потому что это как раз тест целочисленных вычислений.
The Dhrystone benchmark contains no floating point operations, thus the name is a pun on the then-popular Whetstone benchmark for floating point operations.
Весьма актуален в настоящее время, говорите?
michael_vostrikov
04.01.2017 14:37+1> Это тест вычислений с плавающей точкой. Весьма актуален в настоящее время, потому что данные операции подешевели и все больше заменяют целочисленные.
Это где интересно? Разве что в играх. В бизнес-логике в основном строки и целочисленные айдишники.tyomitch
04.01.2017 14:49И в этой бизнес-логике критически важна скорость операций над строками и целочисленными айдишниками?
terryP
04.01.2017 15:04+1А что есть html? Строки. Что есть json и xml? Строки. Что есть sql запросы? Cтроки. Что есть деньги? Целочисленный тип, так как типы с плавающей точкой не подходят для хранения денежных сумм. Вычисления с плавающей точкой в бизнес логике тоже встречаются, но их редко бывает очень много.
tyomitch
04.01.2017 15:42Речь-то шла не про деньги, а про целочисленные айдишники.
И не про обработку html / json / xml / sql — ею, я надеюсь, занимается бэкенд — а про бизнес-логику.terryP
04.01.2017 15:47+1ею, я надеюсь, занимается бэкенд — а про бизнес-логику.
Ооо, а что такое, по вашему, бэкенд? Где у вас живет бизнес логика в классической трехзвенке? Во фроненде или базе данных?
VolCh
05.01.2017 09:41+1А что есть html? Строки. Что есть json и xml? Строки. Что есть sql запросы? Cтроки.
Это всё форматы представлений и запросов. Бизнес-логика обычно оперирует числами и идентификаторами (по сути не важно в какой форме).
michael_vostrikov
04.01.2017 15:08Нет, но и вопрос мой не об этом. Хотя быстро обрабатывать строки тоже не помешает.
VolCh
05.01.2017 09:38В бизнес-логике в основном строки и целочисленные айдишники.
Это что же за бизнес-логика такая? Обычно бизнес-логика считает количества, цены и стоимости.michael_vostrikov
05.01.2017 10:16Количество — целое число. Цену и стоимость во флоатах не считают. Разве что в статистических отчетах и графиках, но там и раньше так считали, то есть нельзя сказать, что там операции с плавающей точкой заменяют целочисленные. Оттого и вопрос.
Randl
02.01.2017 21:38+9Вот так, с помощью нехитрых приспособлений
буханку белого (или черного) хлебаассемблер можно превратить втроллейбусязык веб-программирования… Но зачем?
antonksa
02.01.2017 22:01+6Писать веб-сайты на ассемблере полезно и приятно
Жесть
Для базы данных была выбрана SQLite.
Жестокая жесть
Ну, вот и все. Если кому понравилось, используйте на здоровье.
Спасибо, как нибудь в другой раз. В другой жизни.
TheDeadOne
03.01.2017 08:22+8Ты скучный. Наверняка, даже не пытался никогда написать программу опкодами.
mikeus
03.01.2017 11:38+10Писать веб-сайты на ассемблере полезно и приятно
Жесть
Не очень понятно — человек взял написал и говорит, что это полезно и приятно.
А у вас как-то не аргументировано.
d1mk0
03.01.2017 19:00-1Для базы данных была выбрана SQLite.
Жестокая жесть
А что с SQlite не так? Или коллега привык на каждый чих развертывать MSSQL?
RPG18
03.01.2017 19:28Насколько понимаю, SQlite поддерживает одного писателя, а когда имеем несколько писателей, то получаем SQLITE_BUSY, который приходится обрабатывать вручную.
Кто то должен обслуживать wal(очищать, перемещать данные из wal в базу и т.д.), этим будет заниматься ваш обработчик, который вроде как должен быстро отдавать ответ на запрос.
TheDeadOne
04.01.2017 08:24+1По умолчанию. Но её можно перевести в режим WAL.
RPG18
04.01.2017 11:19+1При WAL читатели не блокируют писателей, а писатели не блокируют читателей. Т.к. WAL один, то и писатель может быть только один. И все равно есть пункт: Sometimes Queries Return SQLITE_BUSY In WAL Mode.
antonksa
03.01.2017 21:28+4Я привык, что у меня развернут постгрес и я просто добавлю новую базу в кластер.
К чем смысл страдать с асмом ради первоманса и экономии памяти а, в итоге, подключить тормозок sqlite'a.
А вообще у автора много свободного времени и запасная жизнь. Я бы столько времени не тратил непонятно на что. Взял бы готовый движок форума, развернул его за 15 минут и забыл. Каждая секунда моей жизни для меня важнее сэкономленных мегагерцев и мегабайт.
tyomitch
04.01.2017 14:59+2А вообще у автора много свободного времени и запасная жизнь. Я бы столько времени не тратил непонятно на что.
Зачем идти в пеший поход на неделю, если можно до конечного пункта доехать на поезде за два часа?
Зачем рисовать картину красками, если можно щёлкнуть айфоном и распечатать?
Вот и тут как-то так.
evgenymarkov
02.01.2017 22:10+20Надо было публиковать это в хаб «Ненормальное программирование» :)
VioletGiraffe
03.01.2017 10:50Пора заводить хаб «Ненормальный back-end», ну а там и «ненормальный front-end» подтянется.
TimsTims
03.01.2017 11:27+9Для неопытного фронтендчика — весь современный фроеюнтенд кажется ненормальным)
Danakt
03.01.2017 21:04А для опытного — все что другим кажется ненормальным, покажется отличной идеей.
https://ru.m.wikipedia.org/wiki/WebAssembly
longclaps
02.01.2017 22:27+5> Использование веб программы на ассемблере может сэкономить много денег от хостинга
[sarcasm] Хостинг-провайдеры кусают локти и ждут обрушения рынка. [/sarcasm]
Ничего. Левша вон блоху подковал, и тоже не взлетело — бывает.
Siemargl
02.01.2017 23:09+2С одной стороны, писать сайт на ассемблере — не-кост-эффективно.
С другой — проблема производительности все же есть, не зря акамаи и подобные востребованы. Сам веб — неэффективная технология со стороны клиента, потому все мучаются со стороны сервера.
В ту же копилку — любой SQL также не особо эффективен по отношению к конкретной задаче. Но до определенного предела (SQL кстати, забывают что погрешим), весьма удобен.
А что потом? Ищем оптимальные, или используем подставные планы исполнения, пытаемся как то обмануть абстрактные машины типа sql, jvm и прочие байт код интерпретаторы.
Это тлен, во имя «быстро написать и сдать».
Дальше скупые платят уже нам вдвойне, «за оптимизацию»
Просто бизнес
Psychosynthesis
03.01.2017 00:23+1Это и забавно и круто одновременно…
Хотя пожалуй больше всё-таки забавно.
maniacscientist
03.01.2017 02:24+4Ассемблер — и какие то внешние библиотеки? Как то фу. Интереснее было бы ограничиться каким-то объемом как на спектруме, и чтобы его на всё хватало — и на код, и на данные. Без базы, только с набором подпрограмм, редуцированных до обслуживания постохранилища. Ну и загружать-выгружать это целиком.
NeoCode
03.01.2017 02:35-5Браво! Наконец-то кто-то это сделал.
Я С/С++ программист в свободное время изучаю (пока только изучаю) современные веб-фреймворки, и это туши свет! Мало того что php/python/ruby etc. сами по себе интерпретируемые языки, так разработчики еще и внутрь умудряются напихать каких-то бешеных абстракций! ORM — «птичий» язык доступа к БД, зачем когда есть SQL? Шаблонизаторы — еще один птичий язык. Я когда смотрю на это и понимаю какое количество пустопорожнего кода там выполняется, сколько раз происходят бессмысленные переаллокации памяти и перекачивание данных между буферами прежде чем они попадут в HTTP поток…
А если еще вспомнить как работает веб сервер — активизируется заново для каждого обращения, выполняет каждый раз 99% одних и тех же действий и только 1% отличающихся для каждого запроса… это тоже непаханное поле для оптимизации, и какое нибудь кэширование байт-кода php только слегка затрагивает эту тему.
Конечно писать именно на Ассемблере… может быть просто just for fun, но на Си — вполне разумное решение.
asdf404
03.01.2017 04:12+5php/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, но всё равно не стал бы на нём писать веб.
terryP
03.01.2017 10:53+1Только PHP, насколько я знаю, позволяет инлайнить код прямо в HTML, остальным языкам (React не рассматриваем) нужны шаблонизаторы.
Java тоже может, либо в серлетах генерить HTML просто как текст, либо инлайнить код прямо в HTML это JSP технология. Но в большинстве случаев оно не несет особого смысла, так как по сравнению с любым запросом в БД шаблонизатор практически не требует времени и ресурсов.
stychos
04.01.2017 19:51оверхед неизбежен, но это плата за скорость разработки.
Ага, рассказывайте, скорость разработки ) Автор топика написал за месяц с нуля форум на ассемблере, даже не зная что такое FastCGI. А вкурить во все эти тонны абстракций, все эти ORM и шаблонизаторы, изучить какой-нибудь фреймворк - займёт куда поболее месяца. При этом, как не знал, что такое FastCGI, так и не узнаешь.Source
05.01.2017 00:22+4Автор конечно крут, но надо учитывать сколько лет он до этого писал на ассемблере… Я думаю, если взять такой же опыт в веб-программировании, то все абстракции будут уже давно вкурены и изучить какой-нибудь ещё один фреймворк можно будет за день :-)
VolCh
05.01.2017 09:43-1В целом, да. Не досконально, но типа форума написать на незнакомом фреймворке и даже на незнакомом языке вполне можно за день. Если не выходить за рамки привычных парадигм типа ООП и иметь приличную документацию.
neit_kas
03.01.2017 04:20+9Это кажется ненужным, пока пилишь <h1>Hello world</h1>. Я сам ориенитровался на low-level, и мне тоже было не понятно, зачем всё это. Но так получилось, я попал на работу в качестве веб программиста. Там пилят один облачный проект уже далеко не один год (т.е. он работает и его пилят одновременно). Там производительность не на первом месте точно, т.к. имеется два жирных сервера. Зато на первом месте поддерживаемость. И, собственно, стало понятно почему. Когда пилишь что-то для себя, обычно помнишь, что как робит. Когда приходишь в новый для тебя проект, плюс нужно читать чужой код, то понимаешь необходимость всего этого. Без этой мишуры какая-нибудь вшивая правка на два часа работы может обернуться недельным выносом себе мозга.
NeoCode
03.01.2017 21:57Если язык разработки будет статически и строго типизированным и компилируемым, то значительная часть вшивых правок приведет к нормальным ошибкам на этапе компиляции, а не недельным выносом себе мозга.
Source
03.01.2017 22:34+2Если язык разработки будет статически и строго типизированным и компилируемым
Отличная идея! Только причём тут low-level? В ассемблере типизации вообще нет, в Си она слабая… А под Ваш критерий лучше подходит Haskell, или Idris, или на крайний случай Crystal.
neit_kas
04.01.2017 04:27Смотря как организовать. В плюсах динамическую типизацию частично объединения заменяют. Что действительно сложно заменить из PHP — это символические ссылки на классы. Т.е. конструкция вида:
$object = new $class; неплохо так вынесет мозг рядовому C++ программисту. Но, как заметил, такие штуки нечасто используются.oxidmod
04.01.2017 09:31+2не хочу вас расстраивать, но довольно часто во всяких фабриках и прочих порождающих шаблонах)
neit_kas
04.01.2017 15:31+1Именно в них и видел. Говорил относительно того проекта, где я участовал. Там фабрики не столь частое явление. К тому же зачастую они очевидны. Особое веселье данная конструкция доставляет, когда имена классов подтягиваются откуда-то из анналов, каким-нибудь образом меняются и объявляются. Потом тебя просят убрать какой-нибудь из этих классов из проекта.
index0h
03.01.2017 11:38+6Все эти абстракции и птичие языки нужны для делегирования работы между разными специалистами, экономии вменении разработки, упрощения поддержки и тестирования.
В один прекрасный момент ресурсы у любого железа кончаются и поднимается вопрос о распределении нагрузок. Так уж получается, что основное время ваша система, пусть даже на С будет тупо ждать ответ. С этого ракурса — написав web систему на C вы не особо выиграете. Если же взять во внимание время, которое вы потратите на разработку — это будет на много дороже.
Lexus27
03.01.2017 16:30На Ассемблере конечно не очень технологично, но если подойти фундаментально и написать целый Web Framework на нем с уже отработанными(на высокоуровневых инструментах) кейсами, тогда есть возможность попытать чего то в этом, Но разработка будет — долгой, и мы не всегда успеваем за тенденциями, в то время как производится разработка, начав серьезный «поход» трудно его на лету «корректировать», чтобы такой проект «выстрелил» и уже готовый появился на свет «вовремя», сейчас разработка «велосипедов», оправдывает себя только если это делается Очень быстро при условии что «парадигма» будет реально эффективна с точки зрения юзабилити, охватываемых кейсов и производительности, но одно другому мешает в данном сравнении.
Evgeny42
03.01.2017 02:44Заметил, что время выполнения скрипта линейно возрастает от кол-ва постов в теме (1 пост ~ 2ms, 15 постов ~ 13ms) с чем это связано? Не с базой же.
UPD: хотя судя по всему именно с базой. Статистику по запросам интересно было бы посмотреть. Изучать какие запросы в коробке как-то трудновато, учитывая незнание asmjohnfound
03.01.2017 13:27Это из за рендеринга markdown. Каждый пост обрабатывается отдельно. А markdown вообще транслируется весьма сложно — там два прохода по тексту и сложные правила. BBcode было бы на порядок быстрее.
Evgeny42
03.01.2017 13:50+3А почему вы не храните у себя два варианта? Транслированный вариант и оригинал?
johnfound
03.01.2017 14:20Можно конечно. Только для прототипа это было не нужно. Производительность пока хватит с избытком. А если понадобится сделать можно очень быстро.
Evgeny42
03.01.2017 15:00+4Ну я так скажу, у нас коммерческая црм, написанная на php (+phalcon) работает не сильно хуже, когда речь идет о большом кол-ве постов. Понятное дело не 2мс, но 20, по памяти выходит близко к вашему (2-4мб, если замерять средствами php).
К чему это я? Можно было бы сделать реально что-то очень быстрое, чтобы показать реальные преимущества, а не только теоретические.johnfound
03.01.2017 15:22+1Ну я так скажу, у нас коммерческая црм, написанная на php (+phalcon) работает не сильно хуже, когда речь идет о большом кол-ве постов. Понятное дело не 2мс, но 20, по памяти выходит близко к вашему (2-4мб, если замерять средствами php).
Между 2 и 20мс разница в 10 раз. А кстати, на каком сервере работает этот php+phalcon? Параметры моего хостинга даны в статье.
Evgeny42
03.01.2017 15:47+3Между 2 и 20мс разница в 10 раз, я согласен. А вот разницы между 20мс и 20мс нет :)
Сервер конечно лучше вашего, я просто хотел показать что это не какие-то ВАУ числа. 20мс даже на таком хостинге как у вас не вызывают восторга. Да, быстро, но не более того.
Duke565
03.01.2017 03:46+6Уаы, но мои сайты на Go быстрее работают. Просто у вас уперлось в бд.
Сделайте хранение данных в памяти и раз в минуту сохраняйте дамп на диск.
Апач думаю даёт мало оверхеда, поэтому можно оставить.
foxin
03.01.2017 03:53+1Для полноты эксперимента осталось запихать все это в микроконтроллер.
A-Stahl
03.01.2017 03:57+5>я решил писать на 32 битном ассемблере для x86
Только вот не «запихать», а «нахрен с нуля переписать».
На мой взгляд Си, а то и Си++ (можно обмазаться STL и перестать бояться возни со строками практически без штрафов производительности) куда лучше подходят под такие задачи хотя бы из-за своей кроссплатформенности.
ruslanys
03.01.2017 09:43+8На мой взгляд, эта статья доказывает не тот факт, что на Assembler можно разрабатывать веб-приложения — это и так понятно,
просто дурака не нашлось, который это сделает, а то, что у программиста присутствует страх выхода из зоны комфорта (боязнь обучения новым технологиям и языкам).
А теперь давайте спросим сколько времени потребовалось сделать такой форум на Assembler, и сколько времени потребуется на эту же задачу «порочным» «PHP, ну или на один из модерных языках Питон, Руби, Node.js и т.д.» программистам.johnfound
03.01.2017 13:33А теперь давайте спросим сколько времени потребовалось сделать такой форум на Assembler, и сколько времени потребуется на эту же задачу «порочным» «PHP, ну или на один из модерных языках Питон, Руби, Node.js и т.д.» программистам.
Я написал сколько времени потребовалось мне. Но ничего не могу сказать насчет Питон и Руби. Если вы можете, то скажите и сравним.
Но мне кажется, что на ЯВУ, очень грязно и с багами, написать будет быстрее, а вот вылизать все и выдать работающий продукт уже будет вполне сравнимо.
terryP
03.01.2017 14:26+2На Java, с использованием веб Фреймворков, ORM и т.п., подобный функционал грязно и с багами можно сделать за два дня (за день если очень спешить).
Вылизать все и выдать работающий продукт, то есть работающий на любой базе данных, с сотнями и тысячами unit, интеграционных, e2e и перфоманс тестов, который можно продавать за реальные деньги — может быть будет сравнимо по времени с вашей разработкой, только это совсем другой класс продуктов чем ваш форум. Уж поверьте, ваш форум находится тоже в категории «грязно и с багами», просто потому что его оттестировать по-настоящему долго и дорого.johnfound
03.01.2017 14:33А без веб Фреймуърков?
Потому что, если считать AsmBB веб фреймуърком, то теперь я тоже за два дня могу чего нибудь подобное написать — например блог или cms.
Randl
03.01.2017 14:38+2А что-то более серьезное?)
johnfound
03.01.2017 14:42+1Не вопрос. :D
sshikov
03.01.2017 20:45Ну оцените для начала, сколько займет реализация HTTPS? :)
johnfound
03.01.2017 20:55+2Ну оцените для начала, сколько займет реализация HTTPS? :)
А она уже реализована. Давал выше ссылку на RWASA, но опять дам, не жалко: https://2ton.com.au/rwasa/
Замечательный сервер 100% на ассемблере с TLS и FastCGI.
sshikov
03.01.2017 21:14+1Не, ну это же не вы написали.
Вообще SSL тут просто в качестве примера — сколько времени займет реализация скажем прокотола SPDY или HTTP 2.0, на асме?
Таких тонких мест в web достаточно много — например, были попытки вызвать DDOS путем передачи сервису заголовков, вызывающих множественные коллизии в hash map, где обычно хранят заголовки сервера на Java. Вы же храните http заголовки? Насколько вам легко поменять тип контейнера?
И так в общем на каждом углу будет — либо все будет в виде библиотек, а тогда зачем ассемблер?
Вот скажем не очень быстрый язык groovy, для JVM. Насколько я помню, на достойном железе, за счет некоторых несложных оптимизаций, безо всякой магии, на нем получали результат порядка полумиллиона http запросов в секунду. Сколько у вас один запрос, 1мс? Так вы значит в 500 раз отстаете, или я что-то неправильно считаю?johnfound
03.01.2017 21:29+1Не, ну это же не вы написали.
На ЯВУ пишется быстро и легко именно потому что многое уже написали не мы. То что требовалось доказать.
Насколько я помню, на достойном железе...
Не знаю. Всегда запускал только на очень недостойном железе. Если у вас, есть "достойное", попробуйте запустите и скажите.
sshikov
03.01.2017 21:54+2Не, ну берем простой ActiveMQ. Это чистая Java. Он на вполне обычном недорогом двухядерном железе выдает порядка 2000 сообщений в секунду.
Это не http а немного другое — но тем не менее, это получение сообщения из сети, складирование его в базу, некоторая маршрутизация, отдача клиенту снова по сети. Т.е. тут есть все основные компоненты, типичные и для http тоже, кроме разве что шаблонизаторов.
В итоге — меньше 1 мс на сообщение. Память сэкономили? В большинстве практически интересных случаев дополнительная память стоит просто такие копейки, которые с зарплатой программиста несравнимы.
И потом — вы в курсе, что сегодня html страница бывает порядка мегабайта, и зачастую делает много чего интересного на сервере? Т.е. сожрать всю вашу экономию памяти — это просто подключить скажем svg процессор какой-нибудь, или imagemagic, или еще какую-то фигню для генерации контента?
Ну и ради чего стоило так стараться? Разве что из спортивного интереса.0xd34df00d
10.01.2017 23:11Т.е. сожрать всю вашу экономию памяти — это просто подключить скажем svg процессор какой-нибудь, или imagemagic, или еще какую-то фигню для генерации контента?
Надо просто и это переписать на ассемблере.
terryP
03.01.2017 14:50+3я тоже за два дня могу чего нибудь подобное написать — например блог или cms.
Хорошо, а за сколько вы напишите простой сайт онлайн банкинга с транзакциями и необходимой надежностью?
За сколько напишите интеграцию по Rest и Soup с другими сервисами, прикрутите к вашему форуму Ajax, работу с json и xml?
Загрузку и выгрузку в Excel/Word?
Все это грязно и с багами тоже делается на Java за 2 дня (все вместе). А у вас за сколько? Особенно без хаков с чужими библиотеками.
А без веб Фреймуърков?
А это бессмысленно предложение, серлеты, JSP, orm это официальная часть Java технологии, её вам предоставит любой веб.сервер на Java, это равносильно сказать, за сколько вы сделаете свой сайт без вебсервера.Так или иначе, веб фреймворк, хотя бы на уровне серлета (то есть генератора HTML из текста, на Java будет).johnfound
03.01.2017 15:02+3А у вас за сколько? Особенно без хаков с чужими библиотеками.
Странно почему на Java можно использовать чужие библиотеки, а на ассемблере, видите ли, нельзя ???
terryP
03.01.2017 15:19+6Потому что теряется всякий смысл использования ассемблера. Ну подключите вы библиотеку на Java для работы с Excel/Word, базу данных на C++, шаблонизатор на PHP и что останется у вас от ассемблера? Только код не переносимый между процессорами и как бы сайт на ассемблере. Можно вообще весь код написать на C или Java, а потом одним вызовом подключить «библиотеку».
Хорошо, уточню: без хаков с чужими библиотеками, написанными на высокоуровневых языках. На Java можно обойтись библиотеками, созданными только на Java, а на ассемблере?
В целом, как забивание микроскопом гвоздей разработка забавная, но на любом языке (хоть Java) можно сделать лучше, быстрее и даже производительнее.
Производительнее в том плане что используя многопоточность, нормальные базы данных, кэширование получиться отклик страницы намного быстрее чем вы сможете достичь на ассемблере Так как скорость кода вовсе не означает скорости ответа.Siemargl
03.01.2017 18:48+2Хорошо, уточню: без хаков с чужими библиотеками, написанными на высокоуровневых языках. На Java можно обойтись библиотеками, созданными только на Java, а на ассемблере?
А что, есть JVM, написанная на Java, которой можно пользоваться?
В целом, как забивание микроскопом гвоздей разработка забавная, но на любом языке (хоть Java) можно сделать лучше, быстрее и даже производительнее.
Ваша Java на таком хостинге, да и на очень многих подобных, даже не запустится
Производительнее в том плане что используя многопоточность, нормальные базы данных, кэширование получиться отклик страницы намного быстрее чем вы сможете достичь на ассемблере Так как скорость кода вовсе не означает скорости ответа.
Надо сравнивать технологии с одинаковым стекомterryP
03.01.2017 19:57+6Ваша Java на таком хостинге, да и на очень многих подобных, даже не запустится
Запустится, Java 8 требует 128 МБ памяти и 126 МБ на диске.
Надо сравнивать технологии с одинаковым стеком
Есть заявление, что на ассемблер все делается легко и просто. И мол зачем вообще нужны высокоуровневые языки. А получается что все делается относительно легко, только если подключать библиотеки из других языков, а никто и никогда не будет делать полноценный стэк подобных технологий на ассемблере (ибо их придется выкинуть при каждой смене архитектуры железа).
Ну да, Java обгонит по производительности Си если подключить библиотеку на ассемблере и делать всю критическую по производительности работу в ней. Только так нечестно сравнивать производительность и нечестно сравнивать скорость разработки ассемблере, если 99% функционала на самом деле будут выполняться на высокоуровневом языке.
Siemargl
03.01.2017 23:29+1Запустится, Java 8 требует 128 МБ памяти и 126 МБ на диске.
Я имел в виду аналогичный сайтик на Яве, а не просто JVM.
Проблема скорее в прожорливости фреймворка, чем в JVM.terryP
04.01.2017 11:45+1Проблема скорее в прожорливости фреймворка, чем в JVM.
Значит надо не использовать такие фреймворки. Tomcat или Jetty (это веб серверы для Java) требуют около 12Mb памяти и диска, примерно столько же сколько Апач, при этом дают возможность использовать сервлеты и всякие jsp. Для данной задачи этого с головой хватит.Siemargl
04.01.2017 14:43Ну прямо чудеса какие то.
Но почему то дефолтная установка Tomcat 8 прописана с Xms256Mb.
Я уже молчу про размер виртуальной памяти для Java фреймворка — VSZ в 2.5Гб — то что она намерена сожрать (по необходимости).terryP
04.01.2017 14:57+2Но почему то дефолтная установка Tomcat 8 прописана с Xms256Mb.
Дефолтная установка и минимальная установка это совсем разные вещи. Дефолтная установка не предполагает экономию памяти и вообще предназначена для больших EE приложений, то есть она прописана с огромным запасом (там принцип — память дешевле процессора, поэтому лучше сожрать больше памяти, но работать чуть быстрее).
К тому же я говорил про Tomcat 6/7, они едят чуть меньше памяти чем 8. По дефолту Java приложение съест столько памяти сколько ей «хочется», но можно заставить работать её с и меньшим кол-вом памяти. Тем более если там не будет ничего серьезного вроде транзакций, а простейшие сервлеты, вида сгенерировать html из строк и простых jdbc запросов к базе.Siemargl
04.01.2017 15:18Так Вы в состоянии продемонстрировать минимальное потребление?
Запустить минимальное серверное приложение, заставить его «прогреться» запросами и показать вывод RSS и VSZ для Java-tomcat процессаterryP
04.01.2017 15:52Эээ, вы правда считаете что мне больше в жизни делать нечего? Продемонстрировать в состоянии, но тратит свое время на это не собираюсь. Мне, в принципе, все равно верите мне или нет. Если вам это важно, гугл в помощь.
Siemargl
04.01.2017 23:23-5Очевидно, ты простой дилетант, если для тебя элементарная задача подтвердить свои слова хелловорлдом существенно «тратит свое время».
А то, что ты писал про базовое потребление, я на стековерфлоу тоже видел.
Толку от тебя 0.terryP
05.01.2017 10:48+3Угу, демагогия прием «ad hominem» — переход на личности.
Задача элементарная, но все эти «сделай бенчмарк», дай отчет об «использовании памяти» в Инете всегда заканчивается одним и тем же: это неправильный отчет/ты исправил цифры в блокноте/ты померил не то и не там/ты запустил на Linux, а надо было на Windows, не на 32 битном процессоре, а на 64битном, не в включенном Compressed Oops, а с выключенном/твоя конфигурация слишком минимальна. И вообще твой Hello World слишком простой, давай сразу форум как у автора напиши.
Не хочу заниматься сомнительной игрой «Докажи, что не верблюд» и тратить время на установку и настройку Tomcat 6/7 в минимальной конфигурации. Плюс если делать исследование по уму, то любой элементарный бенчмарк требует учитывать много моментов и проверять его работу на разном железе/операционках. Если мне нужно будет засунуть tomcat или Jetty в хостинг с минимальными характеристиками, тогда проведу полноценное исследование и напишу статью, но на это придется потратить пару дней, если делать все по уму.
Если у вас есть реальный интерес, а не просто холивары разводить — подскажу на сайте tomcat'а море работающих примеров, скачиваете tomcat, примеры и тестируйте сами.Siemargl
05.01.2017 11:40+1Это не бенчмарк, это простая проверка порядка — 10мб в действительности потребляется минимально, или все же 200. Точность бенчмаркинга здесь не нужна.
Тем более, речь идет о простом минимуме.
Я, например, не поленился скачать виртуалку с Томкатом и посмотреть, например.terryP
05.01.2017 11:45+1Я, например, не поленился скачать виртуалку с Томкатом и посмотреть, например.
И ваши результаты?
stychos
04.01.2017 20:08+1Да не рассказывайте сказки, сейчас работаю над проектом одним - там надо разворачивать кучи виртуалок с этой жабой на этом томкате - вполне радостно ради вшивого интернет-магазинчика по 2 гигабайта каждый инстанс кушает. И тормозит нещадно. Молчу уже про то, что просто для того, чтобы весь этот зоопарк запустить, надо подождать, пока томкат две минуты занимается каким-то индексированием. Тьфу, в этом плане даже php в разы быстрее, экономичнее и удобнее.
michael_vostrikov
03.01.2017 15:14+8Напишите точно такой же форум, только с базой MySQL. 2 дня точно хватит?)
vlreshet
03.01.2017 10:43+6«Писать веб-сайты на ассемблере полезно и приятно» — что? Сайты на современных языках типа php или java скорее получат бутылочное горлышко в бд или сетевых протоколах, чем в языке. Чтобы не быть голословным — работаю на ну оочень немаленьком проекте на php. И несмотря на мощную бд на амазоне — мы постоянно упираемся в её скорость. Недавно перешли на php7 — а заметно скорости не прибавилось. Скажете «вы просто говнокодеры»? Возможно. Но врядли вот эти ребята (разработчики mysql) тоже говнокодеры. А их нанимал клиент для оптимизации нашей бд. Вывод из этого всего? А он простой — при огромной кодовой базе написанной несколькими командами разработчиков — сайт упирается во всё что можно, только не в скорость кода. Чем бы тут помог ассемблер, кроме как лишними проблемами?
michael_vostrikov
03.01.2017 11:12+11Итого. Вы переизобрели обработчик FastCGI, парсер HTTP, GET и POST, решали проблемы с разрядностью и библиотеками, все это вместо того, чтобы решать задачу. Вы месяц писали простой форум, и написали 12000 строк кода, который сложно поддерживать. Писать сайты на ассемблере можно для себя, если охота, но для бизнеса это неприемлемо.
sidny_vicious
03.01.2017 11:39+1Интересная идея.
Насчет применения в коммерческих целях не уверен, но как проект для демонстрации возможностей и эксперимента очень крут.
CoderMike
03.01.2017 11:39+4Нет ничего глупее, чем тратить свою жизнь на изобретение велосипедов и думать что ты самый умный. Людские ресурсы намного более важны сейчас. И лишь несколько процентов организаций могут похвастаться какими-то супер оптимизациями за счет своих денег/людских ресурсов, когда они уже достигли успеха, большинство лишь используют тонны чужого кода и правильно делают, иначе они были бы трупами в бизнесе. PS. Пишу на PHP, Java, C#, ранее делал игры под Z80 игры имея 8kb видео памяти и 64 кб вообще в системе!
johnfound
03.01.2017 11:48+13Всем привет. Извините насчет плохого Русского языка. Некоторые товарищи отредактировали и прислали исправления. Постараюсь все исправить как можно быстрее.
johnfound
03.01.2017 13:11+14Вот, кажется все отредактировано хотя бы грамматически. Наверное некоторые предложения все-таки звучат не по русски, но я здесь ничего не могу сделать — Русский я учил в школе, примерно 35 лет назад. Читаю много, понимаю все, но падежи для меня очень сильное колдунство :D (их в Болгарском языке нет).
Большое спасибо: gearbox и Protonicus! Ребята, вы мне помогли очень сильно!
vlreshet
03.01.2017 12:39+6Так как ассемблер я знаю, то больше всего затруднения во время работы вызвало незнание веб протоколов. Пришлось читать RFC документы насчет SMTP и FastCGI.
Имхо, это одна из самых больших проблем такой разработки. На «обычном» языке оно ж как — понадобился, например, smtp — подключил библиотеку и погнал. Надо сокеты? Без проблем. Надо изображения обрабатывать (сжатие, обрезка, ит.д.)? Да в 4 строчки. Надо архивы паковать? Да легко. А на асме для этого надо строить свои велосипеды, которые, к тому же, смогут ездить только по определённой дороге. А потом даже для использования уже готовой библиотеки — городить 3 экрана кода. Всё вылизать, вычистить, радоваться точному управлению регистрами, и… понять что жёсткий диск сервера всё равно не позволяет сделать такую-то операцию быстрее чем обычный язык. Или понять что бд до лампочки какой там ассемблер к ней достучался.MacIn
03.01.2017 18:50Надо сокеты? Без проблем. Надо изображения обрабатывать (сжатие, обрезка, ит.д.)? Да в 4 строчки. Надо архивы паковать? Да легко
Так никто не мешает прикрутить библиотеку на том же Си. Это ж спортивный интерес у автора.
rkfg
03.01.2017 13:29А меня заинтересовали параметры хостинга. Такого ада я ещё не видел, чтобы было ограничение на потребление процессорного времени, да ещё посуточно + ограничение на процессы, но при этом можно запускать свой бинарный код, т.е. не PHP/MySQL-only. Как я понял, хостится ваше приложение на https://www.superhosting.bg (судя по IP), но похожего плана у них не видно. Просто интересно, сколько такое может стоить.
По теме: если кого-нибудь интересует веб-разработка на сравнительно низкоуровневых языках, могу посоветовать взглянуть на Wt — приятный виджетоориентированный фреймворк на C++, fullstack. На хабре немного было про него, но довольно старое всё. Я переписал один небольшой проект «для своих» с Java на Wt, сэкономил кучу памяти, т.к. на VDS её всего 1 Гб. Сейчас ест примерно 10 Мб, не течёт.
Понятно, что какие-то личные проекты можно писать на чём угодно, в том числе и на ассемблере, но в современном мире ценится не потребление памяти или скорость работы, а поддерживаемость продукта, т.к. человеческое время ценится на порядки дороже машинного. Этим можно быть недовольным, но остаётся лишь смириться.
RPG18
03.01.2017 15:23Я на Wt делал CloudBerry Backup for NAS. На мой взгляд Wt оправдан в двух случаях:
- вы мало что знаете про html, js, css;
- нужно цепляться к C++ коду.
rkfg
03.01.2017 15:39Я в основном пишу веб-приложения, т.е. не сайты, а именно аналог десктопа, но в вебе. Там чем меньше знаешь и используешь вышеперечисленное, тем лучше. Можно сосредоточиться на бизнес-логике, когда сервер и клиент суть почти одно целое. Разумеется, далеко не у всех так.
Wt вряд ли подойдёт для крупномасштабных приложений, в частности, потому что почти любое действие на клиенте вызывает запрос к серверу. Отзывчивость приложения напрямую зависит от пинга до сервера. Но для embedded это то, что доктор прописал. Компактно, быстро, а если располагается в локалке, то пинг можно считать близким к нулю. Но в целом, фреймворк любопытный и стоит того, чтобы его хотя б потыкать.
RPG18
03.01.2017 16:03Я в основном пишу веб-приложения, т.е. не сайты, а именно аналог десктопа, но в вебе.
Именно этим я занимался в CloudBerry Lab. Делал веб интерфейс к десктопному продукту.
Там чем меньше знаешь и используешь вышеперечисленное, тем лучше.
Не получается. Приходит начальство, приносит крутой дизайн интерфейса на картинке и ставит задачу сделать. В таких ситуациях прибегал к помощи front end разработчиков, которые верстали html/css страницу, которую потом шаблонизировал через WTemplate.
rkfg
03.01.2017 16:08Ну, зависит от конторы. У нас нет фронтэндщиков, дизайнеров, верстальщиков, пишем программы вдвоём. Главный критерий — чтобы выполняло поставленную задачу (преимущественно учёт всех сортов, иногда задачи типа хелпдеска или системы оповещения населения). Дизайна из бутстрапа более чем хватает. Конечно, если делать на продажу и вообще на экспорт, всё сложнее, и с таким мне пока сталкиваться не доводилось.
MacIn
03.01.2017 18:51Именно этим я занимался в CloudBerry Lab. Делал веб интерфейс к десктопному продукту.
Забавно. Когда мы выбирали изначальное имя для одного своего веб-клиента для десктопного приложения, тоже назвали его Cloudberry, независимо от вашего проекта. Потом поменяли, чтобы не было путаницы. А название какое-то… витающее в воздухе, видимо.
johnfound
03.01.2017 15:36А меня заинтересовали параметры хостинга.
Это план "СуперСтарт". Официально 6.75лв в месяц (3.4€). Я плачу несколько меньше (2.5€) потому что покупая когда есть "акция".
rkfg
03.01.2017 15:45Спасибо. Но это действительно неоправданные ограничения какие-то (если было бы 5€ в год, тогда ещё можно понять), за эти деньги можно взять полноценную VDS без лимитов на процессы и время. Я сам покупаю у LeaseWeb, там 4.95€. У OVH можно взять за 2.99€, да, чуть дороже, но зато свой сервер для чего угодно. Я к тому, что ассемблер для сайта был выбран всё же не только потому, что это было интересно, но и для того, чтобы вписаться в отведённые ресурсы. Сейчас можно примерно за те же деньги получить сервер с намного более хорошими характеристиками и ни в чём себе не отказывать.
EvilFox
03.01.2017 17:35У scaleway тариф получше за те же 2,99€.
stychos
04.01.2017 20:17Да у тех же ruvds меньше доллара в месяц.
EvilFox
04.01.2017 23:00А теперь характеристики сравните.
stychos
04.01.2017 23:13Я не знаю, что там за vps SuperStart - на сайте не увидел, увидел такое название только в разделе шаред-хостинга. У ruvds по сравнению с самым простым vps из этого хостера спеки конечно пониже - 1 ядро, 512 оперативки и всего 10 гб диска, но он и стоит более чем в три раза меньше, и безо всяких ограничений. Хотя на просторах можно, конечно, найти записи о том, что они выключают слишком активных пользователей - меня пока не затрагивало.
johnfound
04.01.2017 23:53Я не знаю, что там за vps SuperStart - на сайте не увидел, увидел такое название только в
Так, у меня не VPS, а именно SuperStart shared hosting.
EvilFox
05.01.2017 12:18Ну я в сравнении с scaleway имел ввиду.
Так-то если поискать всякие «секретные» тарифы у хостингов то можно найти за 10-15$ в год впску, правда памяти там будет 512 и вроде 5ГБ диска.stychos
05.01.2017 22:55Там, конечно, всё красиво, ну разве что кроме arm на самом дешёвом тарифе. Но для меня, например, важнее дешевизна, и в итоге самое дешёвое, что я нашёл - это ruvds. Причём, мне достаточно понравилась работа техподдержки у них. Если знаете дешевле, подскажите )
EvilFox
07.01.2017 13:04Там есть на x86 за 3€. ARM там на голом железе без всякой виртуализации.
Ну да, за 65р в месяц найти альтернативу сложно. Я у eomy.net секретный тариф за такую стоимость видел. Но у time4vps.eu есть тарифы за 0,99€ за пол года или 0,66€ за год, в чём-то даже лучше чем у ruvds.
Source
03.01.2017 13:38Проект впечатляет, хотя скорее тем, что целиком на асме, а не скоростью работы.
Непонятно почему выбран SQLite, а не PostreSQL или MySQL. Очевидно же, что SQLite — далеко не самая быстрая СУБД.
Кроме того заметил, что поиск тредов по тегу сильно проседает: ~ 20 мс против ~ 7 мс на показ списка всех тредов. Проверьте индексы в таблице пересечения (ThreadTags), думаю, добавление индекса по Tag улучшит ситуацию.johnfound
03.01.2017 14:28-1PostgreSQL и MySQL иногда трудно использовать на виртуальном хостинге. А так, все файлы находятся в одном месте.
И не так медленна SQLite как принято считать. Когда все настроено правильно (WAL, работает очень шустро.
Производительность на демо сервере сравнивать не очень удобно. Там у провайдера есть какое-то распределение ресурсов и иногда все начинает работать 2..3 раза медленнее. Конечно, вполне возможно, что некоторые индексы надо добавить и/или исправить.
Source
03.01.2017 16:12PostgreSQL и MySQL иногда трудно использовать на виртуальном хостинге.
Это наверно большая редкость… Хоть я уже лет 7 вирутальным хостингом не пользуюсь, но не помню, чтобы с этим хоть раз были проблемы… Неужели за предыдущие 7 лет ситуация с виртуальным хостингом так ухудшилась?
Производительность на демо сервере сравнивать не очень удобно. Там у провайдера есть какое-то распределение ресурсов и иногда все начинает работать 2..3 раза медленнее.
Не, дело не в этом. Да, иногда по тегу и больше 100 мс ответ занимает, но чаще всего попадает в диапазон 20-30 мс и тут явно есть performance-bug.
P.S. Ещё на порядок сортировки тредов обратите внимание:
GennPen
03.01.2017 14:36-1А чем хуже разрабатывать в компилируемых языках, например в тех же ASP.Net или Java?
Jogger
03.01.2017 15:26-1И давно эти языки стали компилируемыми?
Jogger
03.01.2017 20:37-2От тех кто минусует — с нетерпением жду загрузчик ос на Java или .NET. Ну компилируемые же языки, да?
MacIn
03.01.2017 21:46+1Это терминологический спор, скучный как не знаю что. Компилятор — по определению это транслятор в машинный код. Если мы считаем байт-код джавовской ВМ машинным кодом, то транслятор джавы — вполне себе компилятор.
Siemargl
03.01.2017 23:31-3А если мы считаем таракана птицей, то что?
Сочтут идиотом
Поскольку дальше есть этап компиляции Java байт кода в машинный — то еще терпимо. Но есть и интерпретаторы байт кода (другого, не JVM), которые медленные как все прочие интерпретаторы.MacIn
04.01.2017 00:12А если мы считаем таракана птицей, то что?
Сочтут идиотом
Нет, это корректное допущение. У нас гипотетически может быть «железный» процессор, работающий с байт-кодом. Если у вас есть виртуальная машина, скажем, bochs или что-то аналогичное, работающее с x86 кодом, который является продуктом компилтора gcc, вы же не будете говорить, что мы имеем дело не с компиляцией, поскольку код исполняется виртуальной машиной.
Но есть и интерпретаторы байт кода (другого, не JVM), которые медленные как все прочие интерпретаторы.
И что? Машинный код многих процессоров тоже интерпретируется.Siemargl
04.01.2017 00:26-1AFAIK bochs интерпретирует чужой машинный код, потому очень медленный.
Но речь идет о конкретной платформе, на которой JVM не родной код, так что не надо заниматься софистикой.
Железный Java-процессор кстати, уже был, еще и не одинMacIn
04.01.2017 00:31+1AFAIK bochs интерпретирует чужой машинный код, потому очень медленный.
Замечательно. Значит то, что некий машинный код — интерпретируется, не делает транслятор в этот код не-компилятором?
Железный Java-процессор кстати, уже был, еще и не оди
Тем более это не дает оснований говорить о не-компиляции.
Но речь идет о конкретной платформе, на которой JVM не родной код, так что не надо заниматься софистикой.
Не додумывайте условий про «заданную платформу». Компилируемость не определяется «конкретной платформой», иначе у нас не было бы кросс-компиляторов.Siemargl
04.01.2017 00:38+1Напоминаю, что эта ветка началась с утверждения
А чем хуже разрабатывать в компилируемых языках, например в тех же ASP.Net или Java?
И нет платформ, ну кроме музея, где байт код JVM был бы родным для процессора.
Потому есть различие — нативный код — не нативный код. Есть ли промежуточная прослойка, транслирующая некий код в нативный или ее нет.
И есть итоговая разница в производительности/ресурсах, требуемых для нее.
Мне надоело.
Про кросс-компиляторы — в учебник.terryP
04.01.2017 12:08+4И в Java и в C# есть компиляторы в машинный код, так что это языки могут быть и компилируемыми и интерпретируемыми (и вообще, эти языки — в первую очередь спецификации и могут быть реализованы хоть на механических «компах», см. компьютеры из костяшек домино).
Siemargl
04.01.2017 13:22-1И где там .NET?
Про экселсиор я забыл, но там ценник…terryP
04.01.2017 13:35+1И где там .NET?
По С# не специалист, но вроде технология NET Native, описана в MSDN
Про экселсиор я забыл, но там ценник…
Это уже совсем другой вопрос. Технологии есть, а бесплатно или нет — не принципиально. Тот же Delphi никогда не был полностью бесллатен (не в курсе что сейчас с оплатой .Net студии, когда с ней работал она тоже стоило прилично для нашей фирмы).
PsyHaSTe
09.01.2017 14:12Для .Net есть бесплатный VS Community (хотя там вроде нельзя коммерческие приложения больше одного разработчика писать), еще есть райдер (пока что без ограничений). Подписка группы разработчиков сравнительно дешевая (по крайней мере относительно зарплат этих самых разработчиков).
Так что пробовать можно бесплатно, разрабатывать — ну чуть-чуть придется работодателю заплатить, но тут уже речь идет о нескольких процентах с ЗП разработчика.vlivyur
11.01.2017 12:09+1Community можно писать впятером и если оборот компании за год меньше миллиона, что ль, баксов.
VolCh
04.01.2017 13:56+1Потому есть различие — нативный код — не нативный код.
Такое различие есть, но оно мало отношения имеет к компиляции.
MacIn
07.01.2017 21:37И нет платформ, ну кроме музея, где байт код JVM был бы родным для процессора.
Байт код — родной для виртуальной машины JVM. Ваши требования «нативности» — волюнтаризм, к градации «компиляция-не компиляция» не имеют отношения.
Потому есть различие — нативный код — не нативный код. Есть ли промежуточная прослойка, транслирующая некий код в нативный или ее нет.
И есть итоговая разница в производительности/ресурсах, требуемых для нее.
Упор на производительность — это демагогия, см. пример с компиляцией и Bochs. Компилируемый язык или нет — не зависит от того, нативный ли код на выходе. Если вы, условно, транслируете программу на платформе Win32 / x86 под Linux/Itanium, то вы выполняете компиляцию, хоть тресни. Кросс-компиляцию, но тем не менее.
Мне надоело.
Про кросс-компиляторы — в учебник.
Для начала разберитесь в определениях, которые отличаются от ваших хотелок, потом вернемся к разговору.Jogger
07.01.2017 22:34>Байт код — родной для виртуальной машины JVM.
Тогда интерпретируемых языков нет — поскольку любой текст программы является родным кодом для её интерпретатора.MacIn
07.01.2017 22:381) В таком случае двоичный код x86 запушенный в эмуляторе — Bochs — это не скомпилированная программа, ведь она исполняется эмулятором.
Тут надо разделить эмулятор машины и интерпретатор языка. Что bochs, что JVM — эмуляторы машин, кмк.
2)железные JVMgearbox
07.01.2017 22:44Забейте, мужики. Со времен книги дракона многое поменялось. Бинарник вида байт-код + интерпретатор является исполнимым, опкоды на процессорах транслируются в микрокоманды, LLVM можно настроить как на компиляцию в бинарники так и на транспайлинг в другие ЯВУ. Нет четкой границы, мужики, все в тумане.
MacIn
12.01.2017 00:26Поэтому я с самого-самого начала сказал, что «это скучный терминологический спор». Потому как не впервой.
Jogger
08.01.2017 00:36Не вижу противоречия. Скажем бейсик — исходно был интерпретируемым языком, что не мешает существованию компиляторов. В моём понимании, исполняемый в интерпретаторе код в данном случае интерпретируемый, а если тот же код собрали компилятором — то уже вполне компилированный. Логично же, нет?
Java, исполняемая на железном JVM — компилируемая. Удачи в поиске такого сервера. В остальных случаях — нифига.
двоичный код x86 запущенный в эмуляторе — да, интерпретируемый. Ну мало ли что он бинарно совпадает с точно таким же компилированным кодом на реальной x86 машине.
А, и ещё. Хотя я не признаю java компилируемой (кроме случая железной JVM, да), интерпретируемой (во всяком случае в привычном понимании) — я её пожалуй тоже поостерегусь называть. Благодаря JIT она является чем-то средним.MacIn
12.01.2017 00:25В моём понимании, исполняемый в интерпретаторе код в данном случае интерпретируемый, а если тот же код собрали компилятором — то уже вполне компилированный. Логично же, нет?
По-моему, нет. Точнее, здесь играет свою роль неоднозначность слова в русском языке. Интерпретируемый как тип, и как страдательный залог.
двоичный код x86 запущенный в эмуляторе — да, интерпретируемый. Ну мало ли что он бинарно совпадает с точно таким же компилированным кодом на реальной x86 машине
Он интерпретируется, но он скомпилирован.
MacIn
12.01.2017 00:29Не вижу противоречия. Скажем бейсик — исходно был интерпретируемым языком, что не мешает существованию компиляторов. В моём понимании, исполняемый в интерпретаторе код в данном случае интерпретируемый
Поясню еще.
У нас на работе используется свой внутренний скриптовый язык в одном из продуктов. Так вот, в языке есть конструкция вида [] которая перед интерпретацией строки подставляет/вычисляет значение something и замещает квадратные скобки им.
Например:
set %b := 1
loop
set %a := arr[%b]
set %b := %b + 1
while…
что эквивалентно:
%a := arr1
…
%a := arr2
и так далее по ходу исполнения.
Вот это — интерпретируемый язык, потому что данную конструкцию невозможно скомпилировать — строка кода изменяется во время выполнения программы, эту конструкцию можно только интерпретировать. Данный язык — интерпретируемый потому что он в принципе некомпилируем.
Siemargl
08.01.2017 03:47Предлагаю изучить что такое транслятор, и особенно задавшему исходный вопрос.
И прекратить заниматься демагогией.MacIn
12.01.2017 00:31Предлагаю кое-кому посмотреть определение, например, по ГОСТу на ЕСПД, а не википедии.
tyomitch
04.01.2017 15:30У нас гипотетически может быть «железный» процессор, работающий с байт-кодом.
Не гипотетически, а вполне реально у нас может быть процессор, выполняющий байт-код Java «в железе» — например:- Sun microJava701 (1998)
- Sun MAJC 5200 (1999)
- aJile aJ-100 (2000)
- Imsys Cjip (2000)
- ARM Jazelle (2001)
Но с тех пор технологии JIT-компиляции развились настолько, что аппаратные реализации JVM утратили практическую ценность.
raidhon
11.01.2017 15:13Для начала вам бы с пониманием слова компиляция разобраться!
Компиляция — «трансляция программы, составленной на исходном языке высокого уровня, в эквивалентную программу на низкоуровневом языке, близком машинному коду (абсолютный код, объектный модуль, иногда на язык ассемблера)».
https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80
https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D1%8B%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
Java и NET компилируемые языки с компиляцией в байт-код.
Вы хрень несете товарищ!
GennPen
04.01.2017 13:47Поясните мне, может я некоторые тонкости «компиляций» не знаю.
Вот допустим есть проект на C#, я в VS нажимаю «Build» — получаю на выходе EXE файл, который могу запустить. Это не компиляция?
Допустим есть проект на ASP.Net, я в VS нажимаю «Publish» — получаю на сервере DLL файл. Это не компиляция?Siemargl
04.01.2017 14:48+1Компиляция. Но внутри твоих бинарников — не нативный процессорный код, а байт код для .net виртуальной машины.
Jogger
04.01.2017 15:24-1Вы простите великодушно, но доказательство убогое.
Давайте проверим — в случае php я на выходе получаю PHP файл, который могу запустить. Это теперь тоже компилируемый язык? А почему нет? Три буковки не те? А вот в проекте под линукс я получаю на выходе файл без EXE и без DLL — значит он уже интерпретиреумый, да? Ну нет же расширения.
На самом деле, правильно выше написал MacIn — это терминологический спор. Я не считаю, что превращение код для виртуальной машины — это компиляция. Именно потому, что машина виртуальная. Если бы речь шла о некоем реальном процессоре, выполняющем байткот — тогда да, я бы согласился, что это таки компиляция. Поясню на примере, почему я так считаю — если мы запускаем виндовый запускаемый файл под линуксом через wine — он не становится нативным приложением, ведь так? Хотя и выполняется под линуксом. Значит разница в том, что в этом случае имеет место виртуальная среда исполнения. Так и в случае с java и .net — это можно назвать «виртуальной компиляцией». Напомню, что виртуальный — значит «Возможный; условный, кажущийся». Кажется, что это компиляция. Но на самом деле нет.terryP
04.01.2017 15:43+1Так и в случае с java и .net — это можно назвать «виртуальной компиляцией». Напомню, что виртуальный — значит «Возможный; условный, кажущийся». Кажется, что это компиляция. Но на самом деле нет.
Выше уже несколько раз сказано, что есть компиляторы в машинный код с этих языков. Есть и вполне реальные существующие процессоры (и их можно купить и использовать) для байткода Java. Java это только спецификация, а JVM может быть на любых принципах…
Azoh
04.01.2017 15:57если мы запускаем виндовый запускаемый файл под линуксом через wine — он не становится нативным приложением, ведь так?
Не так. Приложение исполняется полностью нативно, на том же процессоре, на котором запущена система. Эмуляция ограничена подменой вызовов.
Кстати, сама ОС может быть виртуализирована. Вы же не говорите, что от этого все приложения в ней стали не нативными? А они могут все исполняться в режиме эмуляции, на виртуальной машине эмулирующей требуемый процессор.
Более того, тот же .Net в нормальных случаях не предполагает исполнения в режиме эмуляции, весь код исполняется нативно.
Мы можем, конечно, привязаться именно к содержимому исполняемого файла. Но можно взять тот же C, откомпилировать и сразу запустить, не создавая никаких файлов вообще. Что в таком случае?
Jogger
04.01.2017 16:09-1Ок, значит можно не заморачиваться с кросплатформенностью, раз все мои приложения и так нативно исполняются на линукс. Спасибо.
GennPen
04.01.2017 16:29+1То есть получается, программы на С скомпилированные под конкретное ядро на Линуксе — тоже не компиляция? Т.к. на другом ядре скорее всего не заработают, и уж тем более на другой ОС. И все остальные «компиляторы» — тоже на самом деле не компиляторы, т.к. не обеспечивают полную кроссплатформенность?
Jogger
04.01.2017 21:04Скомпилированные программы не обязаны быть независимы от стороннего софта. Но они отличаются тем, что могут быть независимыми. На Си — можно написать под голое железо программу, которая будет загружаться и стартовать без всякой ОС. В этом и отличие. Хотя, как уже не раз тут отмечали — в случае аппаратной реализации java-машины java таки будет являться компилируемой. Но на другом железе — извините, нет.
michael_vostrikov
04.01.2017 16:38Компиляция — трансляция программы, составленной на исходном языке высокого уровня, в эквивалентную программу на низкоуровневом языке, близком машинному коду (абсолютный код, объектный модуль, иногда на язык ассемблера).
Компилировать — проводить трансляцию машинной программы с предметно-ориентированного языка на машинно-ориентированный язык.
Compile — составлять, собирать.Jogger
04.01.2017 21:09+1Тут главный вопрос — что считать машинно-ориентированным языком.
Вот например если мы интерпретатор бейсика назовём «виртуальная машина бейсик», ну и заодно превратим все команды — в последовательность байт, а не ascii-представление (а на zx-spectrum кстати так и было, там для каждой команды был один байт), бейсик станет компилируемым языком? Ну а что, машина есть — интерпретатор. машинно-ориентированный язык есть. Ну подумаешь команды вычитываются и превращаются в реально-исполняемый код по одной, мелочи какие.VolCh
05.01.2017 10:09+2Вообще да. Именно с тех времён разделение языков на компилируемые и интерпретируемые всё меньше имеет смысла — это особенности реализации транслятора и среды исполнения. Гораздо больше имеет значение типизация: статическая или динамическая (некоторые даже путают статическую типизацию с компилируемостью, а динамическую — с интерпретируемостью), строгая или слабая. А сейчас с JIT для интерпретаторов и виртуальных машин для компиляторов — ещё меньше. Особенно если вспоминать про интерпретацию машинных кодов на аппаратном уровне в последовательности элементарных операций, которая была уже сильно развита на том же Z80 по сравнению с i8080, где она тоже присутствовала в командах типа CD 03 F8 :), осуществляющей минимум три элементарных операции (копирование IP в память по адресу из SP, уменьшение SP, копирование операнда в IP).
MacIn
07.01.2017 21:40бейсик станет компилируемым языком
Он компилируемый и так и так, без приведенных допущений.
YemSalat
03.01.2017 15:01+7Спасибо за статью, но мне кажется было бы лучше если бы вы раскрыли вот эту тему:
… написание сайтов на ассемблере очень полезно, а с подходящими инструментами — легко и приятно ..
А так получается что статья — «я написал форум на ассемблере — вот он»MacIn
03.01.2017 18:55Почему легко и приятно — можно понять, посмотрев код автора. Он написал ряд библиотек и многие задачи вырождаются просто в вызов по шаблону функций одну за одной. Потому и легко — скрывается абстракцией.
vlreshet
03.01.2017 19:05+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
MacIn
03.01.2017 19:10-2Легко и приятно — это высокоуровневый код в котором есть конструкции типа
Бесполезное сравнение. Это, на минутку, разные парадигмы. В одном случае мы имеем императивное, в другом — ООП. Сейчас придет какой-нибудь функциональщик и скажет свое «фи» на ваше ООП.
$user->setNewPassword('123456')->save();
Это субъективно — спору о конвейере Vs проверке кодов ошибок с последовательным исполнением — множество машинных тиков в обед. Мне, например, наоборот, некомфортна такая запись.
А что лёгкого и понятного в коде типа вот такого? Да ничего.
Да всё.vlreshet
03.01.2017 19:21+4Как может быть понятен код, в котором даже нельзя наименовать переменную так как мне надо (точнее можно, но в том случае если это именно своя переменная а не системный регистр)? И парадигма тут ни при чём. Вот смотрите — как бы там не было, но в моём коде чётко понятно что в $user — очевидно хранятся данные пользователя. И это одна строка кода, урывок из контекста. Теперь берём отрывок асма.
bswap eax
откуда мне знать что мы храним в eax в данный момент?
Или же
cmp eax, [esi+edx]
А почему сравниваем это? Что такое esi и edx? Сравните какое-нибудь
if(user.type == UserTypes.Admin)
с
cmp eax, [esi+edx]Где тут понятность? И ооп тут ни при чём — изменить user.type (ооп, объект) на user[«type»] (массив, более функциональный подход) — менее понятно не станет.
MacIn
03.01.2017 19:46-1Вы пытаетесь доказать, что писать на асме подобные приложения сложно по сравнению с ЯВУ. Это бесполезная борьба с ветряными мельницами. Говоря об удобстве, имеется в виду, что «все не так плохо, как казалось», не более. ИМХО.
Как может быть понятен код, в котором даже нельзя наименовать переменную так как мне надо (точнее можно, но в том случае если это именно своя переменная а не системный регистр)?
Да элементарно: область видимости сокращается, парой строк выше можно увидеть, что именно задается в esi или какой там регистр использовался. Ну, будет у вас вместо
if(abc* ==…
mov esi, abc
…
cmp [esi],…
И парадигма тут ни при чём. Вот смотрите — как бы там не было, но в моём коде чётко понятно что в $user — очевидно хранятся данные пользователя. И это одна строка кода, урывок из контекста.
Ну так и что-то вроде
mov esi, user
mov eax, [esi+_user.name]
не бог весть какая сложность.
Теперь берём отрывок асма.
bswap eax
откуда мне знать что мы храним в eax в данный момент?
Из знания конвенции вызова. Результат работы функции там хранится. Обмен, очевидно, производится из-за разницы endianess.
А почему сравниваем это? Что такое esi и edx? Сравните какое-нибудь
Потому что, очевидно, мы сравниваем полученный нами ЦРЦ с находящимся в буфере. esi — наверняка указатель на буфер, edx — текущий «бегунок», указатель на ЦРЦ в самом буфере. Я не уверен, что это так — cам код не смотрел. Но исходя из отрывка оно так.
И ооп тут ни при чём — изменить user.type (ооп, объект) на user[«type»] (массив, более функциональный подход) — менее понятно не станет.
Нет, простите, при чем. Давайте тогда смоделируем обсуждаемый отрывок:
bool DoComething(char* buf) {
uint CRC;
char* offset;
…
…
CRC = DataCRC32(buf, offset);
SwapHL(&CRC); — тут я просто не знаю, как это в Си делается
if (uint*(buf + offset) == CRC) {
…
…
и будем сравнивать одинаковые парадигмы. Уже разница не так ощутима. А если использовать в FASM макросы if then else, разница станет еще менее заметной.vlreshet
03.01.2017 20:09+7Да элементарно: область видимости сокращается, парой строк выше можно увидеть, что именно задается в esi или какой там регистр использовался. Ну, будет у вас вместо
if(abc* ==…
Пфф, да понятно что парой строк выше можно смотреть, можно вообще весь код перечитать чтобы понять что в одной строке происходит. Да только вот явное — лучше чем неявное. Искать код выше чтобы понять что в переменной ниже — это позволительно только специфическому языку, но никак не «полезному и удобному». С таким же успехом можно прям в опкодах программировать. Ну а что? Если потом взять таблицу кодов — можно будет легко понимать где что. Удобно и полезно. Почему бы не писать на машинных кодах? Зачем вообще ассемблер, эта ненужная прослойка? Машинные коды — не бог весть какая сложность.MacIn
03.01.2017 20:18-1Пфф, да понятно что парой строк выше можно смотреть, можно вообще весь код перечитать чтобы понять что в одной строке происходит. Да только вот явное — лучше чем неявное
Не потребуется. Здесь за счет короткого scope'а это будет в пределах взора. Плюс, человек, который «в теме», знает, какие регистры для чего обычно применяются (тот же esi), и у него не возникнет вопросов подобных вашим, а-ля «а что же в eax после вызова GetCRC32 посредством stdcall?»
это позволительно только специфическому языку, но никак не «полезному и удобному»
А Ассемблер — как раз специфический язык. И сам по себе ни фига не удобный, если сравнивать с ЯВУ.
С таким же успехом можно прям в опкодах программировать. Ну а что? Если потом взять таблицу кодов — можно будет легко понимать где что. Удобно и полезно. Почему бы не писать на машинных кодах? Зачем вообще ассемблер, эта ненужная прослойка? Машинные коды — не бог весть какая сложность.
Нет, в случае именно x86 разница как раз колоссальна, вы просто, видимо, не знаете о чем говорите. Даже если мы отложим в сторону то, что мы говорим о макроассемблере, который по функционалу в чем-то близок к Си, пусть ограниченному подмножеству, то основное преимущество использования мнемокода по сравнению с машинным — это расчет адресов.vlreshet
04.01.2017 10:35+1преимущество использования мнемокода по сравнению с машинным — это расчет адресов.
А преимущество использования ЯВУ против ассемблера — кроссплатформенность, более удобные абстракции, большая встроенная библиотека, и многое другое. Но вы утверждаете что на ассемблере писать — одно удовольствие. Так всё-таки — а почему ж тогда сразу не на опкодах? Если расчитывать адреса вручную — так можно вообще дико оптимизированный код писать. Прям каждый такт выжать. А то сейчас привыкли ленивые программисты медленный код писать, ассемблер всё за них делает…
Понимаете, использовать опкоды вместо ассемблера для написания веб-сайтов — это такая же затея как и использовать ассемблер вместо той же java или php.MacIn
07.01.2017 21:45Понимаете, использовать опкоды вместо ассемблера для написания веб-сайтов — это такая же затея как и использовать ассемблер вместо той же java или php.
Не совсем верная аналогия. Но о неразумности использования ассемблера я автору неоднократно говорил в предыдуших его темах. Еще раз, на всякий случай: не боритесь против ветряных мельниц, я не говорю, что писать сайты на асм вместо php или Java норма, напротив. Парой сообщений выше я уже написал вам, но вы проигнорировали:
Вы пытаетесь доказать, что писать на асме подобные приложения сложно по сравнению с ЯВУ. Это бесполезная борьба с ветряными мельницами. Говоря об удобстве, имеется в виду, что «все не так плохо, как казалось», не более. ИМХО.
А преимущество использования ЯВУ против ассемблера — кроссплатформенность, более удобные абстракции, большая встроенная библиотека, и многое другое.
Разумеется! С этим никто не спорит как бы.
Но вы утверждаете что на ассемблере писать — одно удовольствие.
Не-а. Автор статьи утверждает, что писать на современном макроассемблере fasm — намного приятнее и проще, чем «встарь». По крайней мере, я именно об этом веду разговор.
Так всё-таки — а почему ж тогда сразу не на опкодах? Если расчитывать адреса вручную — так можно вообще дико оптимизированный код писать. Прям каждый такт выжать. А то сейчас привыкли ленивые программисты медленный код писать, ассемблер всё за них делает…
Нет, я же говорю вам: использование современного fasm — это уже ближе к C, чем к традиционному ассемблеру. Такие вот проекты — это показывают. А опкоды и адреса вручную — это шаг в противоположную сторону.
johnfound
08.01.2017 13:16Если расчитывать адреса вручную — так можно вообще дико оптимизированный код писать. Прям каждый такт выжать. А то сейчас привыкли ленивые программисты медленный код писать, ассемблер всё за них делает…
Я понимаю иронию, но она должна опираться на правильных фактов. Нет такие оптимизации, которые нельзя написать в ассемблере. И это отличает ассемблер от ЯВУ.
Ну или дайте пример.
А да и кроссплатформенность это не священная корова. По крайней мере не для всех.
vlreshet
09.01.2017 11:31+1В мире веб — это самая настоящая священная корова. В других сферах — да, там асм может быть востребован, но никак не в веб-разработке.
Jogger
03.01.2017 20:42Ни в статье, ни в заголовке не утверждалось ничего про поддержку и про понятность для других разработчиков. Только про написание. Писать — легко и приятно. Про «читать» — разговора не было.
jcmvbkbc
03.01.2017 15:53+1А вот glibc (GNU C library) нельзя скомпоновать статически.
С чего бы это вдруг?
$ dpkg -L libc6-dev-i386 | grep '\.a'
/usr/lib32/libanl.a
/usr/lib32/libBrokenLocale.a
/usr/lib32/libc.a
/usr/lib32/libc_nonshared.a
/usr/lib32/libcrypt.a
/usr/lib32/libdl.a
/usr/lib32/libg.a
/usr/lib32/libieee.a
/usr/lib32/libm.a
/usr/lib32/libmcheck.a
/usr/lib32/libnsl.a
/usr/lib32/libresolv.a
/usr/lib32/librt.a
/usr/lib32/libutil.a
/usr/lib32/libpthread_nonshared.a
/usr/lib32/libpthread.a
masai
03.01.2017 17:05+1Ждём веб-сайт, написанный на VHDL!
vlreshet
03.01.2017 17:36+5Веб-сайт собранный на транзисторной логике! Нашёл баг — взял паяльник и исправил. Быстро и удобно!
AlexNfr
03.01.2017 22:08+2Не совсем, наверное, то, что вы имели в виду, но ИМХО очень близко: https://habrahabr.ru/post/149928/ ;))
vlreshet
03.01.2017 18:13+5Хотя я и почти не шарю в асме, но даже я вижу что код весьма… кхм… попахивает.
клац
johnfound
03.01.2017 18:22-3То есть, если я захочу поправить внешний вид сайта
Внешний вид поправляется через CSS. Этот HTML отражает семантики сообщения.
oxidmod
03.01.2017 18:25ну и как вы цссом уберете со страницы h1 в каждом меседже?
johnfound
03.01.2017 18:33А почему его убирать? Этот код форматирует сообщение ошибки. Например это: https://board.asm32.info/!message/Habrahabr
jetexe
09.01.2017 16:45Потому что h1 не для этого сделан. Прочитайте ещё за одно про назначение тегов, а не только смотрите как оно отрисовывается
vlreshet
03.01.2017 18:53Нет, я с вами не согласен, HTML тоже отвечает за отображение. Если я захочу сделать мобильную версию — мне не будут нужны изменения back-end, но однозначно понадобится изменить вёрстку. Ну да ладно, пойдём другим путём — допустим, я захотел добавить какой-нибудь внешний виджет, типа Google Analytics. И тут — снова «здраствуйте», я не смогу этого сделать. Ну так ведь? А просто добавить один js скрипт (вот зима началась, решил снежинок добавить). Тоже нет. И я даже знаю почему так всё реализовано. Потому что свой шаблонизатор — нужно писать. Вместо того чтобы использовать его даже не осознавая этого.
johnfound
03.01.2017 19:08+2Потому что свой шаблонизатор — нужно писать
Я не совсем понимаю о чем вы. Наверное терминология подводит. Давайте уточнить? Это шаблоны: https://asm32.info/fossil/repo/asmbb/dir?ci=930d7bcfcd750ee0&name=www/templates
vlreshet
03.01.2017 19:28Так, согласен, с этим погорячился. Правда не совсем понятно зачем у вас тогда куски html в коде, если шаблоны есть. Но это уже не проблема ассемблера да. Тогда извиняюсь.
MacIn
03.01.2017 18:56Это уже не к асму придирка. Так же можно ругаться на php код, в котором напрямую манипулируют базой данных и кодом страницы.
michael_vostrikov
03.01.2017 20:04+1Это придирка к тому, что на асме проще писать так. Для любого действия надо писать больше кода, поэтому проще не выносить код, а писать прямо здесь же, не объявлять класс для сущности, а написать несколько строк с SQL-запросами, не объявлять новую переменную, а использовать регистр eax. На плохой код можно ругаться в любом языке, но на высокоуровневом языке правильно написать проще, за счет того, что служебный код для организации этой правильности скрыт за абстракциями.
MacIn
03.01.2017 20:11-1Можно было вызвать какой-нибудь stdcall GetTemplatedCode, который вернул бы нам строку по шаблону, разница невелика для данного конкретного случая, кмк.
Vasilesk
03.01.2017 21:01Обязательно допишите, как хабраэффект скажется!
johnfound
03.01.2017 21:57+1А пока никак. Все работает, не падает.
Сегодня есть около 5000 уникальных посетителей.
Сервер запускает около 4 копия движка. Иногда 3, иногда несколько больше.
Зарегистрировались 18 человек. Написали несколько десятков тестовых постов.
Попробовали XSS, не получилось.
Попробовали переполнение буфера — не получилось. Буферы не переполнились, но нашелся баг — когда название темы очень длинное, скрипт третирует его как имя файла и возвращает "Forbidden". Скоро исправлю.
johnfound
04.01.2017 20:49+2Буферы не переполнились, но нашелся баг — когда название темы очень длинное, скрипт третирует его как имя файла и возвращает "Forbidden". Скоро исправлю.
Нет не исправлю. Это баг Apache :(. Баг репорт написали в 2008-го года, но баг живой и шевелится. Наверное, потому что на C пишется намного быстрее чем на ассемблере. :D
На lighttpd все работает.
id01
03.01.2017 21:37-1Я занимаюсь сайтами небольшой промежуток времени и для меня было удивлением, что можно использовать вместо php ассемблер, да еще и с такими преимуществами! Статья сильно мотивирует к изучению других языков и способов реализации сайтов.
berezuev
03.01.2017 23:33+1У вас если при регистрации не указать email, выдает серверную ошибку 500
Ну и, в нике дыра XSS)johnfound
03.01.2017 23:44А вот за это спасибо. :) Сейчас заделаю. И XSS тоже.
berezuev
03.01.2017 23:55Что-то вы накосячили с исправлением XSS'а)
Ник должен показываться как и раньше, но код не должен исправляться. К тому же, по логике, логиниться я должен также как и раньше <script>alert...., а не & lt;script& gt;alert(1);& lt;/script& gt; (без пробелов)
А вообще, единственно верным решением этой проблемы было бы на хрен выпилить всех подобных юзеров и поставить ограничение по типу и количеству символов. Ибо не хрен)johnfound
04.01.2017 00:15Что-то вы накосячили с исправлением XSS'а)
Я ничего еще не исправлял. Работаю над кодом. А это так, на время, только отредактировал в БД.
А вообще, единственно верным решением этой проблемы было бы на хрен выпилить всех подобных юзеров и поставить ограничение по типу и количеству символов. Ибо не хрен)
Наверное так и сделаю в конце концов. :) А этого юзера придется стирать.
johnfound
04.01.2017 01:43+1Исправил. Теперь должно быть ОК. И XSS и ошибка 500.
Правда, тот юзер пришлось удалить.
Спасибо, еще раз. :)
Error1024
03.01.2017 23:38+7Знаете, при всех недостатках сайта на ассемблере, он все еще держит хабраэффект, при том что многие, очень многие, не выдерживали столько, я считаю что это победа!
Вне обсуждения практичности, автор крут!Vjatcheslav3345
04.01.2017 00:52Так как ассемблер линковался с библиотеками, то для следующего сайта, наверное, стоит взять ассемблер от от Го. Тогда даже некоторой переносимости можно будет добиться, например.
yesasha
04.01.2017 07:42Дело в том, что ассемблер, при кажущихся преимуществах, в конечном итоге обладает многими недостатками. Кажется, что можно получить офигенное быстродействие, но на практике нужно знать все особенности конкретного процессора и операционной системы! Причём о кросс-платформенности можно забыть! Мы конечно будем пытаться эти проблемы решить через процедуры и макросы и в итоге получим нечто что будет отдалённо напоминать высокоуровневый язык программирования. Но ведь существующие языки уже решили большинство этих проблем и уже генерируют более менее быстрый код.
Ассемблер (х86) я знал не плохо и веб сервер тоже пытался писать. Но потом я понял, что есть 64битные системы и sse наборы инструкций, которые лучше справляются с некоторыми задачами, но изучать сотни новых инструкций мне не хотелось. Поэтому асм был заброшен навсегда (никогда не говори никогда). Когда я вернусь в низкоуровневый мир, я буду «программировать» под плис! Вот уж где низкоуровневость себя действительно оправдывает, а отсутствие кросс-платформенности не так критично.johnfound
04.01.2017 09:16Не все так плохо. Мои тесты показывают, что если программисты пишут не оптимизированный, достаточно сложный код (чтобы оптимизировать было не очевидно), то программы на ассемблере всегда получаются быстрее. И быстрее намного. А не оптимизированный код — это 99.9% всего кода в мире.
Дело в том, что программисты ленивые и всегда пишут так как им легче. Вот, на ассемблере, легче (почти) всегда пишется так как проще, а это (почти) всегда быстрее. Потому что проще, на ассемблере означает и проще для процессора.
А "проще" на ЯВУ, совсем не означает "проще для процессора". Поэтому, чтобы стало быстрее на ЯВУ, нужно прилагать нешуточные усилия, а код получается далеко не читаемым.
yesasha
04.01.2017 10:18yesasha
04.01.2017 10:22И мы с этим «адом» столкнулись http://board.flatassembler.net/topic.php?t=15875
Такая простая процедура, а тема как разрослась!johnfound
04.01.2017 11:12Так тоже бывает, но только когда код нужен совсем наибыстрейший. :D
Когда пишутся глубокие оптимизации, то скорость оптимизированного кода на ассемблере и на C будет приблизительно одинакова. Ну пусть ассемблер будет на 10..20% быстрее. (Но читаемость кода на ассемблере все таки будет лучше).
Но дело в том, что 99% программ в мире, наоборот — совершенно не оптимизированные. Вот там, разница в производительности будет в десятки раз.
Я делал такие эксперименты дважды или трижды и всегда было так. Конечно, программисты должны быть одинаковой квалификации, а программы достаточно большими, чтобы нельзя было заняться сразу глубокими оптимизациями.
Randl
04.01.2017 11:16Ждем от вас в десятки раз более быстрого браузера.
johnfound
04.01.2017 11:24Когда хороший браузер писался в одиночку??? Как соберутся энтузиасты, так сразу и возьмусь.
А пока пишу хорошее IDE и GUI библиотека для FASM.
Веб программирование на ассемблере, просто хобби и повод написания провокационных статей. ;)
bitrixworkshop
04.01.2017 08:42Спасибо за сложный эксперимент. Было бы интересно (откровенно говоря только в этом и интерес) провести полное нагрузочное тестирование этого решения. Будет неплохой ориентир в сравнении с массой других технологий и языков.
Да, сложно предположить, что кто-то возьмется так работать в коммерческой разработке. Но для научных целей — вполне годится.
Видел также статью одного умника на английском языке. Он писал о том, как глупо в наше время писать сайты на чем-то интерпретируемом, а не на C. К сожалению, ссылку не сохранил. Как минимум, после Вашего эксперимента, есть смысл ее перечитать. Там схожие мысли были. Как минимум, они заслуживают внимания.Source
05.01.2017 00:11+3Было бы интересно (откровенно говоря только в этом и интерес) провести полное нагрузочное тестирование этого решения.
Тут есть проблемка… Автор хорошо разбирается в ассемблере, но плохо в веб-программировании… Поэтому сайт получился не особо быстрый с точки зрения пользователя. Для примера запустил простенький тест на LoadImpact. VU load time получился в районе 2.3 секунды (даже всего при 3 посетителях), это уже медленно.
Так что устраивать серьёзное нагрузочное тестирование смысла нет. Веб-сервер скорее всего не настроен должным образом и просто захлебнется под нагрузкой даже не дойдя до кода автора.
Для сравнения у Хабра VU load time в районе 1.7 секунды (быстрее 2 секунд — это хороший результат).PsyHaSTe
09.01.2017 15:06+1Мда. Решил протестировать наш сайт на SharePoint, средний VU load time — 10 секунд, с пиками до 30… Теперь у меня есть метрики для того, чтобы ругать SharePoint, спасибо за классный проверочный сайт.
riky
04.01.2017 15:50+1в чистом виде для веб серверов такая штука мало востребована, тк все таки сложно добавлять функционал и сложно будет развивать. но как стартовая точка для веб фреймворков на асме вполне неплохой вариант.
на таком фреймворке можно было бы писать вебсервера для микроконтроллеров, например веб оболочку для умного дома.
все равно когда нибудь наверное придем к тому что на контроллере обычной лампочки можно будем устанавливать формуы/блоги/магазины.
не рассматриваю проект для себя как нужную платформу для какого то дела, но это хорошая стартовая точка для дальнейшего развития, чего и желаю автору от всей души.tyomitch
05.01.2017 10:38+2все равно когда нибудь наверное придем к тому что на контроллере обычной лампочки можно будем устанавливать формуы/блоги/магазины.
На этаж выше меня сидят IoT-разработчики, которые действительно пишут веб-приложения, встроенные в лампочки.
Уверяю вас, они пишут на C и C++, потому что им переносимость между разными контроллерами важнее потенциальной экономии килобайта памяти.
photocritic
04.01.2017 15:50-4Чувак! Ты для меня Бог асма! И не обращай внимание на «обсеральцев». Твори!
IDMan
04.01.2017 23:26+1Если написать в сообществе программистов, что вы собрались писать форум на ассемблере, чтобы он работал на дешевом хостинге, есть довольной большой шанс, что вам придёт несколько небольших пожертвований. Но с поточными расценками на хостинг даже небольших пожертвований хватит, чтобы этот хостинг держал пару десятков тысяч уникальных посетителей в день год или больше.
Если серьёзно, вы играете на поле, где ваш подход имеет немного смысла — достать 100 кусков текста с бд, отформатировать и отослать клиенту. Это работа базы даных, шаблонизатора, веб-сервера, и немного прослойки вроде вашего кода. Я на rake напишу такой код в обход фреймворков и он заработает на очень плохом хостинге, хотя и проиграет пару мс вашему варианту.
Но. Если вы бекенд, допустим, Призмы, если вы считаете в реальном времени кластеризацию данных от клиента, если вы строите маршрут алгоритмом, который не зависит или слабо зависит от БД, если вам надо посчитать уникальный набор чисел, которые идентифицируют человека на фото относительно пред-рассчитанного базиса, и вообще найти человека на фото — вы сможете обойти конкурентов всерьёз. Не знаю, насколько вы обойдёте tensorflow который на c + python, но это имеет на порядок больше смысла, чем собирать тексты с бд в единый кусок HTML.oxidmod
04.01.2017 23:49+4И можно написать все это на С (или зефире) в виде пхп экстеншина. Запустить в виде демона под супервизором и поиметь плюсы как быстрого написания бойлерплейта ( 100500 фреймворков/ либ на пакаджисте) так и производительность.
Зы. Со стороны "гляди как я могу" безусловно круто, но практическая ценность как-то ускользает от меня.
Ззы. Пыха и риалтайм это конечно стеб.IDMan
05.01.2017 00:40Мне кажется, несколькими годами раньше на Хабре товарищ написал программу, которая слушала порт и отвечала на некий перечень запросов. Это позволит пропустить стадию модуля к apache/nginx, хотя и оставит на сладкое работу в режиме «одна программа на процессор», вместо ненужной и дорогой прослойки ОС. Это явно не история «держать тысячи клиентов на дешёвом хостинге», но нет предела совершенству.
IDMan
05.01.2017 00:46Как ни крути, на любом уровне работа с бд и шаблонизатором убьёт все выигранное преимущество, зато в чистых независимых вычислениях на нагружённом сервере может иметь смысл. Конечно, при наличии клиента/пользователей, готовых оплатить пиршество человеческой мысли (и тогда можно даже позавидовать автору).
terryP
05.01.2017 11:04+2чистых независимых вычислениях на нагружённом сервере
У нас был подобный проект, когда не было ни бд, ни шаблонов, просто очень быстрый код, который должен давать очень быстрый ответ на множество запросов «клиентов» из веба. В общем, несмотря на то что код был на Java, мы в первую очередь уткнулись в максимально возможное кол-во одновременных соединений по TCP к серверу, а переходит на UDP было слишком сложно. Скорость кода тут оказалось делом десятым, от перехода к C или ассемблеру мы ничего бы не выиграли.
Да, если требовалось много сложных вычислений, то С++ или С нам бы помогли, но это не имеет отношения в вебу, достаточно переписать только критичную часть.
johnfound
05.01.2017 00:39Если написать в сообществе программистов, что вы собрались писать форум на ассемблере, чтобы он работал на дешевом хостинге, есть довольной большой шанс, что вам придёт несколько небольших пожертвований. Но с поточными расценками на хостинг даже небольших пожертвований хватит, чтобы этот хостинг держал пару десятков тысяч уникальных посетителей в день год или больше.
Дело не в форуме. Мне форум не нужен как таковой. То что я инсталлировал, просто демо, чтобы можно было потрогать руками.
И если дело в одном форуме то конечно заплати и спи спокойно. Но дело здесь в принципе. Если сделать бакенд вдвое легче (а AsmBB более чем вдвое легче эквивалента на PHP) то при прочих равных вы сможете обслуживать за те же деньги вдвое больше посетителей. Ну или сэкономить половину бюджета. А половина, иногда может быть много миллионов. Не так ли?
Я на rake напишу такой код в обход фреймворков и он заработает на очень плохом хостинге, хотя и проиграет пару мс вашему варианту.
Я в комментариях уже наверное 100500 раз прочитал, как на языке X и Y все это пишется за 2 часа и будет конечно и быстрее и память будет жрать меньше и поддерживаться лучше.
И языки были и Java и PHP и C. Вот теперь rake (никогда не слышал, может это и не язык).
Только ведь, не пишут, только болтают.
Потому что реальный проект просто так не пишется. Тем более за 2 часа или 2 дня. Там многое чего нужно придумывать.
А вот вы возмите и напишите. Сделайте хранилище кода, а мы посмотрим как быстро у вас получится. Поставьте где нибудь демо.
А мы посетим, зарегистрируемся. Понагрузим хабра-эффектом. Поищем XSS уязвимостей. Осмотрим на каком хостинге это установлено. И вывод сам сделается.
Но ведь не напишете.
kiaplayer
05.01.2017 10:00+2Но дело здесь в принципе. Если сделать бакенд вдвое легче (а AsmBB более чем вдвое легче эквивалента на PHP) то при прочих равных вы сможете обслуживать за те же деньги вдвое больше посетителей. Ну или сэкономить половину бюджета. А половина, иногда может быть много миллионов. Не так ли?
Мне кажется, это ошибочное предположение, что основная часть бюджета тратится на вычислительные ресурсы. Основные затраты — это разработка и сопровождение.
Конечно, если проект написан раз и навсегда, и больше в нем на 100% нет никаких синтаксических и логических ошибок, то да — бюджет будет тратиться только на ресурсы сервера. Но я в природе таких проектов еще не встречал :)
vlreshet
05.01.2017 10:38+2Извините, но вы не правы. Вы же не будете спорить что разработка на том же php быстрее чем на асме? Не будете (вы сами об этом говорили). Теперь смотрите живой пример — есть проект, на нём 5 девелоперов по 20$ час. Итого — 16к долларов в месяц. И есть сервер + бд на амазоне. Мощный, должен сказать, сервер. И бд очень неплохая (сейчас дамп базы весит около 60гб). И в месяц аренда этого всего обходится меньше чем 5к долларов. Если мы перепишем всё на асме, и ускорим даже в 5 раз — то экономия на сервере составит ну пусть 2к долларов (а у нас и так всё упирается в бд, так что скорости особо не увидим), а затраты на разработчиков — возростут на 5-8к. Не будет экономии. Как уже говорили сотни комментаторов выше — в наше время человеческий ресурс стоит дороже железа. И никакой бизнес не станет вкладывать в разработчиков десятки тысяч, вместо единоразового обновления железа. Подход с асмом имеет смысл там где он даст огромный прирост скорости. А в веб-среде, с её базами данных и http протоколом — этого выигрыша не будет.
terryP
05.01.2017 11:14+2Все ещё веселее, количество одновременных TCP соединений к серверу весьма ограничено. То есть, если код не лезет в базу, не работает по сети, а только отдает некоторые данные из памяти, то почти любой язык будет работать быстрее чем к серверу будут приходит запросы. А если активно лазить в базу, сеть, читать/писать файлы то основное время сервер будет занят записью на диск, скорость кода большой роли не сыграет. Другими словами, на любом более-менее серьезном языке при работе с вебом и прямых руках узким горлышком окажется не скорость кода, а либо работа базы данных, либо количество одновременных соединений, либо работа с файлами и сетью.
Поэтому переписав все на асме получится практически та же стоимость сервера, хорошо если выигрыш будет 25-30%.
johnfound
05.01.2017 11:32Все это так, но не совсем.
Ваши все вычисления предполагают, что разработчики будут работать в одинаковом темпе, во все время жизни проекта. Работает сервер, тысячи посетители посещают сайт, читают, пишут, общаются, а в то же время 5 девелоперы, каждый день, 8 часов подряд, пишут новый код, фиксят баги и т.д. И так в продолжении 10..20 лет.
Но ведь так не бывает. Разработка всегда движется по экспоненте — в начале все работают много, потом работа уменьшается и приоритеты смещаются — примерно исправляются ошибки.
Во вторых, вы пишете насчет разработки очень специализированного софта, который будет работать на одном сервере и нигде больше. Но так тоже далеко не всегда. Если взять например SMF — там тоже разработчики работают все время (и опять интенсивность работ совсем не всегда одинакова), но их программа установлена на десятки тысячи серверов и суммарные расходы на хостинг просто сумасшедшие.
vlreshet
05.01.2017 11:51+3Разработка всегда движется по экспоненте
Поспорю, разработка не всегда движется по экспоненте. Если написать проект, а потом только фиксить — то да. А если активно его развивать вместо стойки на месте — то темп нисколько не падает. С чего ему падать? Кодовая база растёт, всплывают старые баги, появляются новые. Я бы сказал что со временем поддержка и разработка проекта становится только сложнее и сложнее.
который будет работать на одном сервере и нигде больше
Но, если нам понадобится масштабируемость — мы сделаем это сверхбыстро. Создаём копию сервера, подключаем к общей бд, ставим балансировщик — готово. А вот как раз в случае с ассемблером — нельзя просто так взять, и использовать любой сервер. Перескочить с сервера на amd на сервер с intel, например.
Ну правда, ну смотрите — бизнес всегда пытается выбрать самый оптимальный путь развития. Если ассемблер даёт такую бешенную пользу и экономию — то почему ни один современный гигант
не переводит всю разработку на асм, а в мире бешенными темпами набирает скорость JS? Ну правда, если так всё хорошо как вы описываете — почему же никто не использует это в промышленных масштабах? Да потому что в наше время кроссплатформенность и человеческий ресурс сильно важнее железа. Железо всегда можно докупить. Банальный пример — напишет кто-то огромный проект под процессоры amd. И всё хорошо. Тут бац — интел совершает прорыв, и выкатывает в продажу в 10 раз более быстрый проц, и при этом дешевле. И что — всё, капец, переписывать весь проект?
Был бы асм экономически выгоднее — его бы уже все использовали. И всё тут. Академические и научные интересы — да, тут асм пойдёт. Реальная бизнес-разработка — не прокатит.terryP
05.01.2017 12:03+1почему же никто не использует это в промышленных масштабах? Да потому что в наше время кроссплатформенность и человеческий ресурс сильно важнее железа. Железо всегда можно докупить.
У сервера есть несколько узких мест:
1. Максимальное количество открытых соединений,
2. Скорость записи на диск (базы данных, файлы),
3. Скорость обмены с другими серверами (удаленный базы данных, микросервисы),
4. Память (читай кэши),
5. Канал трафика,
6. Процессор,
Так вот использование низкоуровневого языка влияет только на процессор, на память он виляет слабо, исходный код это меньшая часть памяти, большая часть съедают структуры данных и кэши (кэши вебсерверов, кэши баз данных, объекты бизнес логики и т.п.). А современное железо достаточно производительно, и в типовом бекеэнде веб приложений процессор редко бывает узким местом. Ускорять код, когда процессор и так никогда не бывает загружен даже на 50%, можно, но это мало чем поможет если пользователи уперлись в трафик или скорость записи на диск. Отсюда огромную экономию низкоуровеневые языки в вебе дают редко (и обычно проще переписать только кричиный код на таком языке).vlreshet
05.01.2017 12:06+5Об этом я ранее тоже говорил. Да все говорили. Всем понятно что адекватно написанный сайт всегда упирается не в скорость кода а в бд, фс, и сетевые протоколы, но поклонникам ассемблера хоть в лоб хоть по лбу — ассемблер быстрый и всё тут. А то что эта скорость такой ценой не нужна — их не волнует.
Source
05.01.2017 15:09+3Ассемблер то быстрый, а сайт получился медленный:
При оптимизации сайтов главная метрика — load time, а не время генерации на сервере. Да и временем генерации ответа за миллисекунды сложно удивить, было бы меньше 1 ms — было бы круто. А текущие результаты (6 — 30 ms) можно и на ЯВУ воспроизвести. Т.е. в теории выигрыш от применения ассемблера должен быть, но на данном примере его не видно.
johnfound
05.01.2017 15:210.97с это долго? А сравниваете с чем?
Source
05.01.2017 15:47+3Это не так чтобы очень долго, но и не быстро. Считается, что меньше 2 секунд — это приемлемый результат для среднестатистического сайта.
Но, учитывая достаточно простой дизайн (малое кол-во картинок и CSS) и практически пустую БД, можно было ожидать хотя бы в районе 0.5 секунды.
Обратите внимание, что у Вас плохие показатели по Initial connection и по TTFB. Не факт, что Вы можете на них повлиять, т.к. они зависят от настроек сервера. Но дело в том, что они добавляют сотни миллисекунд оверхеда, на фоне которых экономия пары миллисекунд за счёт применения ассемблера совсем потерялась.
michael_vostrikov
05.01.2017 15:17+3А вот вы возмите и напишите. Сделайте хранилище кода, а мы посмотрим как быстро у вас получится. Поставьте где нибудь демо.
А я вот взял и написал.
https://github.com/michael-vostrikov/asm-bb
http://michae9j.bget.ru/test/asm-bb/
Логин: admin
Пароль: 123456
В сумме ушло часов 10-12. Не знаю насчет хабраэффекта, тариф минимальный, посмотрим сколько выдержит. Функционал скопирован не полностью, но для proof of concept хватит. Нет загрузки файлов, закрепления тредов, редактирования/удаления комментов и тредов, профиля пользователя, и прочих полезных мелочей. На них оценка от одного до нескольких дней, в зависимости от требований. Для комментов используется не markdown, а HTML с обработкой через HTMLPurifier. Да, специально для вас, коммит с добавлением поля для скомпилированного HTML.
vlreshet
05.01.2017 15:25Имхо, стоило взять микрофреймворк типа lumen или silex, либо же вообще phalcon. Брать Yii чтобы показать производительность php — весьма так себе идея… Ещё и php 5.5.
michael_vostrikov
05.01.2017 15:51Смысл был в том, чтобы показать скорость разработки. PHP явно медленнее ассемблера работает, зачем тут производительность сравнивать.
Я в комментариях уже наверное 100500 раз прочитал, как на языке X и Y все это пишется за 2 часа. Только ведь, не пишут, только болтают. Потому что реальный проект просто так не пишется. Тем более за 2 часа или 2 дня.
Source
05.01.2017 16:09+1Ну, кстати, load time у Вас получился 0.35 секунды (против 0.97 у демо asmbb), даже несмотря на то, что оставили без объединения 3 CSS и 3 JS-файла. Так что отзывчивость сайта оказалась почти в 3 раза лучше, просто за счёт более хорошего хостинга.
johnfound
05.01.2017 16:23А скорость разработки пока так:
3 дня и 27 коммитов, а версия, согласитесь что сырая. (Кстати, вы начали писать 3-его Января?!)
У меня, для v1.0 понадобилось 54 коммитов.
Так что если привести эту работу к v1.0 по моему брой коммитов будет очень близко к те 54.
michael_vostrikov
05.01.2017 16:40+4Я писал 3 января 1 час вечером, на следующее утро решил, что че-то неохота возиться, закоммитил оставшиеся изменения, потом сегодня утром прочитал ваш коммент и решил все-таки доделать.
У меня коммиты помельче, и это вообще не показатель. Если я их в 3 коммита объединю, разве что-то изменится?
johnfound
05.01.2017 15:41О! Уважаю! Теперь давайте приводить в вид, которого можно было сравнивать:
- Script runtime добавьте. Как иначе сравнивать будем.
- markdown, компилировать сложно и медленно. Так что форматирование через HTML, несколько не то. Нет готовых библиотек что ли?
- Добавьте счетчик "read count" на каждом посте — это важно, потому что делает запись в базе данных на каждом посте.
- Индикация непрочитанных тем — это тоже совсем не тривиальная проблема, которой я решал нескольких дней.
Функционал скопирован не полностью, но для proof of concept хватит.
Насчет оценки быстродействия может и хватит — но, конечно если добавите измеритель (см. 1)
Но насчет сравнения времени разработки не хватит, потому что у вас нет:
- Редакция и удаление темы.
- Редакция потребительского профиля. Аватары.
- Поддержка сессии. Например я не могу разлогинится.
- Администраторская панель. У меня их 2 — общие настройки и SQLite конзоль.
- Права доступа. Сейчас, администратор никак не отличается от потребителей.
А чтобы сделать все это нужно время. И так эти 12 часов превратятся в намного больше.
michael_vostrikov
05.01.2017 16:331. Смысл был в том, чтобы показать скорость разработки аналогичного проекта на языке высокого уровня. Я не ставил себе цель сравнивать миллисекунды.
2. Markdown для форматирования постов выбрали вы, мне было удобнее взять HTML. Форматирование постов есть? Есть.
3. См. п.1, цель не в быстродействии.
4. Не, спасибо. Еще один день неохота на это тратить. Лучше опишите проблемы, которые у вас возникли.
1. Если посмотрите в коммиты, там был код для редактирования и удаления. Я его убрал, потому что неохота было делать интерфейс.
2. Да, это самая долгая часть из оставшегося.
3. Если есть логин, значит есть и сессия. Возможно, у вас скрипты отключены. Кстати, вы в курсе, что не рекомендуется делать logout по GET-запросу?
4. Админка есть, только там ничего нет: http://michae9j.bget.ru/test/asm-bb/admin/. Отладочная панель есть в debug-режиме, сейчас включен production-режим.
5. Это не так долго, есть готовый компонент для управления доступом на основе ролей. Тут смысл не в том, что он готовый, а вы писали сами, а том, что подключить новый компонент в проект на ЯВУ гораздо проще.
А чтобы сделать все это нужно время. И так эти 12 часов превратятся в намного больше.
По текущему функционалу можно оценить время остальных доработок по пунктам 2,4,5. Оценку я уже дал — несколько дней, максимум пусть будет неделя. Но как я уже сказал, больше время на это тратить не хочется.
Этим проектом я хотел показать преимущества от разработки на ЯВУ. Время на разработку уходит в несколько раз меньше (счет идет на дни, а не на месяцы), решение получается более переносимое (можно подключить любую БД), сложность и время внесения изменений гораздо ниже (пример с добавлением поля), решение будет гораздо понятнее для новых разработчиков.
Из преимуществ ассемблера только призрачная скорость выполнения кода.johnfound
05.01.2017 22:04- Смысл был в том, чтобы показать скорость разработки аналогичного проекта на языке высокого уровня. Я не ставил себе цель сравнивать миллисекунды.
Я тоже провел эксперимент. Мне очень трудно считать сколько времени отнимет та или другая задача. Поэтому, решил реализовать кеширование HTTP (как советовали), но измерить точное время работы.
Эта задача очень подходит под эксперимент, потому что код которого надо было менять писался весной и больше никогда не менялся (ну может быть были некоторые багфиксы). Так что задача получается очень реалистична. Надо менять код, которой писался давным давно, надо сориентироваться и потом поменять его.
Получилось ровно 78 минут.
Можно было и быстрее, но мне не хотелось удалять старую БД, поэтому пришлось писать и код который рендировал все старые посты на сервере.
IDMan
05.01.2017 20:44Я сравнил написание asm с ruby кодом без фреймворков, потому что в задачах слепить тексты с базы данных в HTML они почти равные — все преимущество скушает бд. Я смотрю например в лог выполнения запроса в Rails, довольно таки большом фреймворке с кучей магии, динамических методов, и стектрейсе на 50 вызовов — запрос в БД занимает больше времени, чем работа этой махины.
В то же время, на задаче кластеризации данных от датчиков, которые поступают непрерывным потоком, руби берет 30 секунд на порцию. На python и tensorflow/или аналог должно отработать в разы быстрее. Вы бы з хорошим знанием ассемблера код под конкретную задачу разогнали бы до нескольких секунд. А это задача, которая начальный по цене хостинг грузит 100% почти треть времени (причём это ограниченная по объёме выборка данных). Я вижу, как решения, которые работают быстрее, могут принести реальную пользу. Но зачем, кроме фана, нужен ассемблер в задаче, где нет никаких вычислений, я все же не понимаю.johnfound
05.01.2017 21:48+1Но зачем, кроме фана, нужен ассемблер в задаче, где нет никаких вычислений, я все же не понимаю.
А разве фан, это плохо?
Я пишу на ассемблере много чего. Часть моего кода (например программы управления промышленного оборудования) закрытая. Можно посмотреть некоторые картинки здесь.
A вообще, больше всего нравится писать десктоп приложения. Но написание AsmBB было мне очень полезно. Я научил что это FastCGI, SMTP, XSS и много всего из мира WWW/HTTP. Разве это плохо?
IDMan
05.01.2017 23:29Я говорил не о том, что решение написать форум на ассемблере это плохо, а о том, что вы раскрываете потенциал ассемблера в области, в которой раскрыть его в полной мере невозможно. Под областью я имею ввиду не веб, а контентные сайты, где нет обработки текстов, вычислений, математики. Возможно, хотя, это получится тот же десктоп, только на сервере.
Используя рекламную площадь комментария, попрошу совета. Как проще всего зайти в ассемблер на уровне «оптимизация некоторых функций» программисту, который кроме программирования на си микроконтроллера, работал только с высокоуровневыми языками?johnfound
05.01.2017 23:42Как проще всего зайти в ассембер на уровне «оптимизация некоторых функций» программисту, который кроме программирования на си микроконтроллера, работал только с высокоуровневыми языками?
"Зайти" на уровне "оптимизация" не получится. Оптимизация, это высший пилотаж. Поэтому лучше просто начать писать на ассемблере неоптимальный код. Скачайте FASM или Fresh IDE, почитайте примеры которые в архиве. Напишите небольшие программы, которые вам нужны.
Общайтесь на форуме FASM. Спрашивайте на stackoverflow. Постепенно все образуется.
Не стоит делать то, что многие рекомендуют — читать выход компилятора на C. Люди пишут на ассемблере совершенно по другому.
Siemargl
05.01.2017 23:46Не совсем. Старый Борланд, MSVC, TinyC нормально транслируют в asm, человеколюбиво.
А вот gcc…johnfound
06.01.2017 00:04Дело не в то как компилятор компилирует, а в то что компилирует он код, который написан на ЯВУ. Вся логика у этого кода не ассемблерная, а именно логика ЯВУ. Человек, который писал этот код, скорее всего написал эго так как легче и лучше именно C или на Паскаль.
Когда человек пишет на ассемблер, он пишет так как легче и лучше писать именно на ассемблере.
Siemargl
06.01.2017 02:28Логика у компилятора та, что вложил его создатель.
Собственно, и Асм и С и Паскаль императивные языки и, за исключением ньюансов по использованию регистров, логика одинаковая (я только не знаю, что курили создатели gcc=).
Для более совершенных ЯВУ, уже нет такого подобия.
Хотя я и видел примеры, что на ассемблере можно весьма наплевательски нарушать все правила структурного программирования Дейкстры, но эти программы потом весьма тяжело читаются и сопровождаются.johnfound
06.01.2017 09:33Я не говорю о компиляторах — они делают свою работу прекрасно.
Я говорю о логике ЯВУ. Давайте дам пример. Пусть требуется сделать поиск строки в массиве строк. На каждом ЯВУ, это проще всего сделать через цикл, ну или (если массив сортирован) через бинарный поиск. Потому что в ЯВУ есть сравнение строк. Там можно написать:
if MyString = Arr[i] then return i
Конечно это будет не так быстро, но коротко, ясно и естественно. А все знают что “Premature optimization is the root of all evil”. Поэтому так и оставят.
А вот, на ассемблере, этот подход уже не так удобен. Потому что там сравнение строк нет. Придется сравнивать побайтно. Появятся вложенные циклы. Не хватит регистров. Читаемость кода ухудшится.
Программист, который раньше писал на ЯВУ так и напишет. Потому что по другому он не мыслит. Он знает что это самое простое решение, а то что получается плохо, это из за дурацкого ассемблера.
А на ассемблере, намного проще сделать поиск через хеш таблицу. Потому что там все циклы одиночные, короткие и ясные. Код получится намного проще и понятнее. Даже совершенно наивная реализация хеш функции сделает поиск намного быстрее. И заметьте — никакие ранние оптимизации — пишем так как проще, а не думаем о скорости. Она получается сама.
Этот пример не высосан из пальца. Именно так получилось однажды, когда организовали битвы "assembly vs c++" на одном болгарском форуме. Надо было сделать парсер markdown (кстати, парсер в AsmBB результат именно этой битвы). Так первая версия на ассемблере была в 80 раз быстрее чем на C++, только из за этого.
GennPen
06.01.2017 09:55Если программист имеет хоть немного мозгов, то он понимает, что сравнивать побуквенно — это лишняя трата ресурсов. Да и компиляторы уже давно в большинстве случаев сравнивают хеши.
gearbox
06.01.2017 17:20Посчитать хэш — в любом случае полный проход по строке. Сравнивать побайтово — полный проход только в худшем случае. В среднем — 1/2S. Так, а что там про мозги программиста было?
GennPen
06.01.2017 19:35Считать хеш можно только при присваивании значения переменной.
gearbox
06.01.2017 21:51И? Это как то отменяет полный проход по строке? Сравнение по хэшу имеет смысл когда много сравнений в неизменяемом множестве строк, но это еще надо удачно подобрать хэш функцию.
GennPen
06.01.2017 22:45Но и на ассемблере нужно подобрать такую хеш функцию чтобы работала быстро, если сравнивать по хешу.
А на ассемблере, намного проще сделать поиск через хеш таблицу. Потому что там все циклы одиночные, короткие и ясные. Код получится намного проще и понятнее. Даже совершенно наивная реализация хеш функции сделает поиск намного быстрее.
johnfound
06.01.2017 23:43Но и на ассемблере нужно подобрать такую хеш функцию чтобы работала быстро, если сравнивать по хешу.
Хеш вычисляется только однажды, а сравнение делается с каждой строке в массиве. Посмотрите ниже — я дал пример.
gearbox
07.01.2017 01:07GennPenjohnfound
Я не отрицаю преимущество использования хэш функции в частном случае:
Сравнение по хэшу имеет смысл когда много сравнений в неизменяемом множестве строк,
Я лишь возражаю против вот этого обобщения:
то он понимает, что сравнивать побуквенно — это лишняя трата ресурсов
Потому что в общем случае сравнивать побуквенно эффективнее чем считать и сравнивать хэши.johnfound
07.01.2017 01:25Сравнение по хэшу имеет смысл когда много сравнений в неизменяемом множестве строк,
А почему в "неизменяемом"? Вполне может быть и изменяемом.
Потому что в общем случае сравнивать побуквенно эффективнее чем считать и сравнивать хэши.
Нет не так. Побуквенное сравнение будет эффективнее только в некоторых частных случаях. Например когда массив очень небольшой. Но когда массив небольшой и почти сортивован, даже сортировка пузырком может быть быстрее quick сорта.
Но дело в том, что каждой небольшой массив всегда вырастает после две версии программы. ;)
Кстати, мне кажется, что вы не совсем понимаете как работает хеш-таблица. Там нет поиска в массиве и нет циклов, кроме однократного вычисления хеша.
Azoh
07.01.2017 03:04Кстати, мне кажется, что вы не совсем понимаете как работает хеш-таблица. Там нет поиска в массиве и нет циклов, кроме однократного вычисления хеша.
А что происходит в случае коллизий?
Но дело в том, что каждой небольшой массив всегда вырастает после две версии программы. ;)
Заменить линейный поиск на поиск в хэш-таблице — дело 5 минут (если код хорошо спроектирован).
Но часто выясняется более веселое. Нужно сравнивать строки не как попало, а по умному.
Во-первых, строки бывают в юникоде. Простое сравнение уже не всегда работает. Хеш-функция должна это учесть.
Во-вторых, сравнивать нужно без учета регистра. Иногда. Опять же простым сравнением не получается. Хеш-функция должна это учесть и это.
Для дополнительного веселья выясняется, что один из поддерживаемых языков имеет странные правила. И сравнивать строки нужно с учетом этих правил. Хеш-функция разрастается в монстра.
И тут уже все сильно зависит от доступного инструментария. Многие ЯВУ содержат встроенные средства для работы со всем этим. Хотя тот же C++ нет, но можно что-то найти.
johnfound
07.01.2017 03:40А что происходит в случае коллизий?
Колизии происходят очень нечасто и поэтому не влияют на производительности алгоритма. А если случаются часто, то надо исправлять баги.
Даже не буду комментировать насчет 5 минут. Вы ещо операционку состряпаете за 5 минут на JS. :P
Но часто выясняется более веселое. Нужно сравнивать строки не как попало, а по умному.
Конечно, когда пишется программа, применяются разные алгоритмы.
Но не понятно, почему этот очевидный факт должен доказывать чего нибудь насчет вполне конкретного примера??? Или сравнивая побайтно легче сделать сравнение UTF-8 с combining characters (например (U+0061)+(U+0301) == (U+00E1))? Не думаю.
Azoh
07.01.2017 04:46А очевидный факт должен показать, что из примера "поиск строки в массиве строк" совсем не следует оправданность применения хэш-таблиц.
Ситуации могут быть разные.
Если нам требуется выполнить одноразовый поиск в массиве, то очень запросто может оказаться, что проход по массиву со сравнением будет куда быстрее, чем создание хэш-таблицы (или хэш-множества) из-за высокой трудоемкости первоначального создания хэш-таблицы.
Есть ситуации, когда хэш-таблицы эффективнее. И их использование следует из логики выполнения, не из удобства для реализации. Если разработчик не увидел этого, это говорит о разработчике, не о языке.
gearbox
07.01.2017 11:01Да не, как работают хэши я в курсе. Смотрите. Для того что бы вычислить хэш, помимо вычислений — надо выбрать ВСЮ строку из памяти. Для того что бы сравнить две строки — в общем случае надо выбрать ПОЛОВИНУ длины каждой строки. И это не учитывая того что побайтовое сравнение почти всегда можно распараллелить а вычисление хэша можно распараллелить только если хэш функция позволяет.
С учетом этого становится очевидно что использование хэша выгодно когда КАЖДАЯ строка используется в сравнении несколько раз (или в нескольких сравнениях) Если надо один раз сравнить строку по множеству — смысла считать хэш нет. Ну и, как выше отметили — коллизии. Чем меньшую вероятность коллизии дает хэш функция, тем она, как правило, более ресурсоемкая. Проблемы с кодировками или регистром решаются нормализацией строки, их я пропускаю.
Да, и мы еще не рассматривали суффиксное дерево, которое на многих случаях пододвинет и брутальное сравнение и хэши. К чему это я. Просто не надо вот ТАК обобщать:
то он понимает, что сравнивать побуквенно — это лишняя трата ресурсов
Это не Вам, это автору этих слов. Без агрессии, просто объясняю свою позицию.johnfound
07.01.2017 12:23С учетом этого становится очевидно что использование хэша выгодно когда КАЖДАЯ строка используется в сравнении несколько раз (или в нескольких сравнениях) Если надо один раз сравнить строку по множеству — смысла считать хэш нет.
Мне все-таки кажется, что вы не понимаете как работает хеш-таблица. Мне кажется, что вы думаете что там в массиве кроме строки сохраняется и хеш этой строки и когда нужно сравнить строку по множеству мы циклим по массиву, только сравниваем не строка с строкой, а хеш с хешем.
Поиск строки в хеш таблицу состоится от:
- Вычисление хеша строки которую будем сравнивать — пусть будет h
- Смотрим в hash_table[h] — если там 0 то строки нет в массиве. Если там указатель <>0 — то строка есть в массиве.
Это все, даже если в таблице есть миллиардов строк. Поиск будет занимать только одну проверку в массиве. Сложность О(1).
Я сознательно опустил проверки на коллизии, но они не уменьшают скорость, потому что случаются нечасто. Разрешение коллизии просто немножко удлиняет код. Этот код в большинстве случаев не выполняется.
gearbox
07.01.2017 16:23ок. Смотрите.
>Вычисление хеша строки которую будем сравнивать — пусть будет h
Строку выбираем? Что бы вычислить хэш. Выбираем. Всю? Всю.
Сравниваем побайтово. Один раз. Строку Выбираем? Выбираем. Всю? Нет. Сатистически — 1/2 от средней длины строк. Так как сравниваем две строки — то в среднем выборка равна средней длине строки. При разовом сравнении — побайтовое сравнение выгоднее.
Дальше. Эффективность хэш таблиц проявляется при МНОГОКРАТНОМ сравнении строк (сортировки, выборки). Но тут конкурент — суффиксное дерево. На котором не надо строить на каждой строке хэш, а надо строить дерево, которое, при достаточно плотном распределении строк может памяти занимать меньше чем исходный набор строк. И при таком сравнении:
Смотрим в hash_table[h] — если там 0 то строки нет в массиве. Если там указатель <>0 — то строка есть в массиве.
по любому получаем засаду — либо у нас маленький хэш (32 разряда — это ОЧЕНЬ маленький хэш для строк) с большой вероятностью коллизий, либо у нас нормальный хэш, но тогда проблемы с распределением памяти (и виртуальная память тут не спасет — даже одна строка будет вызывать необходимость выделить физическую страницу в памяти). И тогда нам нужно либо иметь более умный алгоритм (учитывающий в том числе и коллизии) либо вообще не хэши. То есть для принятия решения (какой алгоритм применять) надо учитывать среднюю длину строки, плотность распределения, объем памяти. Собственно то, что делают движки баз данных, применяя оптимизации на основании собранной статистики на прогретых базах.
Поймите, я уже третье сообщение пытаюсь донести — я не против хэшей. И не за. Есть задачи на которых они работают хорошо, есть где не очень. Я вообще не про хэши начал диалог. Я попытался отметить тот факт что простое сравнение не всегда сливает хэшам и прочим алгоритмам. Есть большое множество задач, где простое сравнение работает лучше остальных. И глупо говорить что использовать его — пустая трата ресурсов. Глупо том смысле, что это неоправданное обобщение.
michael_vostrikov
06.01.2017 19:01А приведите код для поиска через хеш-таблицу? Как-то не очень верится, что он намного проще "=" или "rep cmpsb". И на ЯВУ тоже можно хеш посчитать, если ставить цель именно оптимизировать выполнение.
johnfound
06.01.2017 20:47"rep cmpsb"
Так сравнивать строки обычно нельзя. Потому что длина неизвестна.
А приведите код для поиска через хеш-таблицу? Как-то не очень верится, что он намного проще "=" или "rep cmpsb"
Напишу. Только проще <> короче. Код там будет несколько больше, но его будет проще писать и читать. И конечно будет намного быстрее.
И на ЯВУ тоже можно хеш посчитать, если ставить цель именно оптимизировать выполнение.
Конечно можно. Но там это будет "оптимизация" — то что делается когда иначе никак нельзя. А на ассемблере, это будет проще написать, не думая о производительности.
michael_vostrikov
07.01.2017 03:49+1Так сравнивать строки обычно нельзя. Потому что длина неизвестна.
Ну так и хеш неизвестен. Вместо вычисления хеша можно вычислять длину строки (это тоже вариант хеш-функции). Или вообще вычислять заранее и хранить вместе со строкой. Вы мыслите в алгоритмах ассемблера, а это уже ближе к ООП.
И начинать можно со сравнения длин строк. И сравнивать с конца. Так что неизвестно, какой код будет быстрее работать. Поэтому преждевременная оптимизация — зло.
Код там будет несколько больше, но его будет проще писать и читать.
Чем это проще чтения знака "="?
Но там это будет "оптимизация" — то что делается когда иначе никак нельзя.
Правильно. Потому что преждевременная оптимизация — зло.
johnfound
06.01.2017 21:55Ну вот один простой пример. Жаль что нет подсветки синтаксиса. Здесь даю только процедуры которые делают работу.
Весь тестовой проект можно скачать здесь. Компилируется в Fresh IDE для Windows, Linux или KolibriOS.
uglobal hash_table rd 65536 endg ; returns 16 bit hash in EAX! proc HashFNV1b, .pString begin push esi mov esi, [.pString] mov eax, $811C9DC5 .hashloop: cmp byte [esi], 0 je .exit xor al, byte [esi] inc esi imul eax, $01000193 jmp .hashloop .exit: ; folding to 16 bit. mov esi, eax shr esi, 16 xor eax, esi movzx eax, ax pop esi return endp ; Returns: ; ; CF=0 - the string has been added to the list. ; CF=1 - the string is already in the list or the list is full. proc AddUniqueToList, .pString begin pushad stdcall HashFNV1b, [.pString] mov edx, eax ; in order .put_loop: mov esi, [.pString] mov edi, [hash_table+4*eax] test edi, edi jnz .compare ; Empty slot has been found mov [hash_table+4*eax], esi clc popad return ; Collision? .compare: cmpsb jne .yes_collision cmp byte [esi-1], 0 jne .compare ; the string is already in the list. stc popad return .yes_collision: ; closed hashing inc ax cmp eax, edx jne .put_loop ; the table is full. stc popad return endpmichael_vostrikov
07.01.2017 04:26Побайтовое сравнение строк тоже есть, а вы говорили, что есть только простые циклы. Есть хитрый хак с переполнением, это понятности не добавляет. Для оптимизации есть более эффективные методы (которые на ЯВУ проще применять). Ну и в целом кода гораздо больше, и я бы не сказал, что он проще для понимания, совершенно обычный код.
Source
07.01.2017 12:22Кроме того johnfound подменил изначальную задачу "поиск строки в массиве строк" на "добавление строки в уникальное множество строк". Т.е. сразу взял случай, когда проверка наличия строки в множестве будет выполняться часто. Однако, для таких случаев практически в любом ЯВУ есть класс/структура типа HashSet, которая работает с произвольными объектами, проверяя уникальность добавляемого объекта неожиданно при помощи метода GetHashCode.
johnfound
07.01.2017 12:27Кроме того johnfound подменил изначальную задачу "поиск строки в массиве строк" на "добавление строки в уникальное множество строк"
Это не подмена, потому что это одна и та же задача. Код будет тот же самый только будет на инструкции меньше:
; mov [hash_table+4*eax], esi
johnfound
07.01.2017 12:35Кроме того, почему я дал тот пример? — потому что хотел показать, что на ассемблере и на ЯВУ программисты думают по разному. Потому что то что пишется просто на ЯВУ, на ассемблере пишется сложно, а то что на ЯВУ написать сложно, наоборот, на ассемблере пишется просто.
Поэтому я считаю, что учится программировать на ассемблере, читая выход компилятора на ЯВУ нельзя.
Source
07.01.2017 13:00Это не подмена, потому что это одна и та же задача. Код будет тот же самый только будет на инструкции меньше
Да, только это медленнее побайтового сравнения будет, если нужно всего один раз за время выполнения программы эту проверку вызывать.
А если надо много проверок, то, как я выше написал, это и на ЯВУ будет HashSet, который под капотом сделает то же самое, что Ваш код, только с большим количеством проверок.
потому что хотел показать, что на ассемблере и на ЯВУ программисты думают по разному
Скорее они думают на разных уровнях абстракции, и это вполне очевидно.
Поэтому я считаю, что учится программировать на ассемблере, читая выход компилятора на ЯВУ нельзя.
С этим я согласен, т.к. у компилятора нет задачи сделать код читабельным.
MacIn
07.01.2017 21:56Я вас умоляю… кто мешает программисту на асме вынести сравнение в библиотечную функцию?
0xd34df00d
11.01.2017 19:39Давайте поиграем в игру.
Я вообще не веб-разработчик, поэтому форумов и прочего не писал, но на днях за полтора вечера (из которых где-то половину вечера разбирался с незнакомым для меня фреймворком) я написал мааааленький такой сервис, который общается с клиентом по HTTPS, и общение сводится к следующему:
- Получить от клиента имя музыкального исполнителя.
- Вернуть URL страницы этого исполнителя на last.fm этому клиенту, чтобы он её скачал.
- Получить от клиента скачанную страницу (не самому же качать, last.fm забанит).
- Распарсить HTML, выдрать оттуда ссылки на фоточки исполнителя.
- Завернуть это всё в JSON и вернуть клиенту.
Сколько времени и кода у вас займёт написать это всё? Только библиотеку для парсинга HTML чур написанную ассемблере используйте. И никаких внешних HTTPS-серверов, никакого апача, lightttpd или чего там.
У меня реализация логики — буквально 25 строк, выставить это всё по HTTPS — ещё 25.
Finesse
09.01.2017 06:32Использование веб программы на ассемблере может сэкономить на хостинге и позволит использовать дешевый виртуальный хостинг там, где другие используют выделенные серверы и другие дорогие решения.
Через сколько времени экономия на хостинге окупит увеличенную оплату работы программистов?
johnfound
09.01.2017 08:57Через сколько времени экономия на хостинге окупит увеличенную оплату работы программистов?
Это конечно смотря какой сайт и какие программисты. Можно и сразу.
Например, если вам нужен форум чтобы несколько тысяч человек общались:
- Качаете AsmBB.
- Устанавливаете за 5 минут.
- ???????
- Профит!
Source
09.01.2017 12:03Где ж тут профит?.. AsmBB пока на уровне прототипа и нет никаких гарантий, что Вам не надоест его разрабатывать и он дотянет до production-ready состояния в ближайшие пару лет.
Несколько тысяч пользователей для форума — это мелочи, можно взять любой движок с активным комьюнити, поддержкой и расширениями.Siemargl
09.01.2017 12:12Значок сарказма нужно было понимать.
На самом деле профит от любого быстрого развертывания. Только вот AsmBB потребует VDS, потому профит может оказаться меньшим на начальном этапе
Или не потребует в базовой функциональности?johnfound
09.01.2017 12:20Только вот AsmBB потребует VDS,
Никакого VDS не надо. У меня работает на shared hosting.
terryP
09.01.2017 14:46У меня работает на shared hosting.
Далеко не на любом хостинге вам дадут запускать исполняемые файлы. Во многих хостингах все ограничивается php, MySQL и ещё чем-нибудь вроде питона. А там где дадут, скорее всего не будет такого жесткого ограничения по ресурсам.johnfound
09.01.2017 16:05А вы это пробовали?
Я не встречал такой хостинг, который не позволял бы бинарные файлы. Если PHP или Perl работают, то и бинарные CGI и FastCGI скрипты должны работать.
Я конечно не специалист в Apache, но по моему там просто нет возможность ограничит исполнения таких файлов.
terryP
09.01.2017 17:29Если PHP или Perl работают, то и бинарные CGI и FastCGI скрипты должны работать.
Я конечно не специалист в Apache, но по моему там просто нет возможность ограничит исполнения таких файлов.
Ну кто вам помещает просто не пустить пользователя в папку куда он сможет положить бинарные CGI и FastCGI? Будет у него папка куда он сможет залить php скрипты (да ещё и с кучей ограничений, вроде safe мода) и все. Ни модули php переставить, ни бинарники запустить, ни .httaccess свой использовать. Естественно, ни ssh, ни прав на смену прав у пользователя не будет, чисто ftp и веб.консоль.
Я не встречал такой хостинг, который не позволял бы бинарные файлы.
Я встречал хостинги, которые вообще ничего кроме html не позволяли. Ничего народ пользовался… правда это было давно. А так как только хостеры не извращались в своих тарифах.johnfound
09.01.2017 18:52Просто попробуйте.
Я встречал хостинги, которые вообще ничего кроме html не позволяли.
Это да, возможно. Но раз позволены некоторые исполняемые файлы — например PHP, то позволены все выполняемые файлы. Некоторые из них можно запретить, просто не устанавливая интерпретатор — например Perl. Но бинарные файлы не нуждаются в интерпретатором. Они работают всегда.
terryP
09.01.2017 19:03Но бинарные файлы не нуждаются в интерпретатором. Они работают всегда.
Эээ, а как же chmod +x имя_файла? Как нечто залитое по ftp вдруг в Linux станет исполняемым без прав доступа? И как вы его запустите из веба, если там позволены только расширения php и html? Настроить FastCGI свои права доступа для каждого пользователя можно.johnfound
09.01.2017 19:53Права вполне можно менять и через FTP. Я собственно так и делаю. А если PHP доступны, то их права тоже надо менять на +x
PHP работает через FastCGI. Если PHP работает, то в модуль Апачи fcgi работает. Остается только написать в .htaccess:
FcgidWrapper "/YOUR_PATH/engine" virtual SetHandler fcgid-script
И все будет работать.
Source
09.01.2017 22:19PHP может и через mod_php быть настроен. Раньше на большинстве shared-хотингов был именно он.
johnfound
09.01.2017 23:22Ну, вообще то, может быть. Как я сказал, я не специалист в Апачи.
Просто я никогда не видел такой хостинг, чтобы нельзя было запустить бинарные CGI или FastCGI скрипты, если хоть какие CGI скрипты разрешены, например Perl или PHP. Кстати, то же самое в силе и насчет bash CGI скрипты. Например fossil работает именно через bash скрипт.
johnfound
09.01.2017 12:18Ну не совсем на уровне прототипа. Там все вполне хорошо работает. А мне даже и если надоест его разрабатывать, то хоть баги исправить не откажусь никогда. А если люди начнут использовать, то найдутся и такие, которые будут писать расширения и развивать проект дальше. Это и есть сущность свободного ПО.
Несколько тысяч пользователей для форума — это мелочи, можно взять любой движок с активным комьюнити, поддержкой и расширениями.
Я имел ввиду общаться одновременно в онлайне. Это совсем не мелочь. И да, можно взять любого движка, только на хостинг придется платить намного больше. Что я и имел ввиду.
terryP
09.01.2017 14:56+1Я имел ввиду общаться одновременно в онлайне. Это совсем не мелочь. И да, можно взять любого движка, только на хостинг придется платить намного больше. Что я и имел ввиду.
Хотите расскажу как добиться того скорости в десяток раз большей, а затрат ресурсов в десяток раз меньшей чем ваш прототип, причем на любом ЯП?
На любом языке пишем скрипт, который всю информацию форума будет хранить в виде сгенеренных html файлов или json файлов для ajax (или и того и другого вместе), при каждом добавлении новой информации, он будет просто блокировать нужный файл html/создавать новый, дописывать в страницу пост и возвращать результат. А в базу все изменения будут скидываться с определенной периодичностью (минута, час, день) и к базе он будет обращаться только при восстановлении системы или для поиска по форуму.
Скорость чтения будет равна скорости отдачи любого html'а (а это самый частый запрос), скорость записи будет ограничена записью в файл с блокировкой. Ресурсов будет тратиться мизер, база данных вообще не будет грузиться.
P.S. Насколько знаю подобные движки уже существуют (например, на PHP).
P.P.S. Кое-какие функции будут недоступны или придется исхитрится, чтобы их реализовать, но скорость будет… быстрой.johnfound
09.01.2017 16:08terryP
09.01.2017 16:12+2О, это будет очень простой системой. У неё будут ограничения, но система она будет простой. Именно такие были первые веб порталы на заре интернета. Другое дело, что сейчас есть мало причин пытаться протянуть верблюда через игольное ушко (для ассемблера это тоже справедливо).
Source
09.01.2017 16:45+2Эта техника была достаточно популярна ещё лет 5 назад… С современным фронтендом всё ещё проще для бекэнда. Теперь весь HTML принято кешировать в шаблонах любимого JS-фреймфорка, а от сервера только JSON спрашивать… Который в свою очередь легко кешируется в memcached, хотя в большинстве случаев даже его честная генерация занимает в разы меньше времени, чем пинг до сервера )
grossws
12.01.2017 02:30На любом языке пишем скрипт, который всю информацию форума будет хранить в виде сгенеренных html файлов или json файлов для ajax (или и того и другого вместе), при каждом добавлении новой информации, он будет просто блокировать нужный файл html/создавать новый, дописывать в страницу пост и возвращать результат. А в базу все изменения будут скидываться с определенной периодичностью (минута, час, день) и к базе он будет обращаться только при восстановлении системы или для поиска по форуму.
ixbt вспомнился, он примерно так и работал. Рендер в статику — и в путь.
Source
09.01.2017 17:31+3Ну не совсем на уровне прототипа. Там все вполне хорошо работает.
Ну на уровне прототипа работает… А если прикинуть сколько человеколет понадобится, чтобы до уровня какого-нибудь Discourse допилить, то становится грустно.
Поймите, что ваш проект привлекателен только тем, что он на ассемблере. Если бы кто-то опубликовал анонс аналога (по функционалу) на PHP/Ruby/Python, то его закидали бы помидорами в стиле "что это за кусок г...?" Потому что все, когда начинали изучать веб-программирование, писали собственный форум, или CMS, или соц.сеть, или ещё что-то подобное, но и то более навороченное по фичам.
Я имел ввиду общаться одновременно в онлайне. Это совсем не мелочь.
Согласен, это уже не мелочь. Но, как я выше писал, для пользователей AsmBB работает медленно даже без нагрузки. Если к вам пару сотен одновременных посетителей нагнать, то у вас тупо веб-сервер ляжет, до asmbb даже запросы доходить не будут.
Это я ещё молчу, что придётся как в прошлом веке страницу каждый раз обновлять, чтобы о новых сообщениях узнать. Что для активных переписок выглядит жестоким анахронизмом.johnfound
09.01.2017 18:57но и то более навороченное по фичам.
А какие именно фичи вы имеете ввиду?
Source
09.01.2017 22:32Если по форумам, которые раньше в качестве обучалок писали, то там хотя бы были дерево категорий (а не только теги), личные сообщения между пользователями, система рейтинга и т.д. По современным фичам — смотрите современные форумы.
johnfound
09.01.2017 23:29Дерево категории не реализовано вполне сознательно. Потому что на форумы на каторых я бываю, оно совершенно бесполезно.
Личные сообщения — это да. Надо и будет.
Source
10.01.2017 00:46Если только теги оставить, то надо хотя бы возможность подписываться на теги, чтобы был список не только всех тем, но ещё и только с теми тегами, по которым ты хотел бы отвечать.
johnfound
09.01.2017 18:59для пользователей AsmBB работает медленно даже без нагрузки
Да, если эти пользователи из Канады. Но это не проблем AsmBB, а конкретного веб провайдера.
Source
09.01.2017 22:53Скорее проблема в вашем хостинге… Сегодня он, кстати, получше работает. Мораль тут в том, что нагруженный проект на shared-хостинге всё равно не получится запустить просто по определению shared-хостинга… Все ресурсы разделяемы, в том числе и канал… Попробуйте тысячу ботов на ваш форум запустить, которые ежесекундно будут к нему обращаться (читать, писать, редактировать) и посмотрите через сколько дней вас попросят на VDS переехать или хотя бы на VPS без оверсейла. А заодно узнаете какая часть запросов не дойдёт до AsmBB и какое будет время ответа от сервера при средненькой базе (в районе 10 Gb)… Хотя это я загнул, база не успеет до средних размеров вырасти, т.к. дисковая квота закончится ещё на миниразмере БД )
Finesse
10.01.2017 01:19Я имею ввиду случай, когда продукт разрабатывается самостоятельно, а не берётся готовый.
stas404
Блин, неужели так трудно проверить статью перед публикацией или попросить об этом кого-нибудь, чтобы потом не кровоточило из глаз при чтении? Это уже за гранью. Безотносительно к содержанию.
kAIST
Насколько я понял, русский для автора не родной язык.
stas404
При всем понимании.
gearbox
Почему мы злые?
вычитать и отправить автору корректировки отняло у меня не больше 20 минут.
stas404
Это действительно очень здорово и похвально, что у вас нашлось 20 минут на корректировки и отправку оных автору. Но, мне представляется, бы еще чуточку лучше, если бы читатели прочитали данную статью уже после их внесения перед публикацией для чего бы и пригодилась инициатива со стороны автора. Суть того, что я написал — пожелание уделять несколько больше внимания к подготовке материала, потому что читать такое тяжело, не говоря уже об остальном. Никакой злости со своей стороны я лично в этом не усматриваю и не вкладываю, и хочется верить, что только вы увидели здесь то, что захотели (кстати, по вашей ссылке совсем другая история, касающаяся конкретно содержания, а не корректности его изложения, обратите внимание — это разные вещи).
Когда статья подготовлена нормально, таких комментариев не появляется. Не зря классики говорили «Кто ясно мыслит, тот ясно излагает.»
vics001
Не переживайте, большинство прочитали уже после исправления.
Вопрос, почему мы такие злые все-таки остается актуальным.
mikeus
Я прочитал ещё начальный вариант и ничего, что было бы «за гранью» и от чего бы «кровоточило из глаз при чтении» не заметил. Ну да, в паре мест падежи не согласованы, может где речевые обороты не такие гладкие, но для изложения на иностранном языке вполне прилично. Кто писал, тот понимает. Англоговорящим и не такое приходится читать. Реакция не заслуженная и, главное, не по существу.
tyomitch
Ну вот прямо сейчас прямо в первом предложении статьи — ошибки согласования падежей («писать на один из языках»).
Было ещё хуже?
mikeus
Нет, примерно такие же ляпы.
vics001
Непонятно, почему «мы такие злые», ведь даже то же самое, можно было изложить гораздо аккуратнее.
«При все моем уважении к тому, что для автора русский — это не родной язык, он поторопился, выкладывая данную статью без вычитки. К сожалению, я не смог прочитать даже первые пару абзацев. Думаю, вычитка и исправление помогло бы раскрыть суть статьи полнее для многих читателей.»
Смысл тот же, а отношение лучше.
gearbox
>Это действительно очень здорово и похвально, что у вас нашлось 20 минут на корректировки и отправку оных автору.
Речь шла не обо мне. Это был тонкий намек на то что возможно и у Вас ушло бы сопоставимо времени на это. Но вы предпочли возмущаться тем что человек для которого русский не является родным осмелился публиковаться, не выучив язык на уровне натива. Россияне ведь все как один владеют языками лучше носителей, да что там — носители свой язык учат по постам россиян на форумах. Оттого и требования у нас высокие, не злые мы, совсем нет. А еще мы воспитанные.
stas404
Да, я прекрасно понял ваш «намек обо мне» и, пожалуй, оставлю без внимания ваши Д'Артаньяновские слова в мой адрес и не буду намекать вам в ответ. Просто повторюсь и подытожу:
Я бы с удовольствием помог автору, если бы он, зная, что у него возможны проблемы с изложением на русском обратился ко мне с просьбой глянуть черновик перед публикацией. И я, в принципе, не против делать это в будущем.
Мне хотелось бы видеть здесь более качественные публикации (хотя бы в плане изложения) — к сожалению, в последнее время таковых все меньше. Чтобы не возникало отторжения при чтении — даже если материал интересный, то качество изложения может весьма сильно подпортить впечатление, а в некоторых случаях и исказить его понимание, не говоря уже о желании читать.
Раз уж писать статью, то писать ее для людей — понимая кто ее будет читать и хоть немножко уважать читателя. Не надо говорить мне, что я преувеличиваю — читать то, что было предложено было реально тяжело.
Такова моя позиция, пространные рассуждения про злость или не злость совершенно не к месту — разве что только высказывание своего мнения карается у нас минусами в карму — это весьма по-доброму, при всем при том, что вроде бы на личности не переходил и просто высказал мнение с которым имеются и солидарные.
В конце концов, объективно — для ресурса статья была подготовлена ненадлежащим образом и, обращаясь к автору/авторам — уделяйте чуть больше внимания к подготовке материала, чтобы всем было хорошо, на крайний случай попросите кого-нибудь.
С наступившим.
gearbox
>Я бы с удовольствием помог автору, если бы он, зная, что у него возможны проблемы с изложением на русском обратился ко мне с просьбой глянуть черновик перед публикацией. И я, в принципе, не против делать это в будущем.
И что же помешало сделать это в прошлом?
stas404
Даже приведенная вами цитата содержит ответ на этот вопрос — видимо по причине того, что автор опубликовал «как было» и не обратился. По-моему выше я довольно четко сформулировал свою мысль.
Однако, вас я не пойму — вы чего-то от меня хотите или ждете? Вроде как, уже все прояснено, я дал развернутый ответ и обозначил свою позицию, а вы продолжаете за что-то цепляться.
Так я уже даже похвалил вас без всякого сарказма — быть может вам самому стоит вспомнить про ту ссылку, которую вы приводили?
johnfound
Не думал комментировать, но как это "обратится"? К кому? Есть песочница, там можно писать в черновики, а потом публиковать и ждать модератора и приглашения (ну или неприглашения). Я просто не понимаю где в этом процессе можно попросить помощь и от кого?
Потом, когда статью одобрили к публикацию, вот gearbox сразу написал на ЛС, что и где не так. А я исправил. Кстати, я даже не знал что есть ЛС.
eteen
Кстати, дайте ответ в ЛС. Пожалуйста!
stas404
Приветствую.
Думаю, что вы уже прочитали ветку и понимаете о чем идет речь.
Раньше модераторы просматривали статьи и сами корректировали их при необходимости, а в некоторых случаях и не допускали к публикации, если в большем количестве присутствовали ошибки (даже несмотря на интересный материал).
Но с тех времен, к сожалению, многое изменилось, в частности, сейчас ответственность за качество статей почти полностью лежит на руках самих авторов.
Зная, что у вас возможны проблемы с написанием статьи на русском, к кому обратиться — вопрос не технический (с учетом отсутствия такого механизма на хабре, насколько я знаю), а эстетический, чтобы быть уверенным в своей публикации и что она будет понятна читающим.
Думаю, в просьбе пробежаться по статье и поправить ошибки перед публикацией нашлось бы немало тех, кто был бы не против, и это могли бы быть люди не обязательно с этого сайта. Если готовится публикация на широкую публику, а не у себя в блоге, то почему бы не сделать ее доступнее и на нормальном уровне? Ведь все от этого будут только в плюсе.
Здесь есть даже правила для публикаций, с которыми было бы крайне желательно ознакомиться перед самой публикацией: https://habrahabr.ru/info/help/posts/
Там, как раз, и изложены принципы и пожелания о которых идет речь, и ваша публикация была бы только лучше, если бы вы, зная, что возможны ошибки в таком большом объеме уделили бы им внимание. Ничего личного — то, что я писал направлено не только к вам, но к авторам в целом и к носителям языка тем более. Ребят, просто хочется видеть приемлемый уровень, а не ломать мозг при чтении.
Center-T
Вы выставили себя занудой. Написали очень много бесполезного текста, т.е. текста, который неинтересно читать никому. И, вероятно, утомили не только меня. Лучше бы Вы вообще ничего не писали.
stas404
Вынужден признать, что вы правы — именно так оно теперь и выглядит.
Нашло что-то — слово за слово, ответ на ответ, конечно же стоило ограничиться первым комментарием и не разводить это болото.
Но, к сожалению, уже ничего не поделаешь.
MoreBeauty
Ну так если у вас нашлось бы время почитать черновик и указать на недочеты, то почему не нашлось почитать готовый уже материал и отправить автору исправления, как это сделал предыдущий оратор?