Скорее проблема в вашем хостинге… Сегодня он, кстати, получше работает. Мораль тут в том, что нагруженный проект на shared-хостинге всё равно не получится запустить просто по определению shared-хостинга… Все ресурсы разделяемы, в том числе и канал… Попробуйте тысячу ботов на ваш форум запустить, которые ежесекундно будут к нему обращаться (читать, писать, редактировать) и посмотрите через сколько дней вас попросят на VDS переехать или хотя бы на VPS без оверсейла. А заодно узнаете какая часть запросов не дойдёт до AsmBB и какое будет время ответа от сервера при средненькой базе (в районе 10 Gb)… Хотя это я загнул, база не успеет до средних размеров вырасти, т.к. дисковая квота закончится ещё на миниразмере БД )
Если по форумам, которые раньше в качестве обучалок писали, то там хотя бы были дерево категорий (а не только теги), личные сообщения между пользователями, система рейтинга и т.д. По современным фичам — смотрите современные форумы.
Ну не совсем на уровне прототипа. Там все вполне хорошо работает.
Ну на уровне прототипа работает… А если прикинуть сколько человеколет понадобится, чтобы до уровня какого-нибудь Discourse допилить, то становится грустно.
Поймите, что ваш проект привлекателен только тем, что он на ассемблере. Если бы кто-то опубликовал анонс аналога (по функционалу) на PHP/Ruby/Python, то его закидали бы помидорами в стиле "что это за кусок г...?" Потому что все, когда начинали изучать веб-программирование, писали собственный форум, или CMS, или соц.сеть, или ещё что-то подобное, но и то более навороченное по фичам.
Я имел ввиду общаться одновременно в онлайне. Это совсем не мелочь.
Согласен, это уже не мелочь. Но, как я выше писал, для пользователей AsmBB работает медленно даже без нагрузки. Если к вам пару сотен одновременных посетителей нагнать, то у вас тупо веб-сервер ляжет, до asmbb даже запросы доходить не будут.
Это я ещё молчу, что придётся как в прошлом веке страницу каждый раз обновлять, чтобы о новых сообщениях узнать. Что для активных переписок выглядит жестоким анахронизмом.
Эта техника была достаточно популярна ещё лет 5 назад… С современным фронтендом всё ещё проще для бекэнда. Теперь весь HTML принято кешировать в шаблонах любимого JS-фреймфорка, а от сервера только JSON спрашивать… Который в свою очередь легко кешируется в memcached, хотя в большинстве случаев даже его честная генерация занимает в разы меньше времени, чем пинг до сервера )
Где ж тут профит?.. AsmBB пока на уровне прототипа и нет никаких гарантий, что Вам не надоест его разрабатывать и он дотянет до production-ready состояния в ближайшие пару лет.
Несколько тысяч пользователей для форума — это мелочи, можно взять любой движок с активным комьюнити, поддержкой и расширениями.
Договора подряда как физ.лицо можно заключать, но невыгодно… 13% надо отдать в налоговую. А для ИП на УСН — 6%, часть из которых идёт в ПФР. Правда, у ИП есть ещё всякие расходы, типа платы за расчётный счёт и т.п., но это 20-30 т.р. в год. Но это, как правило, всё равно меньше 7% от годового дохода.
Основное отличие Elixir от Erlang — это возможности метапрограммирования в стиле Lisp, ну и более удобный тулинг. Остальное — по сути либо следствия, либо мелочи.
P.S. Мутабельности данных в Elixir нет, есть ребиндинг переменных, но это совсем не то же самое.
Это не подмена, потому что это одна и та же задача. Код будет тот же самый только будет на инструкции меньше
Да, только это медленнее побайтового сравнения будет, если нужно всего один раз за время выполнения программы эту проверку вызывать.
А если надо много проверок, то, как я выше написал, это и на ЯВУ будет HashSet, который под капотом сделает то же самое, что Ваш код, только с большим количеством проверок.
потому что хотел показать, что на ассемблере и на ЯВУ программисты думают по разному
Скорее они думают на разных уровнях абстракции, и это вполне очевидно.
Поэтому я считаю, что учится программировать на ассемблере, читая выход компилятора на ЯВУ нельзя.
С этим я согласен, т.к. у компилятора нет задачи сделать код читабельным.
Кроме того johnfound подменил изначальную задачу "поиск строки в массиве строк" на "добавление строки в уникальное множество строк". Т.е. сразу взял случай, когда проверка наличия строки в множестве будет выполняться часто. Однако, для таких случаев практически в любом ЯВУ есть класс/структура типа HashSet, которая работает с произвольными объектами, проверяя уникальность добавляемого объекта неожиданно при помощи метода GetHashCode.
Ну, кстати, load time у Вас получился 0.35 секунды (против 0.97 у демо asmbb), даже несмотря на то, что оставили без объединения 3 CSS и 3 JS-файла. Так что отзывчивость сайта оказалась почти в 3 раза лучше, просто за счёт более хорошего хостинга.
Это не так чтобы очень долго, но и не быстро. Считается, что меньше 2 секунд — это приемлемый результат для среднестатистического сайта.
Но, учитывая достаточно простой дизайн (малое кол-во картинок и CSS) и практически пустую БД, можно было ожидать хотя бы в районе 0.5 секунды.
Обратите внимание, что у Вас плохие показатели по Initial connection и по TTFB. Не факт, что Вы можете на них повлиять, т.к. они зависят от настроек сервера. Но дело в том, что они добавляют сотни миллисекунд оверхеда, на фоне которых экономия пары миллисекунд за счёт применения ассемблера совсем потерялась.
При оптимизации сайтов главная метрика — load time, а не время генерации на сервере. Да и временем генерации ответа за миллисекунды сложно удивить, было бы меньше 1 ms — было бы круто. А текущие результаты (6 — 30 ms) можно и на ЯВУ воспроизвести. Т.е. в теории выигрыш от применения ассемблера должен быть, но на данном примере его не видно.
Ну, ё-моё, опять 25… Забудьте Вы уже про скорость… Абстрагируйтесь от неё, если морфологическое сходство слов вас так сильно запутывает. Тем более, что такого термина как "скорость выполнения" в принципе нет в бенчмарках.
Бенчмарки меряют время ожидания (latency в секундах) и считают пропускную способность (throughput в ips или в rps).
При этом изменения latency обычно считают в процентах, а изменения throughput — в разах.
Ускорилось на 50% = latency уменьшилось на 50% = throughput вырос в 2 раза = ускорилось в 2 раза.
Вы же пытаетесь ввести какую-то свою терминологию, и не понятно откуда Вы её вообще взяли… Мне прям даже интересно на базе чего Вы так упорствуете… Дайте хоть ссылку на какую-нибудь benchmark-утилиту, которая вашей методологии подсчётов придерживается.
Скорее проблема в вашем хостинге… Сегодня он, кстати, получше работает. Мораль тут в том, что нагруженный проект на shared-хостинге всё равно не получится запустить просто по определению shared-хостинга… Все ресурсы разделяемы, в том числе и канал… Попробуйте тысячу ботов на ваш форум запустить, которые ежесекундно будут к нему обращаться (читать, писать, редактировать) и посмотрите через сколько дней вас попросят на VDS переехать или хотя бы на VPS без оверсейла. А заодно узнаете какая часть запросов не дойдёт до AsmBB и какое будет время ответа от сервера при средненькой базе (в районе 10 Gb)… Хотя это я загнул, база не успеет до средних размеров вырасти, т.к. дисковая квота закончится ещё на миниразмере БД )
Если по форумам, которые раньше в качестве обучалок писали, то там хотя бы были дерево категорий (а не только теги), личные сообщения между пользователями, система рейтинга и т.д. По современным фичам — смотрите современные форумы.
PHP может и через mod_php быть настроен. Раньше на большинстве shared-хотингов был именно он.
Ну на уровне прототипа работает… А если прикинуть сколько человеколет понадобится, чтобы до уровня какого-нибудь Discourse допилить, то становится грустно.
Поймите, что ваш проект привлекателен только тем, что он на ассемблере. Если бы кто-то опубликовал анонс аналога (по функционалу) на PHP/Ruby/Python, то его закидали бы помидорами в стиле "что это за кусок г...?" Потому что все, когда начинали изучать веб-программирование, писали собственный форум, или CMS, или соц.сеть, или ещё что-то подобное, но и то более навороченное по фичам.
Согласен, это уже не мелочь. Но, как я выше писал, для пользователей AsmBB работает медленно даже без нагрузки. Если к вам пару сотен одновременных посетителей нагнать, то у вас тупо веб-сервер ляжет, до asmbb даже запросы доходить не будут.
Это я ещё молчу, что придётся как в прошлом веке страницу каждый раз обновлять, чтобы о новых сообщениях узнать. Что для активных переписок выглядит жестоким анахронизмом.
Эта техника была достаточно популярна ещё лет 5 назад… С современным фронтендом всё ещё проще для бекэнда. Теперь весь HTML принято кешировать в шаблонах любимого JS-фреймфорка, а от сервера только JSON спрашивать… Который в свою очередь легко кешируется в memcached, хотя в большинстве случаев даже его честная генерация занимает в разы меньше времени, чем пинг до сервера )
Я думаю, имелось в виду, что типизация позволяет реализовать дополнительные подсказки в IDE.
Где ж тут профит?.. AsmBB пока на уровне прототипа и нет никаких гарантий, что Вам не надоест его разрабатывать и он дотянет до production-ready состояния в ближайшие пару лет.
Несколько тысяч пользователей для форума — это мелочи, можно взять любой движок с активным комьюнити, поддержкой и расширениями.
Договора подряда как физ.лицо можно заключать, но невыгодно… 13% надо отдать в налоговую. А для ИП на УСН — 6%, часть из которых идёт в ПФР. Правда, у ИП есть ещё всякие расходы, типа платы за расчётный счёт и т.п., но это 20-30 т.р. в год. Но это, как правило, всё равно меньше 7% от годового дохода.
Для Elixir есть Phoenix.
Тогда уж N2O, а то Zotonic больше на аналог Wordpress тянет.
Основное отличие Elixir от Erlang — это возможности метапрограммирования в стиле Lisp, ну и более удобный тулинг. Остальное — по сути либо следствия, либо мелочи.
P.S. Мутабельности данных в Elixir нет, есть ребиндинг переменных, но это совсем не то же самое.
Да, только это медленнее побайтового сравнения будет, если нужно всего один раз за время выполнения программы эту проверку вызывать.
А если надо много проверок, то, как я выше написал, это и на ЯВУ будет HashSet, который под капотом сделает то же самое, что Ваш код, только с большим количеством проверок.
Скорее они думают на разных уровнях абстракции, и это вполне очевидно.
С этим я согласен, т.к. у компилятора нет задачи сделать код читабельным.
Кроме того johnfound подменил изначальную задачу "поиск строки в массиве строк" на "добавление строки в уникальное множество строк". Т.е. сразу взял случай, когда проверка наличия строки в множестве будет выполняться часто. Однако, для таких случаев практически в любом ЯВУ есть класс/структура типа HashSet, которая работает с произвольными объектами, проверяя уникальность добавляемого объекта неожиданно при помощи метода GetHashCode.
Ещё есть freelancer.com, guru.com и peopleperhour.com. Хотя, имхо, более интересное направление — это работа с заказчиками напрямую.
Плюс есть ещё созвучное to grin
Переводить сленг в Google Translate — это провальная идея…
Ближайшее по смыслу сленговое словечко будет to green.
Ну, кстати, load time у Вас получился 0.35 секунды (против 0.97 у демо asmbb), даже несмотря на то, что оставили без объединения 3 CSS и 3 JS-файла. Так что отзывчивость сайта оказалась почти в 3 раза лучше, просто за счёт более хорошего хостинга.
Это не так чтобы очень долго, но и не быстро. Считается, что меньше 2 секунд — это приемлемый результат для среднестатистического сайта.
Но, учитывая достаточно простой дизайн (малое кол-во картинок и CSS) и практически пустую БД, можно было ожидать хотя бы в районе 0.5 секунды.
Обратите внимание, что у Вас плохие показатели по Initial connection и по TTFB. Не факт, что Вы можете на них повлиять, т.к. они зависят от настроек сервера. Но дело в том, что они добавляют сотни миллисекунд оверхеда, на фоне которых экономия пары миллисекунд за счёт применения ассемблера совсем потерялась.
Ассемблер то быстрый, а сайт получился медленный:
При оптимизации сайтов главная метрика — load time, а не время генерации на сервере. Да и временем генерации ответа за миллисекунды сложно удивить, было бы меньше 1 ms — было бы круто. А текущие результаты (6 — 30 ms) можно и на ЯВУ воспроизвести. Т.е. в теории выигрыш от применения ассемблера должен быть, но на данном примере его не видно.
Ну, ё-моё, опять 25… Забудьте Вы уже про скорость… Абстрагируйтесь от неё, если морфологическое сходство слов вас так сильно запутывает. Тем более, что такого термина как "скорость выполнения" в принципе нет в бенчмарках.
Бенчмарки меряют время ожидания (latency в секундах) и считают пропускную способность (throughput в ips или в rps).
При этом изменения latency обычно считают в процентах, а изменения throughput — в разах.
Ускорилось на 50% = latency уменьшилось на 50% = throughput вырос в 2 раза = ускорилось в 2 раза.
Вы же пытаетесь ввести какую-то свою терминологию, и не понятно откуда Вы её вообще взяли… Мне прям даже интересно на базе чего Вы так упорствуете… Дайте хоть ссылку на какую-нибудь benchmark-утилиту, которая вашей методологии подсчётов придерживается.