Как стать автором
Обновить

Комментарии 429

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

Ага, что не начни писать на асме, в конце всё равно получается операционная система.
Колибри на роль серверной ОС не годится. Нет многопроцессорности и многопоточности.

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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


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


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


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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Машкод х86 — это интерпретируемый процессором в элементарные операции язык.
НЛО прилетело и опубликовало эту надпись здесь

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

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

Жесть


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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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

А для опытного — все что другим кажется ненормальным, покажется отличной идеей.
https://ru.m.wikipedia.org/wiki/WebAssembly

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

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

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

Full Text Search же :-)

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переписать в виде модуля апача.
Для полноты эксперимента осталось запихать все это в микроконтроллер.
НЛО прилетело и опубликовало эту надпись здесь

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

Esp8266 !!!

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

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

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


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

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

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

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


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

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

Не вопрос. :D

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дык, https://archive.org/details/bashttpd
НЛО прилетело и опубликовало эту надпись здесь
Итого. Вы переизобрели обработчик FastCGI, парсер HTTP, GET и POST, решали проблемы с разрядностью и библиотеками, все это вместо того, чтобы решать задачу. Вы месяц писали простой форум, и написали 12000 строк кода, который сложно поддерживать. Писать сайты на ассемблере можно для себя, если охота, но для бизнеса это неприемлемо.
Как и многие другие сервера, к сожалению кладётся с помощью старого-доброго slowHttp read

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

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

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

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

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


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

НЛО прилетело и опубликовало эту надпись здесь
Надо сокеты? Без проблем. Надо изображения обрабатывать (сжатие, обрезка, ит.д.)? Да в 4 строчки. Надо архивы паковать? Да легко

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

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


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


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

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


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

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


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

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

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


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

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

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

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь
А теперь характеристики сравните.
НЛО прилетело и опубликовало эту надпись здесь
Я не знаю, что там за vps SuperStart - на сайте не увидел, увидел такое название только в

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

НЛО прилетело и опубликовало эту надпись здесь

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

Ну я в сравнении с scaleway имел ввиду.
Так-то если поискать всякие «секретные» тарифы у хостингов то можно найти за 10-15$ в год впску, правда памяти там будет 512 и вроде 5ГБ диска.
НЛО прилетело и опубликовало эту надпись здесь
Там есть на x86 за 3€. ARM там на голом железе без всякой виртуализации.
Ну да, за 65р в месяц найти альтернативу сложно. Я у eomy.net секретный тариф за такую стоимость видел. Но у time4vps.eu есть тарифы за 0,99€ за пол года или 0,66€ за год, в чём-то даже лучше чем у ruvds.

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

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


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


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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мне надоело.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

set %b := 1

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

%a := arr2

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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