Основное отличие 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-утилиту, которая вашей методологии подсчётов придерживается.
Автор конечно крут, но надо учитывать сколько лет он до этого писал на ассемблере… Я думаю, если взять такой же опыт в веб-программировании, то все абстракции будут уже давно вкурены и изучить какой-нибудь ещё один фреймворк можно будет за день :-)
Было бы интересно (откровенно говоря только в этом и интерес) провести полное нагрузочное тестирование этого решения.
Тут есть проблемка… Автор хорошо разбирается в ассемблере, но плохо в веб-программировании… Поэтому сайт получился не особо быстрый с точки зрения пользователя. Для примера запустил простенький тест на LoadImpact. VU load time получился в районе 2.3 секунды (даже всего при 3 посетителях), это уже медленно.
Так что устраивать серьёзное нагрузочное тестирование смысла нет. Веб-сервер скорее всего не настроен должным образом и просто захлебнется под нагрузкой даже не дойдя до кода автора.
Для сравнения у Хабра VU load time в районе 1.7 секунды (быстрее 2 секунд — это хороший результат).
И что? Мы измеряем время в рамках бенчмарков, ips — это производная (вычисляемая, а не измеряемая) характеристика. Ускорить алгоритм == сократить время его выполнения. Это общепринятая трактовка.
Другими словами, ускорение на 67% == ips вырос на 200%.
Поймите простую вещь, "рост ips" и "ускорение" — это не синонимы ни разу.
Было 100 ms, стало в 3 раза быстрее, т.е. стало 33 мс. Так понятнее?
Слово "ускорился" в контексте быстродействия синоним слова "подешевел".
Функция ускорилась в 2 раза == Функция подешевела в 2 раза == Стала занимать в 2 раза меньше времени.
Функция ускорилась на 50% == Функция подешевела на 50% == Стала занимать на 50% меньше времени.
Аллюзии к слову "скорость" тут совсем не в тему. У меня странное ощущение, от того, что мне приходится разжевывать такую базовую тему на Хабре… Причём эффекта ноль, никто даже не пытается задуматься над неверным пониманием этого аспекта.
Я понял Вашу отсылку к физическому понятию "скорость", но, к сожалению, как физик, вынужден отметить, что Ваши формулировки безграмотны с точки зрения физики и знак "=" там не уместен, т.к. у слова "ускорение" совершенно иной физический смысл, и ни в процентах, ни в разах оно в физике не измеряется.
Ничего я не путаю, увеличение скорости вычислений в 3 раза — это и есть сокращение времени вычислений на 67%… И то и то упрощенно называется ускорением.
А если хотите морфологией заняться, то не забывайте, что ускорение — это производная от скорости по времени, удачи в трактовке ;-)
С делением ЯВУ на классы я согласен, хотя там можно ещё интерпретаторы с JIT в отдельный класс выделить. А вот с тенденцией не согласен. Наоборот, тенденция писать на скриптовых языках слабеет с каждым годом. Народ активно смотрит в сторону Go, Elixir, Crystal, Nim, Clojure, etc.
Другое дело, что необязательно бросать все существующие наработки на PHP, Ruby, Python и JS. Во многих случаях достаточно выделить узкие места в отдельные сервисы на более быстрых языках, а ненагруженную часть проекта оставить, как есть.
P.S. Мне лично тоже нравится писать быстрый код, но опыт работы показывает, что в первую очередь бизнесу быстро нужен код, а не быстрый код.
Правильный вариант Вашего комментария звучит так:
"Ускорить на 66.(6)% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость."
P.S. Любая величина изначально принимается за 100% при расчётах. Допустим, после оптимизации стало в 3 раза быстрее, т.е. (100/3)% от начального значения, значит мы ускорили на (100 — 100/3)%.
Стало лучше. Но, справедливости ради, первоначально речь шла о потенциале ускорения от переписывания на асме. Фиг знает, причём тут потенциал замедления от обратного переписывания и к чему вдруг Вы начали его считать..
И давайте представим, что БД тоже написал «эффективный программист», на PHP…
Вы понимаете смысл оптимизации узких мест? Хранилище данных очень часто оказывается узким местом, именно поэтому в оптимизацию СУБД вложено столько человеко-лет. И несмотря на это когда нужна действительно высокая пропускная способность всё равно приходится отходить от реляционной модели.
Проблема в том, что ассемблер не поможет написать отзывчивый высоконагруженный веб-сервис… вроде и потенциал есть, но по факту граблей больше. И даже отличные знания асма, на уровне автора статьи, не застрахуют Вас от performance-ляпов, как у автора получилось со страницей тредов по тегу (20-30 мс там, где должно быть 7-8 мс). При использовании ЯВУ такие performance-ляпы встречаются реже, т.к. можно сконцентрироваться на оптимизации узких мест, не распыляясь на оптимизацию каждой функции.
Да, я потом уже почитал, что он закрылся… Печально, конечно, но посыл был в том, чтобы для экономии бюджета использовать чужие наработки в виде движков, текстур и т.д. Если делать всё самому при ограниченных ресурсах, то легче лёгкого закопаться в мелочах.
Есть ещё такое понятие Minimal Viable Product… Его можно сделать на чём угодно, лишь бы сэкономить на ресурсах, а потом его уже показывать, собирать обратную связь, искать инвесторов… И если интерес к проекту будет, то можно уже с нуля переписать.
Основное отличие 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-утилиту, которая вашей методологии подсчётов придерживается.
Автор конечно крут, но надо учитывать сколько лет он до этого писал на ассемблере… Я думаю, если взять такой же опыт в веб-программировании, то все абстракции будут уже давно вкурены и изучить какой-нибудь ещё один фреймворк можно будет за день :-)
Тут есть проблемка… Автор хорошо разбирается в ассемблере, но плохо в веб-программировании… Поэтому сайт получился не особо быстрый с точки зрения пользователя. Для примера запустил простенький тест на LoadImpact. VU load time получился в районе 2.3 секунды (даже всего при 3 посетителях), это уже медленно.
Так что устраивать серьёзное нагрузочное тестирование смысла нет. Веб-сервер скорее всего не настроен должным образом и просто захлебнется под нагрузкой даже не дойдя до кода автора.
Для сравнения у Хабра VU load time в районе 1.7 секунды (быстрее 2 секунд — это хороший результат).
И что? Мы измеряем время в рамках бенчмарков, ips — это производная (вычисляемая, а не измеряемая) характеристика. Ускорить алгоритм == сократить время его выполнения. Это общепринятая трактовка.
Другими словами, ускорение на 67% == ips вырос на 200%.
Поймите простую вещь, "рост ips" и "ускорение" — это не синонимы ни разу.
Было 100 ms, стало в 3 раза быстрее, т.е. стало 33 мс. Так понятнее?
Слово "ускорился" в контексте быстродействия синоним слова "подешевел".
Функция ускорилась в 2 раза == Функция подешевела в 2 раза == Стала занимать в 2 раза меньше времени.
Функция ускорилась на 50% == Функция подешевела на 50% == Стала занимать на 50% меньше времени.
Аллюзии к слову "скорость" тут совсем не в тему. У меня странное ощущение, от того, что мне приходится разжевывать такую базовую тему на Хабре… Причём эффекта ноль, никто даже не пытается задуматься над неверным пониманием этого аспекта.
Я понял Вашу отсылку к физическому понятию "скорость", но, к сожалению, как физик, вынужден отметить, что Ваши формулировки безграмотны с точки зрения физики и знак "=" там не уместен, т.к. у слова "ускорение" совершенно иной физический смысл, и ни в процентах, ни в разах оно в физике не измеряется.
Ничего я не путаю, увеличение скорости вычислений в 3 раза — это и есть сокращение времени вычислений на 67%… И то и то упрощенно называется ускорением.
А если хотите морфологией заняться, то не забывайте, что ускорение — это производная от скорости по времени, удачи в трактовке ;-)
С делением ЯВУ на классы я согласен, хотя там можно ещё интерпретаторы с JIT в отдельный класс выделить. А вот с тенденцией не согласен. Наоборот, тенденция писать на скриптовых языках слабеет с каждым годом. Народ активно смотрит в сторону Go, Elixir, Crystal, Nim, Clojure, etc.
Другое дело, что необязательно бросать все существующие наработки на PHP, Ruby, Python и JS. Во многих случаях достаточно выделить узкие места в отдельные сервисы на более быстрых языках, а ненагруженную часть проекта оставить, как есть.
P.S. Мне лично тоже нравится писать быстрый код, но опыт работы показывает, что в первую очередь бизнесу быстро нужен код, а не быстрый код.
Правильный вариант Вашего комментария звучит так:
"Ускорить на 66.(6)% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость."
P.S. Любая величина изначально принимается за 100% при расчётах. Допустим, после оптимизации стало в 3 раза быстрее, т.е. (100/3)% от начального значения, значит мы ускорили на (100 — 100/3)%.
Стало лучше. Но, справедливости ради, первоначально речь шла о потенциале ускорения от переписывания на асме. Фиг знает, причём тут потенциал замедления от обратного переписывания и к чему вдруг Вы начали его считать..
Вы понимаете смысл оптимизации узких мест? Хранилище данных очень часто оказывается узким местом, именно поэтому в оптимизацию СУБД вложено столько человеко-лет. И несмотря на это когда нужна действительно высокая пропускная способность всё равно приходится отходить от реляционной модели.
Проблема в том, что ассемблер не поможет написать отзывчивый высоконагруженный веб-сервис… вроде и потенциал есть, но по факту граблей больше. И даже отличные знания асма, на уровне автора статьи, не застрахуют Вас от performance-ляпов, как у автора получилось со страницей тредов по тегу (20-30 мс там, где должно быть 7-8 мс). При использовании ЯВУ такие performance-ляпы встречаются реже, т.к. можно сконцентрироваться на оптимизации узких мест, не распыляясь на оптимизацию каждой функции.
Да, я потом уже почитал, что он закрылся… Печально, конечно, но посыл был в том, чтобы для экономии бюджета использовать чужие наработки в виде движков, текстур и т.д. Если делать всё самому при ограниченных ресурсах, то легче лёгкого закопаться в мелочах.
Есть ещё такое понятие Minimal Viable Product… Его можно сделать на чём угодно, лишь бы сэкономить на ресурсах, а потом его уже показывать, собирать обратную связь, искать инвесторов… И если интерес к проекту будет, то можно уже с нуля переписать.