Смысл был в том, чтобы показать скорость разработки аналогичного проекта на языке высокого уровня. Я не ставил себе цель сравнивать миллисекунды.
Я тоже провел эксперимент. Мне очень трудно считать сколько времени отнимет та или другая задача. Поэтому, решил реализовать кеширование HTTP (как советовали), но измерить точное время работы.
Эта задача очень подходит под эксперимент, потому что код которого надо было менять писался весной и больше никогда не менялся (ну может быть были некоторые багфиксы). Так что задача получается очень реалистична. Надо менять код, которой писался давным давно, надо сориентироваться и потом поменять его.
Получилось ровно 78 минут.
Можно было и быстрее, но мне не хотелось удалять старую БД, поэтому пришлось писать и код который рендировал все старые посты на сервере.
Но зачем, кроме фана, нужен ассемблер в задаче, где нет никаких вычислений, я все же не понимаю.
А разве фан, это плохо?
Я пишу на ассемблере много чего. Часть моего кода (например программы управления промышленного оборудования) закрытая. Можно посмотреть некоторые картинки здесь.
A вообще, больше всего нравится писать десктоп приложения. Но написание AsmBB было мне очень полезно. Я научил что это FastCGI, SMTP, XSS и много всего из мира WWW/HTTP. Разве это плохо?
Ваши все вычисления предполагают, что разработчики будут работать в одинаковом темпе, во все время жизни проекта. Работает сервер, тысячи посетители посещают сайт, читают, пишут, общаются, а в то же время 5 девелоперы, каждый день, 8 часов подряд, пишут новый код, фиксят баги и т.д. И так в продолжении 10..20 лет.
Но ведь так не бывает. Разработка всегда движется по экспоненте — в начале все работают много, потом работа уменьшается и приоритеты смещаются — примерно исправляются ошибки.
Во вторых, вы пишете насчет разработки очень специализированного софта, который будет работать на одном сервере и нигде больше. Но так тоже далеко не всегда. Если взять например SMF — там тоже разработчики работают все время (и опять интенсивность работ совсем не всегда одинакова), но их программа установлена на десятки тысячи серверов и суммарные расходы на хостинг просто сумасшедшие.
Если написать в сообществе программистов, что вы собрались писать форум на ассемблере, чтобы он работал на дешевом хостинге, есть довольной большой шанс, что вам придёт несколько небольших пожертвований. Но с поточными расценками на хостинг даже небольших пожертвований хватит, чтобы этот хостинг держал пару десятков тысяч уникальных посетителей в день год или больше.
Дело не в форуме. Мне форум не нужен как таковой. То что я инсталлировал, просто демо, чтобы можно было потрогать руками.
И если дело в одном форуме то конечно заплати и спи спокойно. Но дело здесь в принципе. Если сделать бакенд вдвое легче (а AsmBB более чем вдвое легче эквивалента на PHP) то при прочих равных вы сможете обслуживать за те же деньги вдвое больше посетителей. Ну или сэкономить половину бюджета. А половина, иногда может быть много миллионов. Не так ли?
Я на rake напишу такой код в обход фреймворков и он заработает на очень плохом хостинге, хотя и проиграет пару мс вашему варианту.
Я в комментариях уже наверное 100500 раз прочитал, как на языке X и Y все это пишется за 2 часа и будет конечно и быстрее и память будет жрать меньше и поддерживаться лучше.
И языки были и Java и PHP и C. Вот теперь rake (никогда не слышал, может это и не язык).
Только ведь, не пишут, только болтают.
Потому что реальный проект просто так не пишется. Тем более за 2 часа или 2 дня. Там многое чего нужно придумывать.
А вот вы возмите и напишите. Сделайте хранилище кода, а мы посмотрим как быстро у вас получится. Поставьте где нибудь демо.
А мы посетим, зарегистрируемся. Понагрузим хабра-эффектом. Поищем XSS уязвимостей. Осмотрим на каком хостинге это установлено. И вывод сам сделается.
Я тоже раньше так считал, но это не так. Этой точки эсть в нынешнем пространстве, только она выглядит как сфера, удаленная на 13.8 миллиарда световых лет от нас.
Получается так, что каждый возможный световой луч, куда ни был направлен, заканчивается в точке БВ.
Мы как бы разглядываем эту точку со всех сторон одновременно.
Буферы не переполнились, но нашелся баг — когда название темы очень длинное, скрипт третирует его как имя файла и возвращает "Forbidden". Скоро исправлю.
Нет не исправлю. Это баг Apache :(. Баг репорт написали в 2008-го года, но баг живой и шевелится. Наверное, потому что на C пишется намного быстрее чем на ассемблере. :D
Так и я о том же. Это просто не работа для одиночек. И деньги тут не причем. Просто современные веб стандарты достаточно сложные и реализация, вне зависимости от языка программирования, должна делаться коллективом.
Каждый раз заново парсите markdown, вместо хранения скомпилированного варианта,
А сколько времени вы думаете отнимет чтобы сделать эту функцию? Моя оценка — около двух часов. Ничего сложного там нет. Понадобится, сделаю.
А кстати, этим можно протестировать насколько плохо поддерживается ассемблерный код.
Нужен доброволец, который хоть немного знает ассемблер и синтаксис FASM. Даем ему задание, чтобы сделал кеширование компилированного markdown-а и посмотрим сколько времени ему отнимет.
Конечно эму будет нужны намного больше 2-х часов, хотя и потому что понадобиться почитать исходники и ориентироваться в проекте с нуля. Но я считаю, что получится все очень быстро.
Так тоже бывает, но только когда код нужен совсем наибыстрейший. :D
Когда пишутся глубокие оптимизации, то скорость оптимизированного кода на ассемблере и на C будет приблизительно одинакова. Ну пусть ассемблер будет на 10..20% быстрее. (Но читаемость кода на ассемблере все таки будет лучше).
Но дело в том, что 99% программ в мире, наоборот — совершенно не оптимизированные. Вот там, разница в производительности будет в десятки раз.
Я делал такие эксперименты дважды или трижды и всегда было так. Конечно, программисты должны быть одинаковой квалификации, а программы достаточно большими, чтобы нельзя было заняться сразу глубокими оптимизациями.
Не все так плохо. Мои тесты показывают, что если программисты пишут не оптимизированный, достаточно сложный код (чтобы оптимизировать было не очевидно), то программы на ассемблере всегда получаются быстрее. И быстрее намного. А не оптимизированный код — это 99.9% всего кода в мире.
Дело в том, что программисты ленивые и всегда пишут так как им легче. Вот, на ассемблере, легче (почти) всегда пишется так как проще, а это (почти) всегда быстрее. Потому что проще, на ассемблере означает и проще для процессора.
А "проще" на ЯВУ, совсем не означает "проще для процессора". Поэтому, чтобы стало быстрее на ЯВУ, нужно прилагать нешуточные усилия, а код получается далеко не читаемым.
А лучшие алгоритмы получаются сложными, и их плохо писать на ассемблере.
Нет с этим я не согласен. Сложными они получаются, когда пишут их на ЯВУ. Потому что лучшие алгоритмы, такие, которые ближе к CPU. Нативнее что ли. А таких намного легче писать на ассемблере. На ассемблере они и читаются лучше.
Правда, надо язык знать хоть немного. Но это для каждого языка в силе.
А, да. Весь код, который менялся за те 78 минут здесь: HTTPCache
Я тоже провел эксперимент. Мне очень трудно считать сколько времени отнимет та или другая задача. Поэтому, решил реализовать кеширование HTTP (как советовали), но измерить точное время работы.
Эта задача очень подходит под эксперимент, потому что код которого надо было менять писался весной и больше никогда не менялся (ну может быть были некоторые багфиксы). Так что задача получается очень реалистична. Надо менять код, которой писался давным давно, надо сориентироваться и потом поменять его.
Получилось ровно 78 минут.
Можно было и быстрее, но мне не хотелось удалять старую БД, поэтому пришлось писать и код который рендировал все старые посты на сервере.
А разве фан, это плохо?
Я пишу на ассемблере много чего. Часть моего кода (например программы управления промышленного оборудования) закрытая. Можно посмотреть некоторые картинки здесь.
A вообще, больше всего нравится писать десктоп приложения. Но написание AsmBB было мне очень полезно. Я научил что это FastCGI, SMTP, XSS и много всего из мира WWW/HTTP. Разве это плохо?
А скорость разработки пока так:
3 дня и 27 коммитов, а версия, согласитесь что сырая. (Кстати, вы начали писать 3-его Января?!)
У меня, для v1.0 понадобилось 54 коммитов.
Так что если привести эту работу к v1.0 по моему брой коммитов будет очень близко к те 54.
О! Уважаю! Теперь давайте приводить в вид, которого можно было сравнивать:
Насчет оценки быстродействия может и хватит — но, конечно если добавите измеритель (см. 1)
Но насчет сравнения времени разработки не хватит, потому что у вас нет:
А чтобы сделать все это нужно время. И так эти 12 часов превратятся в намного больше.
0.97с это долго? А сравниваете с чем?
Все это так, но не совсем.
Ваши все вычисления предполагают, что разработчики будут работать в одинаковом темпе, во все время жизни проекта. Работает сервер, тысячи посетители посещают сайт, читают, пишут, общаются, а в то же время 5 девелоперы, каждый день, 8 часов подряд, пишут новый код, фиксят баги и т.д. И так в продолжении 10..20 лет.
Но ведь так не бывает. Разработка всегда движется по экспоненте — в начале все работают много, потом работа уменьшается и приоритеты смещаются — примерно исправляются ошибки.
Во вторых, вы пишете насчет разработки очень специализированного софта, который будет работать на одном сервере и нигде больше. Но так тоже далеко не всегда. Если взять например SMF — там тоже разработчики работают все время (и опять интенсивность работ совсем не всегда одинакова), но их программа установлена на десятки тысячи серверов и суммарные расходы на хостинг просто сумасшедшие.
Я могу себе его позволит. Компания отечественная. Поддержка на Болгарском.
Дело не в форуме. Мне форум не нужен как таковой. То что я инсталлировал, просто демо, чтобы можно было потрогать руками.
И если дело в одном форуме то конечно заплати и спи спокойно. Но дело здесь в принципе. Если сделать бакенд вдвое легче (а AsmBB более чем вдвое легче эквивалента на PHP) то при прочих равных вы сможете обслуживать за те же деньги вдвое больше посетителей. Ну или сэкономить половину бюджета. А половина, иногда может быть много миллионов. Не так ли?
Я в комментариях уже наверное 100500 раз прочитал, как на языке X и Y все это пишется за 2 часа и будет конечно и быстрее и память будет жрать меньше и поддерживаться лучше.
И языки были и Java и PHP и C. Вот теперь rake (никогда не слышал, может это и не язык).
Только ведь, не пишут, только болтают.
Потому что реальный проект просто так не пишется. Тем более за 2 часа или 2 дня. Там многое чего нужно придумывать.
А вот вы возмите и напишите. Сделайте хранилище кода, а мы посмотрим как быстро у вас получится. Поставьте где нибудь демо.
А мы посетим, зарегистрируемся. Понагрузим хабра-эффектом. Поищем XSS уязвимостей. Осмотрим на каком хостинге это установлено. И вывод сам сделается.
Но ведь не напишете.
Так, у меня не VPS, а именно SuperStart shared hosting.
Я тоже раньше так считал, но это не так. Этой точки эсть в нынешнем пространстве, только она выглядит как сфера, удаленная на 13.8 миллиарда световых лет от нас.
Получается так, что каждый возможный световой луч, куда ни был направлен, заканчивается в точке БВ.
Мы как бы разглядываем эту точку со всех сторон одновременно.
Нет не исправлю. Это баг Apache :(. Баг репорт написали в 2008-го года, но баг живой и шевелится. Наверное, потому что на C пишется намного быстрее чем на ассемблере. :D
На lighttpd все работает.
Совсем не факт. Это зависит от того насколько программист знает тот язык и фреймворк.
Никакой я не бог. Боги другие, я их знаю. :D
Так и я о том же. Это просто не работа для одиночек. И деньги тут не причем. Просто современные веб стандарты достаточно сложные и реализация, вне зависимости от языка программирования, должна делаться коллективом.
А сколько времени вы думаете отнимет чтобы сделать эту функцию? Моя оценка — около двух часов. Ничего сложного там нет. Понадобится, сделаю.
А кстати, этим можно протестировать насколько плохо поддерживается ассемблерный код.
Нужен доброволец, который хоть немного знает ассемблер и синтаксис FASM. Даем ему задание, чтобы сделал кеширование компилированного markdown-а и посмотрим сколько времени ему отнимет.
Конечно эму будет нужны намного больше 2-х часов, хотя и потому что понадобиться почитать исходники и ориентироваться в проекте с нуля. Но я считаю, что получится все очень быстро.
Когда хороший браузер писался в одиночку??? Как соберутся энтузиасты, так сразу и возьмусь.
А пока пишу хорошее IDE и GUI библиотека для FASM.
Веб программирование на ассемблере, просто хобби и повод написания провокационных статей. ;)
Так тоже бывает, но только когда код нужен совсем наибыстрейший. :D
Когда пишутся глубокие оптимизации, то скорость оптимизированного кода на ассемблере и на C будет приблизительно одинакова. Ну пусть ассемблер будет на 10..20% быстрее. (Но читаемость кода на ассемблере все таки будет лучше).
Но дело в том, что 99% программ в мире, наоборот — совершенно не оптимизированные. Вот там, разница в производительности будет в десятки раз.
Я делал такие эксперименты дважды или трижды и всегда было так. Конечно, программисты должны быть одинаковой квалификации, а программы достаточно большими, чтобы нельзя было заняться сразу глубокими оптимизациями.
Не все так плохо. Мои тесты показывают, что если программисты пишут не оптимизированный, достаточно сложный код (чтобы оптимизировать было не очевидно), то программы на ассемблере всегда получаются быстрее. И быстрее намного. А не оптимизированный код — это 99.9% всего кода в мире.
Дело в том, что программисты ленивые и всегда пишут так как им легче. Вот, на ассемблере, легче (почти) всегда пишется так как проще, а это (почти) всегда быстрее. Потому что проще, на ассемблере означает и проще для процессора.
А "проще" на ЯВУ, совсем не означает "проще для процессора". Поэтому, чтобы стало быстрее на ЯВУ, нужно прилагать нешуточные усилия, а код получается далеко не читаемым.
Нет с этим я не согласен. Сложными они получаются, когда пишут их на ЯВУ. Потому что лучшие алгоритмы, такие, которые ближе к CPU. Нативнее что ли. А таких намного легче писать на ассемблере. На ассемблере они и читаются лучше.
Правда, надо язык знать хоть немного. Но это для каждого языка в силе.