Да, сегодня смотрел.
Из-за FastCGI есть накладные расходы на коммуникацию и производительность не ахти.
Выглядит юзабельно, но некоторые вещи морально устарели.
Плохой подарок: ABI и libdispatch отваливается местами, стабильность под Linux'ом стремится к нулю.
Пока будут переписывать стандартную библиотеку, чинить всё… в надежде что хомячков набежит за яблочками, но, как оказалось, хомячкам их придётся самостоятельно спавнить, что собственно не тортъ, и качество яблок канет в лету.
С точки зрения соотношения производительности и соответствующих рисков у каждого окружения есть свои особенности.
Я сейчас потиху перебираюсь в DPDK JNA Netty Disruptor с самописными асинхронными конекторами под PostgreSQL и ScyllaDB, нужно offheap'ить много в MapDB, определять пулы объектов в directBuffer'ах netty, чтобы уменьшать давление на GC, но и задачи у меня довольно специфические. Не брезгую groovy, но вот в Scala overhead'ы получаются довольно большие.
Даже в том же Go тонна проблем, хорошо что запилили нормальное GC, как у Java 5 :|, особенно сильно меня кумарит отсутствие методов для динамического программирования — нужна кодогенерация, и даже самый банальный strcmp не использует simd оптимизации, очень много чего нужно переписывать ручками на asm'ик. Для примера можно взять тот же ffjson, как единственную нормальную реализацию json сериализации под golang, с кодогенерацией и golang'овским asm'ом в нужных местах.
Учить/не учить — сложно сказать, я видел over 100500 которые слазили с node/ruby/python/php на golang из-за его производительности, но, конечно, до правильно приготовленной неэнтерпрайсовской Java, по рецепту указанному выше, всему этому ширпотребу ещё далеко.
Rust не использую просто по причине плохого дизайна стандартной библиотеки — хрен его знает когда она будет стабильной.
Естественно вопрос are we web yet стоит комом. Вот у Swift'a под вэб сейчас вроде как ничего не видел.
Nimrod подаёт надежды, но его использование в продакшене связано с кучей рисков.
Сейчас требования к этому всему барахлу довольно специфические: нужны disruptor'ы, cqrs-es для пущих реактивностей и шаблонные REST CRUD мапперы для DataMapper ORM'ов, потом это всё ещё нужно обернуть вокруг SOA и сделать вменяемый менеджер зависимостей и интеграции. Большинство хомячков своё мировозрение держит в пределах MVC, и это печалит.
CQL/SQL — те же яйца только в профиль, сам по себе ANSI SQL прям такой уж киллер-фичей не является.
Тут смысл в производительности, быстрее просто вряд ли получится сделать — scylladb очень хорошо вертикально масштабируется.
Я бы сказал что даже не представляю как это делать более эффективно, точнее представляю, но подобные вещи пока лабораторий не покидали, разве что на выставках показывались.
По поводу конкуренции — для колоночных БД нужно использовать специфические, для каждой конкретной задачи, методы индексации, по этому сравнивать их между собой не совсем корректно. Вот эффективность реализаций каких-то MVP-tree / X-tree / Fusion-tree cache oblivious структур — вполне даже.
Я вот сижу, пишу gulp-seed под React с JSPM + System.js.
В планах, краулер на webdriver.io — чтобы странички в uncss пихать без подобных заморочек с кириллицей и всяким прочим.
Комментарии, форки и звёздочки приветствуются.
Собственно на картинке в хабракате есть одна большая неточность: Naive Bayes, Logistic Regretion, SVM — это методы, а xgboost это библиотека для распределенного бустинга градиентов, что само по себе достаточно распространённая методика, которая используется для связки нескольких алгоритмов классификации для получения более точных результатов, её особенностью является генерализация и последующая возможность оптимизации простых дифференцируемых функций потерь.
Нужно понимать что тут нет методов которые чем-то лучше, или хуже — просто они по разному подходят для решения тех, или иных задач.
«Рейтинги» составлять — довольно нелепое занятие.
Автору вряд ли удастся получить одобрение, без понимания почему нужно возвращать поток с задачи
gulp.task('default', function () {
[return] gulp.src('src/*.html')
.pipe(pagebuilder('src'))
.pipe(gulp.dest('build/'));
});
Уже раз пятый об этом пишу…
Надо было сначала спросить на тостере, а то выглядит очень нелепо.
Что бы получить правильный ответ — нужно задать правильный вопрос.
Хотите чему-то научится или разобраться — зачем об это статьи писать?
1. Приложение обновить/перезапустить можно только в горячую, и то не всегда. Задержка на перезапуск обычно не может быть больше 7-10ms. Обычно использую 1G. Для выпиливания GC нужен патч в 300 строчек С++.
2. Если в этом самом кольцевом буфере выделять статические объекты для работы с различными сущностями — отпадает потребность в реализации пулов и мультитонов, но это требует специфического подхода в разработке, и позволяет один раз выделить память «под всё» и полностью остановить сборку мусора.
3. На самом деле время вычисления hashcode может быть в 2-3 раза более ресурсоёмко нежели создание самого объекта и выполнения нужного кода, и для абстрактных Netty в вакууме его реализация без псевдо-случайностей часто бывает на много шустрее.
Эм, ну бэнчмарк малость неактуален и «туговат».
Нету ничего странного что при upstream'e на TCP'шном сокете производительно в 1.5-2 раза падает, но подобные бэнчмарки непосредственно к производительности самого golang'a отношения не имеют, хотя бы из-за «100 потоков по 500 соединений» и радости от 17-120ms задержек на древнем 1.2 runtime. А сабж вообще о нецелесообразности использования nginx балансера поврех golang'a, что вообщем-то должно быть совсем «как бы кэп» очевидно.
В общем я и не думаю что мне стоит здесь так распинаться по поводу производительности, которая в 99% случаев никому не нужна.
Буду в очередной раз оскорблять чувства «верующих» и читать разнообразные бесполезности.
Попробуйте аргументировать свой скептицизм и разобраться в личных целях подобных комментариев.
Фраза по поводу «серебряной пули» мной расценена как психологическая проекция.
Из-за FastCGI есть накладные расходы на коммуникацию и производительность не ахти.
Выглядит юзабельно, но некоторые вещи морально устарели.
Пока будут переписывать стандартную библиотеку, чинить всё… в надежде что хомячков набежит за яблочками, но, как оказалось, хомячкам их придётся самостоятельно спавнить, что собственно не тортъ, и качество яблок канет в лету.
Пока юзабельно только для яблок :|
Я сейчас потиху перебираюсь в DPDK JNA Netty Disruptor с самописными асинхронными конекторами под PostgreSQL и ScyllaDB, нужно offheap'ить много в MapDB, определять пулы объектов в directBuffer'ах netty, чтобы уменьшать давление на GC, но и задачи у меня довольно специфические. Не брезгую groovy, но вот в Scala overhead'ы получаются довольно большие.
Даже в том же Go тонна проблем, хорошо что запилили нормальное GC, как у Java 5 :|, особенно сильно меня кумарит отсутствие методов для динамического программирования — нужна кодогенерация, и даже самый банальный strcmp не использует simd оптимизации, очень много чего нужно переписывать ручками на asm'ик. Для примера можно взять тот же ffjson, как единственную нормальную реализацию json сериализации под golang, с кодогенерацией и golang'овским asm'ом в нужных местах.
Учить/не учить — сложно сказать, я видел over 100500 которые слазили с node/ruby/python/php на golang из-за его производительности, но, конечно, до правильно приготовленной неэнтерпрайсовской Java, по рецепту указанному выше, всему этому ширпотребу ещё далеко.
Rust не использую просто по причине плохого дизайна стандартной библиотеки — хрен его знает когда она будет стабильной.
Естественно вопрос are we web yet стоит комом. Вот у Swift'a под вэб сейчас вроде как ничего не видел.
Nimrod подаёт надежды, но его использование в продакшене связано с кучей рисков.
Сейчас требования к этому всему барахлу довольно специфические: нужны disruptor'ы, cqrs-es для пущих реактивностей и шаблонные REST CRUD мапперы для DataMapper ORM'ов, потом это всё ещё нужно обернуть вокруг SOA и сделать вменяемый менеджер зависимостей и интеграции. Большинство хомячков своё мировозрение держит в пределах MVC, и это печалит.
Спасибо Apple.
Тут смысл в производительности, быстрее просто вряд ли получится сделать — scylladb очень хорошо вертикально масштабируется.
Я бы сказал что даже не представляю как это делать более эффективно, точнее представляю, но подобные вещи пока лабораторий не покидали, разве что на выставках показывались.
По поводу конкуренции — для колоночных БД нужно использовать специфические, для каждой конкретной задачи, методы индексации, по этому сравнивать их между собой не совсем корректно. Вот эффективность реализаций каких-то MVP-tree / X-tree / Fusion-tree cache oblivious структур — вполне даже.
В планах, краулер на webdriver.io — чтобы странички в uncss пихать без подобных заморочек с кириллицей и всяким прочим.
Комментарии, форки и звёздочки приветствуются.
Нужно понимать что тут нет методов которые чем-то лучше, или хуже — просто они по разному подходят для решения тех, или иных задач.
«Рейтинги» составлять — довольно нелепое занятие.
Уже раз пятый об этом пишу…
Надо было сначала спросить на тостере, а то выглядит очень нелепо.
Что бы получить правильный ответ — нужно задать правильный вопрос.
Хотите чему-то научится или разобраться — зачем об это статьи писать?
Или соединить все скриншоты в слайдшоу и просто оставить здесь?
Это для университетских блондинок, или для хабра?
Или для университетских блондинок на хабре…
20Мб для MySQL'я в Azure решит все проблемы студента, особенно когда есть OpenShift.
Целесообразность статьи стремится к нулю.
2. Если в этом самом кольцевом буфере выделять статические объекты для работы с различными сущностями — отпадает потребность в реализации пулов и мультитонов, но это требует специфического подхода в разработке, и позволяет один раз выделить память «под всё» и полностью остановить сборку мусора.
3. На самом деле время вычисления hashcode может быть в 2-3 раза более ресурсоёмко нежели создание самого объекта и выполнения нужного кода, и для абстрактных Netty в вакууме его реализация без псевдо-случайностей часто бывает на много шустрее.
4 канала по 40ГБит на 4ёх Virtex7 картах :|
Нету ничего странного что при upstream'e на TCP'шном сокете производительно в 1.5-2 раза падает, но подобные бэнчмарки непосредственно к производительности самого golang'a отношения не имеют, хотя бы из-за «100 потоков по 500 соединений» и радости от 17-120ms задержек на древнем 1.2 runtime. А сабж вообще о нецелесообразности использования nginx балансера поврех golang'a, что вообщем-то должно быть совсем
«как бы кэп»очевидно.В общем я и не думаю что мне стоит здесь так распинаться по поводу производительности, которая в 99% случаев никому не нужна.
Буду в очередной раз оскорблять чувства «верующих» и читать разнообразные бесполезности.
Попробуйте аргументировать свой скептицизм и разобраться в личных целях подобных комментариев.
Фраза по поводу «серебряной пули» мной расценена как психологическая проекция.