Не выдумывайте! Считать не умеете Вы… Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.
Можно взять другие тесты.
Можно, только зачем, если в среднестатическом случае (для вышеописанного класса задач) 70% времени всё равно придётся на запросы к БД. Даже если весь остальной код будет выполняться за пару наносекунд, Вы всё равно получите лишь 30% ускорения. Учитывайте матчасть, а не только синтетику.
Если язык разработки будет статически и строго типизированным и компилируемым
Отличная идея! Только причём тут low-level? В ассемблере типизации вообще нет, в Си она слабая… А под Ваш критерий лучше подходит Haskell, или Idris, или на крайний случай Crystal.
Интерпретатор проигрывает маш.коду в 100 раз. Это на 9900%
Какая у Вас интересная версия математики… в 100 раз быстрее == на 99% быстрее.
Только причём тут это вообще? Я же написал "на данном классе задач", т.е. рендеринг простеньких HTML-страниц на основании данных, полученных из реляционной СУБД.
Каким боком тут Dhrystone, актуальность которого осталась где-то в 80-х? Или при взгляде на великолепные результаты ассемблера в синтетическом бенчмарке у вас автомагически SQL быстрее работать начинает?
PostgreSQL и MySQL иногда трудно использовать на виртуальном хостинге.
Это наверно большая редкость… Хоть я уже лет 7 вирутальным хостингом не пользуюсь, но не помню, чтобы с этим хоть раз были проблемы… Неужели за предыдущие 7 лет ситуация с виртуальным хостингом так ухудшилась?
Производительность на демо сервере сравнивать не очень удобно. Там у провайдера есть какое-то распределение ресурсов и иногда все начинает работать 2..3 раза медленнее.
Не, дело не в этом. Да, иногда по тегу и больше 100 мс ответ занимает, но чаще всего попадает в диапазон 20-30 мс и тут явно есть performance-bug.
P.S. Ещё на порядок сортировки тредов обратите внимание:
Движки форумов тоже разные по степени навороченности бывают. Если честно сравнивать, то затраты на SQL будут одинаковые. А дальше идет разница: время ответа HTTP-сервера (не более 0.02 мс везде), шаблонизатор (тут большую часть времени отожрёт Markdown, так что тоже будет примерно одинаково), оверхэд на ORM/QueryBuilder (в данном случае он небольшой, т.к. запросы тривиальные), вспомагательные мидлвары.
Другими словами, я бы не ожидал ускорения за счёт применения ассемблера более, чем на 20-30% при честном сравнении на данном классе задач.
Проект впечатляет, хотя скорее тем, что целиком на асме, а не скоростью работы.
Непонятно почему выбран SQLite, а не PostreSQL или MySQL. Очевидно же, что SQLite — далеко не самая быстрая СУБД.
Кроме того заметил, что поиск тредов по тегу сильно проседает: ~ 20 мс против ~ 7 мс на показ списка всех тредов. Проверьте индексы в таблице пересечения (ThreadTags), думаю, добавление индекса по Tag улучшит ситуацию.
Количество пользователей Angular 2 сокращается. На момент релиза 2 сообщалось о том, что 1.3 миллиона разработчиков используют Angular 1 и 480 тысяч уже используют Angular 2.
Я думаю, разгадка в том, что инфографика (по кол-ву пользователей) в статье датирована маем, а релиз состоялся в сентябре.
Если посмотреть на первую версию демократии, то там народом считались (обладали правом голоса) всего 15% от населения. Кроме того есть ещё этнократия (власть элиты) и охлократия (власть толпы).
А всё дело в том, что при переводе с греческого и демос, и этнос, и охлос переводятся как народ, хотя в оригинале это совсем не синонимы.
P.S. Кстати, олигархия — это власть богатых, а не элиты.
А "фишка" пытаться делать игру без бюджета в том, что бюджета на игру нет, а сделать хочется.
Я имел в виду, что без бюджета и с нуля сделать что-то с приличной графикой нереально.
UE4 — уже другое дело, но автор, судя по статье ничего такого не использует… вот этому я и удивляюсь.
А в чём фишка без бюджета пытаться делать игру с нуля? Можно ведь взять какой-нибудь Project Spark (примеры игр) или что-то аналогичное и разработка игры упростится на порядок.
Честно говоря, после такого объяснения сложно понять зачем нужен HTML… В Word и в GoogleDocs тоже гиперссылки можно вставлять, а с ваших слов это чуть ли не единственное отличие… Думаю, полезно было бы начать с рассказа про декларативность и про отличия такого подхода от WYSIWYG.
Ну, если Вы в США живёте, как в профиле указано, то я действительно не в курсе юридических тонкостей. Хотя по идее апворк — американская контора, это у нас с ней лишние заморочки в виде перевода оферты, подписания актов в тех.поддержке и прочей ереси..
И у Вас за 2 года ни разу не возникло ощущения, что Вы зря трекаете время?
Это же совершенно не имеет смысла при фуллтайм-занятости. Если только совсем нет доверия у работодателя к Вам, а у Вас к работодателю и вы оба платите апворку, чтобы он вам что-то гарантировал.
Это ваша личная заморочка — про эффективные часы и оплату только их. Это должно пройти со временем.
Может это и личная заморочка, но на мой взгляд это самый справедливый подход для обеих сторон, этакий win-win. На тему эффективных часов, можно для примера тут почитать.
Если совсем уж грубо, то разница между нашими подходами лишь в определении часовой ставки, для меня она равна 1/100 от зарплаты за полную занятость по ТК, для Вас видимо — 1/168.
В целом же, оплате подлежит именно что "время на работе". Ибо именно его вы и продаёте (и не будь работы — занялись бы чем нибудь иным).
А Вы не думали, что если не работается, то реально можно заняться чем-нибудь другим, вместо того, чтобы сидеть прокрастинировать.
Да никак. В офисе просто фиксированная оплата за месяц. Работать при этом можно хоть 2-3 часа в день, как и делают по факту очень многие нанятые сотрудники. Конечно, публично об этом никто не напишет, но все всё прекрасно знают. Есть и другая крайность, когда всякими ухищрениями программистов заставляют работать часов по 9 в день. Но, честно говоря, интересно было бы сравнить… лично по моему опыту, могу сказать, что программист, который в полную силу работает 3 часа в день, сделает за 3 месяца больше, чем программист, который пытается выжать 9 часов в день на протяжении того же срока.
Если заказчик нанимает разработчика на полный рабочий день
Так я про это и говорю, не надо путать почасовку и удалённую работу на фуллтайм (тот же офис, только из дома).
Не исключаю, что есть зависимость от типа проектов и других факторов. Например, я простые задачи чаще всего делегирую. Ваш же вариант может работать, когда Вы в одиночку работаете над проектом.
Да, тоже вариант. Он мне просто по субъективным причинам (не относящимся к типизации) меньше нравится, чем вышеуказанные языки.
Не выдумывайте! Считать не умеете Вы… Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.
Можно, только зачем, если в среднестатическом случае (для вышеописанного класса задач) 70% времени всё равно придётся на запросы к БД. Даже если весь остальной код будет выполняться за пару наносекунд, Вы всё равно получите лишь 30% ускорения. Учитывайте матчасть, а не только синтетику.
Ok, шляпка шурупчика не особо привлекает внимание.
Отличная идея! Только причём тут low-level? В ассемблере типизации вообще нет, в Си она слабая… А под Ваш критерий лучше подходит Haskell, или Idris, или на крайний случай Crystal.
Какая у Вас интересная версия математики… в 100 раз быстрее == на 99% быстрее.
Только причём тут это вообще? Я же написал "на данном классе задач", т.е. рендеринг простеньких HTML-страниц на основании данных, полученных из реляционной СУБД.
Каким боком тут Dhrystone, актуальность которого осталась где-то в 80-х? Или при взгляде на великолепные результаты ассемблера в синтетическом бенчмарке у вас автомагически SQL быстрее работать начинает?
Это наверно большая редкость… Хоть я уже лет 7 вирутальным хостингом не пользуюсь, но не помню, чтобы с этим хоть раз были проблемы… Неужели за предыдущие 7 лет ситуация с виртуальным хостингом так ухудшилась?
Не, дело не в этом. Да, иногда по тегу и больше 100 мс ответ занимает, но чаще всего попадает в диапазон 20-30 мс и тут явно есть performance-bug.
P.S. Ещё на порядок сортировки тредов обратите внимание:
Движки форумов тоже разные по степени навороченности бывают. Если честно сравнивать, то затраты на SQL будут одинаковые. А дальше идет разница: время ответа HTTP-сервера (не более 0.02 мс везде), шаблонизатор (тут большую часть времени отожрёт Markdown, так что тоже будет примерно одинаково), оверхэд на ORM/QueryBuilder (в данном случае он небольшой, т.к. запросы тривиальные), вспомагательные мидлвары.
Другими словами, я бы не ожидал ускорения за счёт применения ассемблера более, чем на 20-30% при честном сравнении на данном классе задач.
Проект впечатляет, хотя скорее тем, что целиком на асме, а не скоростью работы.
Непонятно почему выбран SQLite, а не PostreSQL или MySQL. Очевидно же, что SQLite — далеко не самая быстрая СУБД.
Кроме того заметил, что поиск тредов по тегу сильно проседает: ~ 20 мс против ~ 7 мс на показ списка всех тредов. Проверьте индексы в таблице пересечения (ThreadTags), думаю, добавление индекса по Tag улучшит ситуацию.
Я думаю, разгадка в том, что инфографика (по кол-ву пользователей) в статье датирована маем, а релиз состоялся в сентябре.
Если посмотреть на первую версию демократии, то там народом считались (обладали правом голоса) всего 15% от населения. Кроме того есть ещё этнократия (власть элиты) и охлократия (власть толпы).
А всё дело в том, что при переводе с греческого и демос, и этнос, и охлос переводятся как народ, хотя в оригинале это совсем не синонимы.
P.S. Кстати, олигархия — это власть богатых, а не элиты.
Я имел в виду, что без бюджета и с нуля сделать что-то с приличной графикой нереально.
UE4 — уже другое дело, но автор, судя по статье ничего такого не использует… вот этому я и удивляюсь.
А в чём фишка без бюджета пытаться делать игру с нуля? Можно ведь взять какой-нибудь Project Spark (примеры игр) или что-то аналогичное и разработка игры упростится на порядок.
Честно говоря, после такого объяснения сложно понять зачем нужен HTML… В Word и в GoogleDocs тоже гиперссылки можно вставлять, а с ваших слов это чуть ли не единственное отличие… Думаю, полезно было бы начать с рассказа про декларативность и про отличия такого подхода от WYSIWYG.
С этим я согласен. Я не считаю только отвлечения (более 15 минут уже в зачёт не идут).
Кстати, хороший вариант, время и длительность пиков можно в индивидуальном порядке подбирать. Но у Вас, кстати, получилось 7 часов, а не 8 ;-)
Ну, если Вы в США живёте, как в профиле указано, то я действительно не в курсе юридических тонкостей. Хотя по идее апворк — американская контора, это у нас с ней лишние заморочки в виде перевода оферты, подписания актов в тех.поддержке и прочей ереси..
И у Вас за 2 года ни разу не возникло ощущения, что Вы зря трекаете время?
Это же совершенно не имеет смысла при фуллтайм-занятости. Если только совсем нет доверия у работодателя к Вам, а у Вас к работодателю и вы оба платите апворку, чтобы он вам что-то гарантировал.
Может это и личная заморочка, но на мой взгляд это самый справедливый подход для обеих сторон, этакий win-win. На тему эффективных часов, можно для примера тут почитать.
Если совсем уж грубо, то разница между нашими подходами лишь в определении часовой ставки, для меня она равна 1/100 от зарплаты за полную занятость по ТК, для Вас видимо — 1/168.
А Вы не думали, что если не работается, то реально можно заняться чем-нибудь другим, вместо того, чтобы сидеть прокрастинировать.
С чего Вы это взяли? Перечитайте моё сообщение полностью.
Да никак. В офисе просто фиксированная оплата за месяц. Работать при этом можно хоть 2-3 часа в день, как и делают по факту очень многие нанятые сотрудники. Конечно, публично об этом никто не напишет, но все всё прекрасно знают. Есть и другая крайность, когда всякими ухищрениями программистов заставляют работать часов по 9 в день. Но, честно говоря, интересно было бы сравнить… лично по моему опыту, могу сказать, что программист, который в полную силу работает 3 часа в день, сделает за 3 месяца больше, чем программист, который пытается выжать 9 часов в день на протяжении того же срока.
Так я про это и говорю, не надо путать почасовку и удалённую работу на фуллтайм (тот же офис, только из дома).
Не исключаю, что есть зависимость от типа проектов и других факторов. Например, я простые задачи чаще всего делегирую. Ваш же вариант может работать, когда Вы в одиночку работаете над проектом.