Максимальный лимит по питанию выставить надо будет на уровне 300-350 ватт, что скорее всего даст просадку как минимум на 20-30% по производительности (владельцы 4090 пожалуйста дайте точную цифру);
Как-то все переусложнено и большая поляризация. Все зависит от нужд проекта и требований к Вам
Я занимаюсь триатлоном и получаю от этого удовольствие пока от меня не требуют побеждать или быть впереди в отдельных заплывах или велогонках.
Если в триатлоне я могу финишировать в первых 5-10%, то в отдельной велогонке я буду в первых 40-50%
Также и технологиями, когда-то в начинующей компании я был сильно полезен как универсал. Появилась потребность масштабироваться, копать вглубь и развивать новые сервисы, я уже меньше подхожу и всячески пытаюсь избавиться от как можно больших направлений, чтобы оставить минимум для фокуса
Я занимаюсь элементами:
— стратегии
— продукта
— инфраструктуры
— общего бекэнда
— машинное обучение
— аналитика
Как результат:
— недостаточно времени для погружения в исследования по продукту
— я не умею нормально пользоваться утилитами производительности в linux и иногда дела решаются вертикальным масшабированием. Из примера, оказалась что мы около года запускали Mongo с неоптимальными параметрами диска и можно было сильно улучшить
— когда раньше раз в год падал Kubernetes кластер, я не мог понять куда копать и просто создал новый
— я потерял способность писать и читать аналитические sql запросы. Занимает время осмыслить новые функции
— в перерыве работы с ML я забыл многие основы линейной алгебры, забыл специфики фреймворков.
В текущем положении я активно работаю над тем, чтобы уменьшить круг своих экспертиз.
Но напомню, когда-то я был более полезен как универсал
то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin
Если у команды нет опыта на Scala, то может и стоит. В противном случае если есть экспертиза я не вижу смысла мигрировать на Kotlin.
Я вижу большую проблему адаптации Scala с нуля, с очень большой фрагментацией подходов и стилей библиотек. Но если у команды есть обозначеный путь и политика в отношении выбора, то разработка становится очень продуктивной и сильно превосходит Kotlin с его пока еще неразвитой экосистемой
Я соглашусь, Scala позволяет писать высоабстрактный и «совершенный» код и этим притягивает определенный круг разработчиков, но дальше все зависит от индивидуальности разработчиков и культуры команды.
У нас, например, поощряется писать более простой код, хоть иногда и чуть больше, а иногда и чуть продублировать.
Apache Spark со своим style guide пример как огромное количество котрибьютеров с разным бэкгроундом может работать над одной большой кодовой базой
Twitter — отличный пример из индустрии, избегающий все упомянутые высокоабстрактные архитектуры и продолжающий с успехом использовать Scala
Даже если в Gradle решаются проблемы с вычленением измененных модулей, он все равно другой по архитектуре. Там не поощряются (как минимум раньше) модули маленького (пакетного) размера.
Cинхронность RPC в настоящее время никак не предпочтительна. Насчет отличий Messaging, которые Вы приводите, согласен. Но Ваше (и мое) понятие этого термина существенно отличается от того, что приводится в этой статье.
RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.
Вы, наверное, можете сказать, что они ранние. RPC цветет и пахнет сейчас. CORBA и DCOM — не наиболее яркие предствители. Thrift, Produbuf с новым gRPC. Все вполне актуально…
Детали реализации и принципиальные отличия распределенных систем были слишком велики, чтобы решаться с помощью автоматически генерируемого кода. Постепенно пришло понимание, что факт того, что системы связывает ненадежная, медленная, низкоскоростная среда, должен быть явно отражен в коде программы.
Я не могу проследить тут логику. Кодогенерация RPC имплентацию за вас не сделает. Реализация транспорта (ненадежная, медленная, низкоскоростная среда) может быть отделена от сгенерированного кода и вообще не является проблемой присущей только RPC.
Как именно помогает с этим Messaging?.. Чем контракты веб-сервисов с конвертами (видимо, подразумевается SOAP с его Envelope) отличется от контрактов (API) в RPC?
Я извиняюсь за резкость. Просто для меня Mesosphere — как красная тряпка для быка. У кого-нибудь из присутствующих здесь, есть положительный опыт использования ЭТОГО в продакшне? Можете им поделиться?
На данный момент, абстракции от самого Mesos вполне достаточны для построения staleless приложений. Например, «запустить N инстансов приложения на серверах, где есть для этого ресурсы» (Marathon, Aurora). Но когда я последний раз проверял это не настолько просто с сервисами, которые хранят данные на диске отдельно для каждого из инстансов (Cassandra, Elasticsearch). Если при падении stateless — сервисов, их можно перезапустить где угодно, то с базами данных все несколько сложнее и Mesos расширяется в данный момент до включения и управления дисковыми ресурсами.
По моему опыту, довольно неплохо работают сервисы (имлементирующие Mesos фреймворк) хранящие данные, например, в Zookeeper. У нас неплохой опыт с развертыванием Storm кластера на Mesos. Остальное было пока на уровне экспериментов и тестов: Spark, Marathon, Chronos, но было вполне работоспособное.
ОС для датацентра, конечно, звучит очень громко на данный момент, но это все вполне возможно и остается дело за реализацией, бОльшая часть которой будет основана на умной имлементации Mesos framework для каждого из интересующих сервисов
Из собственной практики, sbt в систему никогда не устанавливаю. Вместе этого кладу базовый скрипт в директорию проекта. Упрощает процесс запуска на других машинах, так как не требует дополнительных установок и версия указана непосредственно в системе контроля версий.
Получается что для сборки проекта в системе необходима только Java.
То, на что дана ссылка в статье — введение. (Getting Started with sbt). Она делает довольно краткий и хороший обзор возможностей и основных концепций sbt.
Как я понимаю, этот файл используется не только указанным Вами скриптом, но и launcher'ом, установка которого описана в системе. В системе может быть установлен sbt 0.13.0 а в build.properties указан 0.13.5. Тогда именно библиотеки последнего будут загружены при запуске и использоваться при сборке
remember that an sbt.version setting in <build-base>/project/build.properties determines the version of sbt to use in a project. If it is not present, the default version associated with the launcher is used.
С pymongo это можно сделать подключив нужный «son_manipulator», и «джойны» будут происходить автоматический на уровне «драйвера». Под Ruby тоже не должно быть такой проблемы.
Не в этом дело. В любом случае, pymongo или что-либо другое будет сначала получать документ на клиент, смотреть на что он ссылается и подтягивать это следующими запросами.
Заголовок абсолютно желтый. Нет ничего специфичного для MongoDB, кроме как конкретный попробованный пример документо-ориентированной базы данных. Такой критикой можно ударить по бОльшей части NoSQL продуктов, которые, как показывает практика, могут успешно использоваться и без непосредственной связи между таблицами.
И объясните мне, пожалуйста. Если все-таки решение с потоками возможно для V8 через расширение, в чем смысл запуска eventloop на одном потоке? Почему нельзя его запустить на пуле из потоков (= число процессоров)? Какие у этого подхода недостатки в сравнении с кластером из такого же количества нодов?
Потому что я вижу только преимущества.
Что я упускаю?
при выставлении 350W:
(44842 Gflop/s) temps: 35 C
с Tensor Cores (-tc):
(121964 Gflop/s) temps: 35 C
Я занимаюсь триатлоном и получаю от этого удовольствие пока от меня не требуют побеждать или быть впереди в отдельных заплывах или велогонках.
Если в триатлоне я могу финишировать в первых 5-10%, то в отдельной велогонке я буду в первых 40-50%
Также и технологиями, когда-то в начинующей компании я был сильно полезен как универсал. Появилась потребность масштабироваться, копать вглубь и развивать новые сервисы, я уже меньше подхожу и всячески пытаюсь избавиться от как можно больших направлений, чтобы оставить минимум для фокуса
Я занимаюсь элементами:
— стратегии
— продукта
— инфраструктуры
— общего бекэнда
— машинное обучение
— аналитика
Как результат:
— недостаточно времени для погружения в исследования по продукту
— я не умею нормально пользоваться утилитами производительности в linux и иногда дела решаются вертикальным масшабированием. Из примера, оказалась что мы около года запускали Mongo с неоптимальными параметрами диска и можно было сильно улучшить
— когда раньше раз в год падал Kubernetes кластер, я не мог понять куда копать и просто создал новый
— я потерял способность писать и читать аналитические sql запросы. Занимает время осмыслить новые функции
— в перерыве работы с ML я забыл многие основы линейной алгебры, забыл специфики фреймворков.
В текущем положении я активно работаю над тем, чтобы уменьшить круг своих экспертиз.
Но напомню, когда-то я был более полезен как универсал
Если у команды нет опыта на Scala, то может и стоит. В противном случае если есть экспертиза я не вижу смысла мигрировать на Kotlin.
Я вижу большую проблему адаптации Scala с нуля, с очень большой фрагментацией подходов и стилей библиотек. Но если у команды есть обозначеный путь и политика в отношении выбора, то разработка становится очень продуктивной и сильно превосходит Kotlin с его пока еще неразвитой экосистемой
У нас, например, поощряется писать более простой код, хоть иногда и чуть больше, а иногда и чуть продублировать.
Apache Spark со своим style guide пример как огромное количество котрибьютеров с разным бэкгроундом может работать над одной большой кодовой базой
Twitter — отличный пример из индустрии, избегающий все упомянутые высокоабстрактные архитектуры и продолжающий с успехом использовать Scala
Даже если в Gradle решаются проблемы с вычленением измененных модулей, он все равно другой по архитектуре. Там не поощряются (как минимум раньше) модули маленького (пакетного) размера.
Bazel — в свою очередь сравнимое с Pants
Не совсем согласен, от модулей маленького размера можно получить много преимуществ и не придется создавать сотни репозиториев.
С описанным в статье нам в компании очень помогает Pants, там эта функциональность идет из коробки
Вот такой командой можно например получить список всех модулей, которые затронули изменения после определенного git коммита.
Дальше для этих модулей мы можем выполнять тесты, собирать артефакты, если требуется и так далее.
В результате имеем преимущества одного репозитория и сборка не страдает.
C картинки Messaging описывается как:
Response GetPerson(Request request)В пример приводятся веб-сервисы, контракты и тд…
Вы, наверное, можете сказать, что они ранние. RPC цветет и пахнет сейчас. CORBA и DCOM — не наиболее яркие предствители. Thrift, Produbuf с новым gRPC. Все вполне актуально…
Я не могу проследить тут логику. Кодогенерация RPC имплентацию за вас не сделает. Реализация транспорта (ненадежная, медленная, низкоскоростная среда) может быть отделена от сгенерированного кода и вообще не является проблемой присущей только RPC.
Как именно помогает с этим Messaging?.. Чем контракты веб-сервисов с конвертами (видимо, подразумевается SOAP с его Envelope) отличется от контрактов (API) в RPC?
На данный момент, абстракции от самого Mesos вполне достаточны для построения staleless приложений. Например, «запустить N инстансов приложения на серверах, где есть для этого ресурсы» (Marathon, Aurora). Но когда я последний раз проверял это не настолько просто с сервисами, которые хранят данные на диске отдельно для каждого из инстансов (Cassandra, Elasticsearch). Если при падении stateless — сервисов, их можно перезапустить где угодно, то с базами данных все несколько сложнее и Mesos расширяется в данный момент до включения и управления дисковыми ресурсами.
По моему опыту, довольно неплохо работают сервисы (имлементирующие Mesos фреймворк) хранящие данные, например, в Zookeeper. У нас неплохой опыт с развертыванием Storm кластера на Mesos. Остальное было пока на уровне экспериментов и тестов: Spark, Marathon, Chronos, но было вполне работоспособное.
ОС для датацентра, конечно, звучит очень громко на данный момент, но это все вполне возможно и остается дело за реализацией, бОльшая часть которой будет основана на умной имлементации Mesos framework для каждого из интересующих сервисов
Что делает практически невозможным разместить директорию с данными (Mongodb, Cassandra...) на них.
Когда они перестанут быть временными?
Получается что для сборки проекта в системе необходима только Java.
За подробностями можно обратиться в «sbt Reference Manual» www.scala-sbt.org/0.13/docs/index.html
www.scala-sbt.org/0.13.2/docs/Community/Nightly-Builds.html
Не в этом дело. В любом случае, pymongo или что-либо другое будет сначала получать документ на клиент, смотреть на что он ссылается и подтягивать это следующими запросами.
Потому что я вижу только преимущества.
Что я упускаю?