Pull to refresh
28
0
Viktor Taranenko @sndl

User

Send message

Максимальный лимит по питанию выставить надо будет на уровне 300-350 ватт, что скорее всего даст просадку как минимум на 20-30% по производительности (владельцы 4090 пожалуйста дайте точную цифру);

при выставлении 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 я забыл многие основы линейной алгебры, забыл специфики фреймворков.

В текущем положении я активно работаю над тем, чтобы уменьшить круг своих экспертиз.
Но напомню, когда-то я был более полезен как универсал

то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin

Если у команды нет опыта на Scala, то может и стоит. В противном случае если есть экспертиза я не вижу смысла мигрировать на Kotlin.
Я вижу большую проблему адаптации Scala с нуля, с очень большой фрагментацией подходов и стилей библиотек. Но если у команды есть обозначеный путь и политика в отношении выбора, то разработка становится очень продуктивной и сильно превосходит Kotlin с его пока еще неразвитой экосистемой
Я соглашусь, Scala позволяет писать высоабстрактный и «совершенный» код и этим притягивает определенный круг разработчиков, но дальше все зависит от индивидуальности разработчиков и культуры команды.

У нас, например, поощряется писать более простой код, хоть иногда и чуть больше, а иногда и чуть продублировать.

Apache Spark со своим style guide пример как огромное количество котрибьютеров с разным бэкгроундом может работать над одной большой кодовой базой

Twitter — отличный пример из индустрии, избегающий все упомянутые высокоабстрактные архитектуры и продолжающий с успехом использовать Scala
Да, это альтернатива, не дополнение.

Даже если в Gradle решаются проблемы с вычленением измененных модулей, он все равно другой по архитектуре. Там не поощряются (как минимум раньше) модули маленького (пакетного) размера.

Bazel — в свою очередь сравнимое с Pants
В идеале: один репозиторий – один модуль.


Не совсем согласен, от модулей маленького размера можно получить много преимуществ и не придется создавать сотни репозиториев.

С описанным в статье нам в компании очень помогает Pants, там эта функциональность идет из коробки

./pants changed --include-dependees=transitive --changes-since=f61ad76d5d37d8dae6f1c298e1365af423d9892e

Вот такой командой можно например получить список всех модулей, которые затронули изменения после определенного git коммита.

Дальше для этих модулей мы можем выполнять тесты, собирать артефакты, если требуется и так далее.

В результате имеем преимущества одного репозитория и сборка не страдает.
Cинхронность RPC в настоящее время никак не предпочтительна. Насчет отличий Messaging, которые Вы приводите, согласен. Но Ваше (и мое) понятие этого термина существенно отличается от того, что приводится в этой статье.

C картинки Messaging описывается как:

Response GetPerson(Request request)

В пример приводятся веб-сервисы, контракты и тд…
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 для каждого из интересующих сервисов
Из письма, которое я получил
Please note that the SSD drives in the D-series are non-persistent.

Что делает практически невозможным разместить директорию с данными (Mongodb, Cassandra...) на них.
Когда они перестанут быть временными?
Из собственной практики, sbt в систему никогда не устанавливаю. Вместе этого кладу базовый скрипт в директорию проекта. Упрощает процесс запуска на других машинах, так как не требует дополнительных установок и версия указана непосредственно в системе контроля версий.

Получается что для сборки проекта в системе необходима только Java.
То, на что дана ссылка в статье — введение. (Getting Started with sbt). Она делает довольно краткий и хороший обзор возможностей и основных концепций sbt.

За подробностями можно обратиться в «sbt Reference Manual» www.scala-sbt.org/0.13/docs/index.html

Как я понимаю, этот файл используется не только указанным Вами скриптом, но и launcher'ом, установка которого описана в системе. В системе может быть установлен sbt 0.13.0 а в build.properties указан 0.13.5. Тогда именно библиотеки последнего будут загружены при запуске и использоваться при сборке

www.scala-sbt.org/0.13.2/docs/Community/Nightly-Builds.html
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 или что-либо другое будет сначала получать документ на клиент, смотреть на что он ссылается и подтягивать это следующими запросами.
ACID транзакций и джоинов нет также и в Riak, Cassandra, HBase, что не делает их менее «продвинутыми».

Заголовок абсолютно желтый. Нет ничего специфичного для MongoDB, кроме как конкретный попробованный пример документо-ориентированной базы данных. Такой критикой можно ударить по бОльшей части NoSQL продуктов, которые, как показывает практика, могут успешно использоваться и без непосредственной связи между таблицами.
И объясните мне, пожалуйста. Если все-таки решение с потоками возможно для V8 через расширение, в чем смысл запуска eventloop на одном потоке? Почему нельзя его запустить на пуле из потоков (= число процессоров)? Какие у этого подхода недостатки в сравнении с кластером из такого же количества нодов?

Потому что я вижу только преимущества.
Что я упускаю?

Information

Rating
Does not participate
Location
Birmingham, England - West Midlands, Великобритания
Date of birth
Registered
Activity