У нас просто своя кастомная реализация каналов, близкая по идеалогии к "каналам на стеройдах", которая при записи не лочится и в целом дает выгоду на 24 ядрах. По сути весь треш атомиков инкапсулирован внутри. Атомики сильно затрудняют на мой взгляд понимание кода. Пример альтернативной реализации каналов: https://docs.google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/pub
Тем не менее, даже если в каналах (сейчас) мьютексы, мне кажется стоит писать на каналах и отдельно уделить внимание в бенчмарках этой реализации, потому что стандартные каналы могут и проапгрейдить, а мьютексы останутся как есть. Кроме того, запись в канал - отличная абстракция, которая упрощает понимание.
Недостает варианта и бенчмарков с использованием каналов. Мьютексы дико просаживают производительсность, когда много ядер. Он все ждут анлока и в это время курят. Атомики - не решение, потому что код превращается в лапшеобразного монстра.
Придумали же изначально идиоматический вариант, когда данные модифицирует только одна горутина и выгребает из канала инфу, а все конкурентные горутины в этот канал кидают данные и дальше выполняются без остановки, если канал буферизированный.
16 оперативки маловато будет. 2-3 вирт. машины запустил и все, приехали. HP не дает добивать память, залочивая биос, да и не факт, что чипсет поддерживает.
Переходите на следующий уровень в 2021 — создание собственных продуктов с высоким содержанием интеллектуальной собственности. Заказы заказами, но результаты должны как-то накапливаться не только в виде опыта.
Тот, у которого миллиард и машина с вертикальными дверьми (на видео) — наглядно объясняет идею "no revenue". Друга Цукербега, который искал хоть какую-то выручку, очень быстро и некрасиво оставили за бортом.
В калифорнийском стартап-казино прибыль получать не принято. Да и в России, если на рынок приходит компания, которая может 10 лет работать в убыток, все ребята "на дошираке" разоряются. Микроприбыль, которой недостаточно для роста — это скорее негативный сигнал, что тема мертвая. Чтобы найти живое направление, надо тратить деньги и пробовать.
Тут уж либо играть в раздувание оценки и доли рынка, прожигая инвестиции в убыток, либо спокойно делать нишевый бизнес, который крупняку не интересен, спокойно расти как идет и не искать вложений со стороны.
Вообще ощущение полной абсурдности статьи. В фильме про Цукерберга был друг-неадекват, любитель самоокупаемости, который все бегал по рекламодателям ради копеечной выручки, когда надо было забить на всю коммерцию, делать продукт, лишь бы совладать с экспоненциальным ростом.
И все это льется в один поток. Если у вас большой трафик на запись (например, собираете телеметрию), то возможна ситуация, когда мастер справляется, а слейвы отстают безнадежно и вылечить это конфигурируя репликацию невозможно. Для понимания границ применимости.
Зенитки немного не так работают. Используются осколочные боеприпасы с программируемым подрывом. Т.е. оно летит в заданную точку, потом взрывается и прошивает осколками сферу 100 метров в диаметре. Один выстрел — как минимум один дрон, как бы не прыгал. Если плотненько пойдут — больше улов.
В середине 20 века стреляли люди, подбирая дальность подрыва, а сейчас это делает автовычислитель по оптико-электронному наведению. Порядка 80 выстрелов в минуту генерируют осколочные разрывы на высоте до 4 км. Так что сверху вывалить не получится, а ковер из тысячи дронов, огибающих рельеф очень сложно организовать.
Это должна быть очень непростая формация, чтобы подобраться всего к одной точке пво. Сейчас пока революции и появления супер-оружия не случилось, штатные средства пво способны сдержать с запасом, но тенденция неприятная.
Вот эта штука способна валить пачками дроны, чисто оптическим наведением: https://russian.rt.com/russia/article/724001-derivaciya-pvo-modul Вычислитель позволяет даже снаряды снимать. Дроны были бы серьезным оружием, если бы удалось выйти на сверхбольшое количество согласованно двигающихся аппаратов, но это очень непросто по логистике, да и дорого.
За сверхскоростным оружием, которое управляется алгоритмами, безусловно будущее. Предполагаю, что в какой-то момент даже понять что происходит на поле боя будет невозможно, без отдельного аналитического алгоритма.
На войне играет роль баланс стоимости и эффективности. Против войска с калашами выглядит как супероружие без шансов, но где такие еще остались? Если решена задача напечатать тысячи дронов недорого, то теоретически можно вывалить несколько тонн этой мелочи с высоты, и не вступать в прямое столкновение. Конечно, если не на равных, а в режиме "превосходящие силы утюжат туземцев".
Если стоит задача защиты периметра от дронов, то одним из решений будет оптико-электронное наведение скорострельного пулемета, в автоматическом режиме. Современный крейсер, например, этих дронов и так не подпустит штатными средствами, потому что сбивает автоматически крылатые ракеты и прочие мелкие цели, вплоть до снарядов. Что-то аналогичное в сухопутном варианте вполне реально выставить.
Вот одновременно пару тысяч дронов из видео создали бы нагрузку, но где же их взять дешевых столько :) Кроме экономических аспектов очень интересная логистика вырисовывается и масса сопутствующих задач. Хотя бы просто одновременно в воздух поднять реально рой, а не десять штук. Как их запускать, волнами или одновременно? Если волнами, как они будут собираться и ждать друг друга, круги нарезать в определенной формации? Пока последние взлетят, у первых уже расход топлива будет, поэтому при увеличении роя дальность упадет. Если даже одновременно удастся выпустить, пусковую площадку или сотни машин просто так не спрячешь. А если скрытно разместить, то будет немобильно. Нужно какое-то более серьезное средство доставки. Не все так просто с роями.
Китайцы поднимают ставки потихоньку. Сейчас если кто отстанет в автоматическом скоростном оружии, которое управляется программно, может оказаться беззащитным. Надеюсь у нас не пренебрегают этой темой.
Государству поиск примерно так же как дороги, мосты, стадионы, библиотеки. Инфраструктурный проект, чтобы жизнь кипела. Простому человеку хорошая дорога очень даже профит.
У поисковика могут быть разные акценты. Если не стоит задача продать как можно больше рекламы, то могли бы наверх подняться информационные/навигационные результаты, а не коммерция. Кроме того, можно поставить задачу поиска по специфическим коллекциям, архивам, законодательству. Индексировать только проверенные источники. Некий заведомо безопасный поиск без криминала, с проверенными источниками и разными вертикалями по специфическим данным. Если серьезно подойти — большая интересная задача для большого коллектива. Почему бы и не убыточный? Лишь бы качественный.
Были ли консультации с крупными компаниями обладающими реальным опытом в работе с большими объемами данных, например Яндексом? Не рассматривали вариант отдать на реализацию такой ответственный и социально-значимый сервис? Это вопрос не про деньги.
Был у меня интересный опыт обсуждения с очень неглупым сотрудником диспетчерской службы некоего эскиза приложения. Обычные экраны, состояния, вот здесь жмем кнопочку, добавляется запись, потом обновляется вот здесь. Все предельно примитивно разрисовано на листах, многие моменты упрощены. Работа проектировщика на ранней стадии. С программистами это можно обсуждать несколько часов подряд и они потом пойдут писать код, не особенно устав.
Проблема в том, что обсуждать проект приложения мы смогли примерно 10 минут, потом у моего собеседника перегрелся мозг. Ну ладно, думаю, поговорю с ее коллегами. Примерно тот же результат. При том, что эти люди работают по 8-10 часов в очень многозадачном режиме, отвлекаются посмотреть карту, зайти в одноклассники, проверить ферму, поговорить с ребенком про уроки. А вот обсуждать пространство состояний не могут.
В момент "перегрева" я по приколу сказал: представляешь, вот так целый день приходится думать. Кажется в этот момент они поняли, почему разработчики софта много зарабатывают и это не просто кнопки давить и формы двигать. Живешь так в пузыре, общаешься с другими разработчиками и думаешь, что это все не так и сложно. Сложно. Особенно уважают юристы, когда прочитав их "исходники" налету пару дыр в договоре находишь.
Если взять типичного водилу, то я как разработчик разложу его деятельность на запчасти, формализую оптимальные паттерны, докопаюсь, почему он не включает правильно поворотники и не придерживается траекторий. В целом тупая скучная работа оператора, хоть и ответственная. Водила же сломает мозг, если мы будем обсуждать устройство приложения.
Кроме программистов, полно специалистов, которые зарабатывают в разы и на порядок больше, будучи глубоко погруженными в предметную область. Как-то сравнивать процесс разработки с количеством высиженных часов низкоквалифицированными операторами — не совсем корректно. Я уже молчу, про хрен знает сколько лет образования и самообразования, постоянного стресса, когда твоя отрасль устаревает буквально на глазах за 2-3 года.
Разработчики — это дорогой и продвинутый обслуживающий персонал, который реализует идеи и потребности заказчиков. Заказчиков прямых или косвенных, в виде пользователей продукта. Элита — это люди, которые платят разработчикам деньги, приносят задачи и берут на себя риски.
По приколу когда-то написал "невнятные траектории, беспомощная рулежка, перестраивается без уважения". Проблема еще в том, что для комфорта пассажира надо специально учиться ездить плавно и не суетиться, да и машина должна располагать. На поло и солярисе достаточно сложно даже остановиться без рывков. На S-классе плавно ездить легко и приятно, поскольку специально подобраны режимы коробки и тормозов.
С интерфейсами интересная ситуация. В PHP интерфейс — это некая декларация с полным неймспейсом. Я не могу в неймспейсе потребителя интерфейса описать интерфейс локально, а подставить посторонний объект, который ничего не знает об этом объекте/интерфейсе. Интерфейсы должны быть описаны "глобально" и видимы всем, кто реализует и использует. Не уверен, давно не проверял, можно ли подсунуть объект под интерфейс, если он в цепочке наследования не заявляет implements. Кажется нет. Поправьте пожалуйста, если это не так.
В Go я могу локально объявить "методу нужен интерфейс publisher, который состоит из одного метода Publish()". Далее абсолютно любые объекты с методом Publish() могут быть переданы как аргумент и пролезут сквозь проверку типов. Автор объекта даже не знает, что реализовал интерфейс publisher, потому что для меня это требуемая зависимость, а для автора часть какого-то другого набора методов. В PHP для этого надо интерфейс сделать глобальным и заставить всех причастных сослаться на один и тот же неймспейс. Поэтому в PHP и слипаются во фреймворки наборы полезных объектов, из за необходимости поддержания единой иерархии зависимостей.
Предлагаю еще потестить VK Cloud.
Мы продаем или покупаем? (с)
Да, действительно, на мьютексах. Как-то не обращал внимания на ограниченность стандартной реализации. При отправке в канал лочится (см. с 200 строки). https://github.com/golang/go/blob/master/src/runtime/chan.go
У нас просто своя кастомная реализация каналов, близкая по идеалогии к "каналам на стеройдах", которая при записи не лочится и в целом дает выгоду на 24 ядрах. По сути весь треш атомиков инкапсулирован внутри. Атомики сильно затрудняют на мой взгляд понимание кода. Пример альтернативной реализации каналов: https://docs.google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/pub
Тем не менее, даже если в каналах (сейчас) мьютексы, мне кажется стоит писать на каналах и отдельно уделить внимание в бенчмарках этой реализации, потому что стандартные каналы могут и проапгрейдить, а мьютексы останутся как есть. Кроме того, запись в канал - отличная абстракция, которая упрощает понимание.
Недостает варианта и бенчмарков с использованием каналов. Мьютексы дико просаживают производительсность, когда много ядер. Он все ждут анлока и в это время курят. Атомики - не решение, потому что код превращается в лапшеобразного монстра.
Придумали же изначально идиоматический вариант, когда данные модифицирует только одна горутина и выгребает из канала инфу, а все конкурентные горутины в этот канал кидают данные и дальше выполняются без остановки, если канал буферизированный.
16 оперативки маловато будет. 2-3 вирт. машины запустил и все, приехали. HP не дает добивать память, залочивая биос, да и не факт, что чипсет поддерживает.
Переходите на следующий уровень в 2021 — создание собственных продуктов с высоким содержанием интеллектуальной собственности. Заказы заказами, но результаты должны как-то накапливаться не только в виде опыта.
Kerbal Space Program стоит пройти перед началом обучения?
Тот, у которого миллиард и машина с вертикальными дверьми (на видео) — наглядно объясняет идею "no revenue". Друга Цукербега, который искал хоть какую-то выручку, очень быстро и некрасиво оставили за бортом.
В калифорнийском стартап-казино прибыль получать не принято. Да и в России, если на рынок приходит компания, которая может 10 лет работать в убыток, все ребята "на дошираке" разоряются. Микроприбыль, которой недостаточно для роста — это скорее негативный сигнал, что тема мертвая. Чтобы найти живое направление, надо тратить деньги и пробовать.
Тут уж либо играть в раздувание оценки и доли рынка, прожигая инвестиции в убыток, либо спокойно делать нишевый бизнес, который крупняку не интересен, спокойно расти как идет и не искать вложений со стороны.
Вообще ощущение полной абсурдности статьи. В фильме про Цукерберга был друг-неадекват, любитель самоокупаемости, который все бегал по рекламодателям ради копеечной выручки, когда надо было забить на всю коммерцию, делать продукт, лишь бы совладать с экспоненциальным ростом.
И все это льется в один поток. Если у вас большой трафик на запись (например, собираете телеметрию), то возможна ситуация, когда мастер справляется, а слейвы отстают безнадежно и вылечить это конфигурируя репликацию невозможно. Для понимания границ применимости.
Зенитки немного не так работают. Используются осколочные боеприпасы с программируемым подрывом. Т.е. оно летит в заданную точку, потом взрывается и прошивает осколками сферу 100 метров в диаметре. Один выстрел — как минимум один дрон, как бы не прыгал. Если плотненько пойдут — больше улов.
В середине 20 века стреляли люди, подбирая дальность подрыва, а сейчас это делает автовычислитель по оптико-электронному наведению. Порядка 80 выстрелов в минуту генерируют осколочные разрывы на высоте до 4 км. Так что сверху вывалить не получится, а ковер из тысячи дронов, огибающих рельеф очень сложно организовать.
Это должна быть очень непростая формация, чтобы подобраться всего к одной точке пво. Сейчас пока революции и появления супер-оружия не случилось, штатные средства пво способны сдержать с запасом, но тенденция неприятная.
Вот эта штука способна валить пачками дроны, чисто оптическим наведением: https://russian.rt.com/russia/article/724001-derivaciya-pvo-modul Вычислитель позволяет даже снаряды снимать. Дроны были бы серьезным оружием, если бы удалось выйти на сверхбольшое количество согласованно двигающихся аппаратов, но это очень непросто по логистике, да и дорого.
За сверхскоростным оружием, которое управляется алгоритмами, безусловно будущее. Предполагаю, что в какой-то момент даже понять что происходит на поле боя будет невозможно, без отдельного аналитического алгоритма.
На войне играет роль баланс стоимости и эффективности. Против войска с калашами выглядит как супероружие без шансов, но где такие еще остались? Если решена задача напечатать тысячи дронов недорого, то теоретически можно вывалить несколько тонн этой мелочи с высоты, и не вступать в прямое столкновение. Конечно, если не на равных, а в режиме "превосходящие силы утюжат туземцев".
Если стоит задача защиты периметра от дронов, то одним из решений будет оптико-электронное наведение скорострельного пулемета, в автоматическом режиме. Современный крейсер, например, этих дронов и так не подпустит штатными средствами, потому что сбивает автоматически крылатые ракеты и прочие мелкие цели, вплоть до снарядов. Что-то аналогичное в сухопутном варианте вполне реально выставить.
Вот одновременно пару тысяч дронов из видео создали бы нагрузку, но где же их взять дешевых столько :) Кроме экономических аспектов очень интересная логистика вырисовывается и масса сопутствующих задач. Хотя бы просто одновременно в воздух поднять реально рой, а не десять штук. Как их запускать, волнами или одновременно? Если волнами, как они будут собираться и ждать друг друга, круги нарезать в определенной формации? Пока последние взлетят, у первых уже расход топлива будет, поэтому при увеличении роя дальность упадет. Если даже одновременно удастся выпустить, пусковую площадку или сотни машин просто так не спрячешь. А если скрытно разместить, то будет немобильно. Нужно какое-то более серьезное средство доставки. Не все так просто с роями.
Китайцы поднимают ставки потихоньку. Сейчас если кто отстанет в автоматическом скоростном оружии, которое управляется программно, может оказаться беззащитным. Надеюсь у нас не пренебрегают этой темой.
Государству поиск примерно так же как дороги, мосты, стадионы, библиотеки. Инфраструктурный проект, чтобы жизнь кипела. Простому человеку хорошая дорога очень даже профит.
У поисковика могут быть разные акценты. Если не стоит задача продать как можно больше рекламы, то могли бы наверх подняться информационные/навигационные результаты, а не коммерция. Кроме того, можно поставить задачу поиска по специфическим коллекциям, архивам, законодательству. Индексировать только проверенные источники. Некий заведомо безопасный поиск без криминала, с проверенными источниками и разными вертикалями по специфическим данным. Если серьезно подойти — большая интересная задача для большого коллектива. Почему бы и не убыточный? Лишь бы качественный.
Были ли консультации с крупными компаниями обладающими реальным опытом в работе с большими объемами данных, например Яндексом? Не рассматривали вариант отдать на реализацию такой ответственный и социально-значимый сервис? Это вопрос не про деньги.
Чем в вашем представлении отличается приложение, которое решает одну бизнес-задачу от микросервиса?
Был у меня интересный опыт обсуждения с очень неглупым сотрудником диспетчерской службы некоего эскиза приложения. Обычные экраны, состояния, вот здесь жмем кнопочку, добавляется запись, потом обновляется вот здесь. Все предельно примитивно разрисовано на листах, многие моменты упрощены. Работа проектировщика на ранней стадии. С программистами это можно обсуждать несколько часов подряд и они потом пойдут писать код, не особенно устав.
Проблема в том, что обсуждать проект приложения мы смогли примерно 10 минут, потом у моего собеседника перегрелся мозг. Ну ладно, думаю, поговорю с ее коллегами. Примерно тот же результат. При том, что эти люди работают по 8-10 часов в очень многозадачном режиме, отвлекаются посмотреть карту, зайти в одноклассники, проверить ферму, поговорить с ребенком про уроки. А вот обсуждать пространство состояний не могут.
В момент "перегрева" я по приколу сказал: представляешь, вот так целый день приходится думать. Кажется в этот момент они поняли, почему разработчики софта много зарабатывают и это не просто кнопки давить и формы двигать. Живешь так в пузыре, общаешься с другими разработчиками и думаешь, что это все не так и сложно. Сложно. Особенно уважают юристы, когда прочитав их "исходники" налету пару дыр в договоре находишь.
Если взять типичного водилу, то я как разработчик разложу его деятельность на запчасти, формализую оптимальные паттерны, докопаюсь, почему он не включает правильно поворотники и не придерживается траекторий. В целом тупая скучная работа оператора, хоть и ответственная. Водила же сломает мозг, если мы будем обсуждать устройство приложения.
Кроме программистов, полно специалистов, которые зарабатывают в разы и на порядок больше, будучи глубоко погруженными в предметную область. Как-то сравнивать процесс разработки с количеством высиженных часов низкоквалифицированными операторами — не совсем корректно. Я уже молчу, про хрен знает сколько лет образования и самообразования, постоянного стресса, когда твоя отрасль устаревает буквально на глазах за 2-3 года.
Разработчики — это дорогой и продвинутый обслуживающий персонал, который реализует идеи и потребности заказчиков. Заказчиков прямых или косвенных, в виде пользователей продукта. Элита — это люди, которые платят разработчикам деньги, приносят задачи и берут на себя риски.
m1tt
По приколу когда-то написал "невнятные траектории, беспомощная рулежка, перестраивается без уважения". Проблема еще в том, что для комфорта пассажира надо специально учиться ездить плавно и не суетиться, да и машина должна располагать. На поло и солярисе достаточно сложно даже остановиться без рывков. На S-классе плавно ездить легко и приятно, поскольку специально подобраны режимы коробки и тормозов.
С интерфейсами интересная ситуация. В PHP интерфейс — это некая декларация с полным неймспейсом. Я не могу в неймспейсе потребителя интерфейса описать интерфейс локально, а подставить посторонний объект, который ничего не знает об этом объекте/интерфейсе. Интерфейсы должны быть описаны "глобально" и видимы всем, кто реализует и использует. Не уверен, давно не проверял, можно ли подсунуть объект под интерфейс, если он в цепочке наследования не заявляет implements. Кажется нет. Поправьте пожалуйста, если это не так.
В Go я могу локально объявить "методу нужен интерфейс publisher, который состоит из одного метода Publish()". Далее абсолютно любые объекты с методом Publish() могут быть переданы как аргумент и пролезут сквозь проверку типов. Автор объекта даже не знает, что реализовал интерфейс publisher, потому что для меня это требуемая зависимость, а для автора часть какого-то другого набора методов. В PHP для этого надо интерфейс сделать глобальным и заставить всех причастных сослаться на один и тот же неймспейс. Поэтому в PHP и слипаются во фреймворки наборы полезных объектов, из за необходимости поддержания единой иерархии зависимостей.