All streams
Search
Write a publication
Pull to refresh
-16
-0.2
Send message

Вот это да (Сарказм).

Спасибо, что прикручиваете NLU к SMT.

Очередной Руководитель Департамента решил пошутить поправить используя свои превосходные знания.

Однако, программирование - поиск в пространстве функций.

А трансформер(GPT/Bert/etc) - отображение одного множества на другом (c CoT или без. Кот кстати даже не выведен математически :) ).

Это происходит от мнения, что Сбер или Яндекс действительно занимаются R&D, а не перепечаткой публикаций ученых.

R&D, только ЗП как у индусов. И уровень...

Да нет, я написал именно то, что имел ввиду.

Советую почитать еще раз
(про seq2seq, T9, LSTM, Tansformer и прочее)
https://ebetica.github.io/pytorch-Deep-Learning/en/week06/06-3

И станет ясно, что seq2seq модели в кодинг не могут по определению :)

Потому что это (seq2seq, Transformer, etc) - отображение одного множества на другом (и используются seq2seq для перевода).

А от всего остального появляется декартово произведение (Напиши Зеленый модуль в стиле Барокко на C++ - цвета X стиль X язык). И бесполезные модели в триллионы параметров.

Программирование - разработка Алгоритма.

Это делают SMT solver-ы, A* и т.д.

P.S. (ответы на все остальные вопросы)

Я обосновал Multistep (thinking) за год-два до OpenAI.

(В отличие от "Экспертов" c habr и сбербанк, которые не смогли в предметную область и тем более в магию множеств и декартова произведения)

https://medium.com/@PushkarevValeriyAndreevich2/how-to-write-on-verilog-with-chatgpt-or-do-anything-else-796a63c17f9b

К сожалению, сбер не опережает, а отстает даже от OpenAI :).

Когда станете прибыльными и сможете платить хотя-бы 8-16к$ на удаленке (типичная ЗП PhD R&D) - пиши, не стесняйся.

Про нейросети и статистические модели думаю говорить не будем (интересно, почему?)

https://9gag.com/gag/aZZVK3n

И, да, Сбербанк не разбирается в трендах ИИ, Яндекс тоже (денег нет), а вот 9 хомяков с Habr - разбираются xD

https://coub.com/view/39aatk

Бред какой пишите.

T-9 (transformer) не кодит?

Кодят поди DreamCoder-ы или SMT Solver-ы?

Есть вообще мнение, что это LowCost Cosplay на CAS (там уже биомаркеры-пептиды и окно в 10-20 лет)

Ну или даже на печально известное Delphi-2M

(да плевать что нейросети очень плохи в Explanation)

https://www.nature.com/articles/s41586-025-09529-3

Если блок работает, его можно включить в более крупную конструкцию, что резко ускоряет поиск новых результатов.

Очень, учитывая что это почти DreamCoder (Darpa).

Т.е. просто спонсируем грант MiT, через 10 лет достаем (у нас тут в Alphabet почти OpenSource)

А вы сами читали? Транзакционность в Orleans реализована за счет сохранения состояния в транзакционном хранилище, то есть в БД.

Продолжайте читать. Если вам советуют почитать (и даже ссылки кидают) - надо говорить Спасибо за ценную информацию.

Не надо делать какие-то невнятные заявления о транзакциях БД и прочем, в надежде что Вам сейчас все разъяснят.

Автор вообще слабо представляет Highload, ругает стандартные подходы (вроде Orleans) и лепит системы в 10-1000 раз менее производительные, чем можно :)

Ну а гит - вообще прелестно. Хоть Concurrent коллекцию возьмите :)

Orleans так-то ACID.

Ну и весь код с Orleans - Положить запросы в шину,

При обработке:

1) дергать Orleans (bookTemporary(int count, int itemId), получаем guid)

2) отсылаем в шину операции на бронирование заказов (там BatchInsert)

3) отсылаем в шину операцию bookFinalize(подтверждаем бронирование)

Все, 100+ RPS.

За счет outboxConsistency точно не будет повисших бронирований.

Даже если шина вдруг откажет (ага), остатки будут возвращены на склад

  • Single-threaded execution within a grain: 

    The Orleans runtime guarantees that a grain instance will never execute on more than one thread at a time. This means that within the context of a single grain, you do not need to worry about race conditions or shared state being accessed concurrently by multiple threads.

Вы через WebApi дергаете BookItems

В Orleans.

Там (В методе BookItems у объекта ShopItem) в транзакции

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

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

@ai_say

но в изначальных требованиях к решению были Strong consistency и запрет на хранение бизнес данных в памяти приложения, потому дальше мыслей не ушло.

https://learn.microsoft.com/ru-ru/dotnet/orleans/grains/transactions

Как не решает?

Остается только добавить возвращение результата (тоже через шину(!))

Почти akka.net

Есть явные причины так не делать под высокой нагрузкой.

Orleans offers high "actor speed" through a framework that keeps grain (actor) state in memory, providing low-latency access for real-time applications and enabling massive horizontal scalability by distributing grains across many silos (servers) and managing their lifecycles automatically. This in-memory state management is significantly faster than database roundtrips, allowing the system to achieve high throughput and sub-millisecond responses for concurrent tasks

У вас сколько типов товаров на распродаже? Меньше миллиарда (Чтобы на одном сервере поместились все акторы)?

Отлично.

10 кRPS.

Могу даже бесплатно подсказать:

Актор у вас

— item_id — уникальный идентификатор товара;

— warehouse_id — склад, где товар лежит;

— stock — общее количество (сколько товара на складе прям сейчас);

— reserved — сколько уже зарезервировано.

Ну а записи о резервировании опять в шину (персистентно, горизонтально масштабируемо), а оттуда - в БД (батчами).

Поздравляю, вы построили систему бронирования для миллиарда типов товаров, которая выдерживает

10 КRPS.

Саммари:

Автор вообще слабо представляет Highload, ругает стандартные подходы (вроде Orleans) и лепит системы в 10-1000 раз менее производительные, чем можно :)

Ну а гит - вообще прелестно. Хоть Concurrent коллекцию возьмите :)

А вообще забавно.

10 RPS

Если просто взять, записать все в шину (шины могут быть развернуты на 100 инстансах, и писать гигабиты запросов) - можно тоже получить 10 кRPS.

Ну и как-то сложно.

Вот генерация веб-апи, которое пишет все в шину и разбирает по батчам (для IOT).

https://habr.com/ru/articles/906778

Orleans.

Богатые доменные модели в оперативке (и дампятся в хранилище автоматом).

Хоть 1M RPS (упретесь в CPU\сеть) :)

Даже с транзакциями(!).

Но есть минусы.

Не вызывает ни в жирном монолите на несколько сотен проектов, ни в нескольких сотнях микросервисов, и это мы ещё не очень большая компания. 

Ну, расскажите нам, что у вас за git

Не вызывает ни в жирном монолите на несколько сотен проектов, ни в нескольких сотнях микросервисов, и это мы ещё не очень большая компания. 

Да вы что, добавление 2-х разных строк в одно и то же место в файле - 100% конфликт при мерже.

Вам написали, что вы - идиот?

Ссылки привели?

Что Вас не устраивает? )

Вы откровенно херню городите, Вам даже ссылки приводят.

Вам уже написали:

1) вы читали меньше меня

2) у вас нет ни интерпретации ни оптимизации персептрона (А как публикация называется? А какие понятные причины? :) )

(и интерпретировано все, и оптимизировано, и это уже сделано с позиции LP)

3) почему те, кто понимает нейросети и перцептроны лучше, чем средние дурачки из Google (или CAS), не пишут вам статьи об этом. Да еще и бесплатно )

Удивительно, но у меня есть куда более перспективные занятия (а хабр с точки зрения науки - трэш :) ).

Вы пропустили 3-4 публикации:

1) Перцептрон, знаки в S/A слое и гиперкубы логических функций

2) Перцептрон, нейросети и ошибки из-за ненормированного расстояния до гиперплоскостей

3) Перцептрон как линейное ограничение

При этом не понимаете, что писать в <TargetFramework>Поменяв net7.0 на netcoreapp2.0, вы сделали хуже, потому что если у .NET 7 поддержка закончилась в мае 2024, у .NET Core 2.0 - в октябре 2018.

И? Моя задача сделать либу, которая поддерживается наибольшим числом проектов. Core2.0 - самое то.

Да, нужно разбивать на несколько пакетов. Unity отдельно, Microsoft DI отдельно. Нет, разбираться в 3+ пакетах никому не придётся. Кому нужен ‎RegistrationByAttributes для Microsoft DI, те по-прежнему поставят один пакет.

Зачем? Пакеты по 100 строк кода? При этом без тяжелых зависимостей (Только Abstractions)?

Во-вторых, лично я с возрастом начал ценить простоту. Я выберу 200 строк скучного, повторяющегося, но понятного как пять копеек кода, нежели магический чёрный ящик на 20 строк.

400-800-1000 строк скучного, повторяющегося кода, который всегда вызывает конфликты при merge :)

PerThread != Scoped, это разные вещи

Тут согласен.

Моё мнение - нет, потому что есть такой принцип наименьшего удивления

Ну есть Scrutor на худой конец, если очень хочется автомагических регистраций.

Это который превращает boilerplate регистраций в еще менее поддерживаемый? И требует перерегистраций? Где истина-то?

1
23 ...

Information

Rating
Does not participate
Registered
Activity

Specialization

Software Developer, Backend Developer
Senior
From 220,000 ₽
SQL
Python
C#
ASP.NET MVC
Windows Forms
.NET
WPF
WCF
RabbitMQ