Людям дали технологии, которые позволяют им проводить собственные подобные эксперименты, и даже такая избыточная вещь может впоследствии стать обычной повседневной функцией. Это как раз тот случай, когда технологию дали поюзать кому угодно, поэтому 99% идей использования этого всего ведет только в тупик, и на это тратятся огромные вычислительные ресурсы, за что уже сейчас заплатит абсолютно каждый, кто собирается апгрейднуть свой пк, так что не стоит переживать за то, что сейчас кто-то из-за подобных вещей недополучит деньги
Без лишней драматургии тут, конечно, не обошлось... JSON победил потому что он читабельный, и все эти побочки в виде тяжеловесности - симптом плохой апишки, на помощь которой и приходят все эти кеширования и синхронизации
Мне кажется, что времена дуо уже всё-таки прошли, нужно развивать сервис, но они заняты тем, что бы бесконечно пытаться выклянчить деньги с пользователей... Это печально, хотя это работает точно так же, как и любой другой похожий бизнес
Совершенно верное замечание, нужна соответствующая квалификация, а не надсмотренность того, как это должно выглядеть. В компромиссы в рамках архитектуры нейронки сами не могут, поэтому нужно эти вопросы контролировать, и постоянно перенаправлять. Без хотя бы этого, хорошего продукта, с приемлемой производительностью - не выйдет(
Не понимаю причину тряски, если задачи выполнялись своевременно, а тесты были зеленые, и всё корректно работало. Все проблемы, которые описаны здесь, вполне могли бы быть и без участия ИИ в проекте
Довольно крутое пояснение. Так же хотел сказать про распределение задач на разные потоки и ядра. Да, кеш третьего уровня общий, но так же есть отдельный кеш на каждое ядро, первого и второго уровня. И таким образом нагрузку можно уменьшить путем распределения инструкций на разные потоки и ядра, особенно если данные не конфликтуют по кеш линиям.Так же думаю, что все зависит от компилятора, который указывает на дыры в оптимизации или сам оптимизирует код, например может переупорядочивать инструкции, векторизовать циклы и эффективнее работать с памятью. Но при этом, если сами данные организованы плохо, как в примере с ООП и разрозненными объектами, компилятор уже мало что спасет, потому что упрется в задержки памяти и cache miss.Как совет, думаю, что важно учитывать не только многопоточность, но и локальность данных, выравнивание структур, размер кеш линий и доступа к памяти. Тогда и проц, и prefetcher смогут работать максимально эффективно. В этом плане data oriented действительно может дать сильный прирост производительности, особенно в задачах с большими массивами однотипных данных
Людям дали технологии, которые позволяют им проводить собственные подобные эксперименты, и даже такая избыточная вещь может впоследствии стать обычной повседневной функцией. Это как раз тот случай, когда технологию дали поюзать кому угодно, поэтому 99% идей использования этого всего ведет только в тупик, и на это тратятся огромные вычислительные ресурсы, за что уже сейчас заплатит абсолютно каждый, кто собирается апгрейднуть свой пк, так что не стоит переживать за то, что сейчас кто-то из-за подобных вещей недополучит деньги
Без лишней драматургии тут, конечно, не обошлось... JSON победил потому что он читабельный, и все эти побочки в виде тяжеловесности - симптом плохой апишки, на помощь которой и приходят все эти кеширования и синхронизации
Так-то оно хорошо, но все мы знаем какие версии этого редактора кода стоят у подавляющего большинства разрабов
Мне кажется, что времена дуо уже всё-таки прошли, нужно развивать сервис, но они заняты тем, что бы бесконечно пытаться выклянчить деньги с пользователей... Это печально, хотя это работает точно так же, как и любой другой похожий бизнес
Совершенно верное замечание, нужна соответствующая квалификация, а не надсмотренность того, как это должно выглядеть. В компромиссы в рамках архитектуры нейронки сами не могут, поэтому нужно эти вопросы контролировать, и постоянно перенаправлять. Без хотя бы этого, хорошего продукта, с приемлемой производительностью - не выйдет(
Не понимаю причину тряски, если задачи выполнялись своевременно, а тесты были зеленые, и всё корректно работало. Все проблемы, которые описаны здесь, вполне могли бы быть и без участия ИИ в проекте
Ушла легенда, получается. Он служил человечеству тогда, когда интернет был действительно безграничным. Этот кабель видел многое. Пропускал через себя.
Довольно крутое пояснение. Так же хотел сказать про распределение задач на разные потоки и ядра. Да, кеш третьего уровня общий, но так же есть отдельный кеш на каждое ядро, первого и второго уровня. И таким образом нагрузку можно уменьшить путем распределения инструкций на разные потоки и ядра, особенно если данные не конфликтуют по кеш линиям.Так же думаю, что все зависит от компилятора, который указывает на дыры в оптимизации или сам оптимизирует код, например может переупорядочивать инструкции, векторизовать циклы и эффективнее работать с памятью. Но при этом, если сами данные организованы плохо, как в примере с ООП и разрозненными объектами, компилятор уже мало что спасет, потому что упрется в задержки памяти и cache miss.Как совет, думаю, что важно учитывать не только многопоточность, но и локальность данных, выравнивание структур, размер кеш линий и доступа к памяти. Тогда и проц, и prefetcher смогут работать максимально эффективно. В этом плане data oriented действительно может дать сильный прирост производительности, особенно в задачах с большими массивами однотипных данных