-
- Картинки интересные, а текст - стоны юзверя. Танчики не погонять
задешево. Там были и более профессиональные статьи. - max(19.06.2023 11:05)
- Например. Итоговая таблица - это конец Эльбруса. Ускорение кода в
зависимости от глубины оптимизации программиста. IRL никто не будет
сидеть над каждым куском кода столько времени. Evgeny_CD(1 знак., 19.06.2023 11:29, ссылка)
- Ну ты и загнул. Не все же говнокодеры. - max(19.06.2023 12:39)
- Даладно, почему под intel сидят? например в зависимости от наличия
инструкций AVX, TSX, итп пишут разные ветки кода, под размер кэша
постраивают порции блочной обработки данных, итп. Тупик новых идей
в области программирования у многих (повторяют старое), и выхода из
него пока не видно. - aнтинoвocти2(19.06.2023 11:37)
- При этом "просто код" на х86 исполненияется очень эффективно. Есть куча библиотек, начиная от IPP, которые оптимизируют распространенные операции. Можно по частям оптимизировать. - Evgeny_CD(19.06.2023 11:59)
- Apple в своих M* сделала гигантский буфер преддекодирования и
анализа исполнения команд, что дало большой прирост IPC. Идея не
нова, но они первыми это сделали. - Evgeny_CD(19.06.2023 11:56)
- Кеш нулевого уровня был еще в пентиум4 - =AlexD=(19.06.2023 12:36)
- 4й Пень со своими 30+ стадиями конвейера - это песня! Хорошо, что
этот уродец упокоился. - Evgeny_CD(19.06.2023 12:49)
- Тем не менее у него в кеш0 сидели цепочки МОПов с развязанными
зависимостями. Он мог исполнять немаленькие циклы вообще не
обращаясь к декодеру. - =AlexD=(19.06.2023 13:15)
- Спасибо! Видимо, я уже запамятовал. - Evgeny_CD(19.06.2023 13:38)
- Тем не менее у него в кеш0 сидели цепочки МОПов с развязанными
зависимостями. Он мог исполнять немаленькие циклы вообще не
обращаясь к декодеру. - =AlexD=(19.06.2023 13:15)
- 4й Пень со своими 30+ стадиями конвейера - это песня! Хорошо, что
этот уродец упокоился. - Evgeny_CD(19.06.2023 12:49)
- Кеш нулевого уровня был еще в пентиум4 - =AlexD=(19.06.2023 12:36)
- Например. Итоговая таблица - это конец Эльбруса. Ускорение кода в
зависимости от глубины оптимизации программиста. IRL никто не будет
сидеть над каждым куском кода столько времени. Evgeny_CD(1 знак., 19.06.2023 11:29, ссылка)
- Проблема Эльбруса не в архитектуре, а в закрытости. Они так усилено
анально огораживали своё ноу-хао, вместо следования принципу
опенсорце/опенхардваре, что просто безнадёжно отстали. - =AlexD=(19.06.2023 10:16)
- Как и всякий VLIW, Эльбрус является тупиком. Это не страшно само по
себе, если вовремя осознать и принять меры. Но вместо этого МЦСТ
накрылся одеялом и пилит миллиарды на этом тупике. - Evgeny_CD(19.06.2023 11:12)
- Процессор сделан, так значит надо его использовать. По-хозяйски
отнестись к делу. Оставить небольшую группу для сопровождения и
баги отлавливать. Копирование/производство относительно дёшего,
когда уже есть готовый образец и даже серия рабочая. - Costic(19.06.2023 15:46)
- Почти верно. Но TSMC по приказу фашингтона решила, что нет у нас
Эльбруса. И все. Таки и вправду нет :( - Evgeny_CD(19.06.2023 15:50)
- Байкал делался на том же TSMC. - _volkanaft_(20.06.2023 10:32)
- Почти верно. Но TSMC по приказу фашингтона решила, что нет у нас
Эльбруса. И все. Таки и вправду нет :( - Evgeny_CD(19.06.2023 15:50)
- В чём этот тупик состоит? почему динамический "предсказатель"
тупиком не является, а статический (на этапе компиляции) является?!
... на определённом круге задач это, само по себе, не плюс и не
минус. А кристалл при этом делает "легче"! - _volkanaft_(19.06.2023 12:07)
- Многозадачка плюс обвязка чипа (всякие там кэши, канальность
памяти, прерывания какие-то). Это невозможно обсчитать при
компиляции, но возможно статистически учесть в рантайме. - LightElf(19.06.2023 12:25)
- Ну так не надо пихать VLIW направо и налево! В машины общего
назначения. А на большом классе задач VLIW себя хорошо показывает.
... В частности шлю вам эти горестные строки с помощью процессора
VLIW! ( Qualcomm Hexagon ). :-) - _volkanaft_(19.06.2023 13:01)
- Нет. Пишешь ты на ARM под Android, а кто там сопроцессор - это
вторично. - Evgeny_CD(19.06.2023 13:17)
- Так я и написал : "шлю".:-) _volkanaft_(62 знак., 19.06.2023 13:53)
- Нет. Пишешь ты на ARM под Android, а кто там сопроцессор - это
вторично. - Evgeny_CD(19.06.2023 13:17)
- Ну так не надо пихать VLIW направо и налево! В машины общего
назначения. А на большом классе задач VLIW себя хорошо показывает.
... В частности шлю вам эти горестные строки с помощью процессора
VLIW! ( Qualcomm Hexagon ). :-) - _volkanaft_(19.06.2023 13:01)
- Многозадачка плюс обвязка чипа (всякие там кэши, канальность
памяти, прерывания какие-то). Это невозможно обсчитать при
компиляции, но возможно статистически учесть в рантайме. - LightElf(19.06.2023 12:25)
- сама по себе парадигма VLIW не тупик, просто такая архитектура
заточена под определённые задачи. На специализированных алгроитмац
ЦОС VLIW "сильно спереди" :) Где-то даже впубликовали тесты, ну и
говорили что на так :) В ощем-то всякие AVX в интелах не спешать
искоренять. Нужно просто делать это расширением, а саму
архитектуру, кмк, брать а-ля RISC с высокими тактовыми частотами
ихорошей оптимизацией конвейеров. - Adept(19.06.2023 11:42)
- VLIW не может стать "просто расширением" RISC из за принципиально
иной требуемой архитектуры шин. - my504(19.06.2023 11:58 - 12:10)
- Cadense Xtensa - в базе - простенький RISC, а сделанный из него
HiFi4 DSP - VLIW. Каг жыдь? - LightElf(19.06.2023 12:23)
- Сделать "из него" можно что угодно. VLIW уже не RISC. Может я чего
то не понимаю, но идеология RISC противоречит длинным инструкциям. - my504(19.06.2023 12:29)
- Современный RISC != RISC из учебника. Aarch64: 2500+ команд. Нихера себе reduced command set. - Evgeny_CD(19.06.2023 15:48)
- x86 тоже совсем не RISC снаружи. но внутри, грят, всё как раз очень на RISC позхоже. Ничто не мешает сделать на кристалле либо второй CPU/FPU специально для VLIW или сделать частично реконфигурируемую архитектуру под VLIW команды (навряд ли можно сделать динамически меняющуюся эффективную архитертуру, на гигагерцовых частотах уже за каждый блок битва будет, и как известно универсальные инструменты завсегда хуже специализированных) - Adept(19.06.2023 12:40)
- Почему? Простая RISC-инструкция может быть префиксом "дальше 100500
байт VLIW команды". А может не быть. - LightElf(19.06.2023 12:32)
- Дело ведь не только в длине команды. Нужен многоканальный доступ к
ОЗУ. Под VLIW нужно писать на АСМе. Компилятор ничего не знает про
многоэтажную конструкцию длинных команд. Поэтому от RISC там ничего
не остается. Во VLIW-процессорах ведь не все команды длинные. - my504(19.06.2023 12:42)
- Почему это "компилятор ничего не знает"? Надо ему разъяснить
политику партии, йащетаю! А без шуток - есть пример
Tensilica/Cadense. Где к RISC ядру прикручивается черта лысого и
VLIW впридачу. И компилятор под это безобразие - тоже есть. - LightElf(19.06.2023 12:45)
- Всегда было интересно как компилятор отличит алгоритм "бабочки" от
простого умножения и суммы. В каком месте Си есть инструменты
предвыборки. В смысле как указать компилятору о чем вообще идет
речь. До сих пор я видел только библиотеки написанные на АСМе или
на встроенных функциях, что одно и тоже. - my504(19.06.2023 12:50)
- __builtin_prefetch() это нужно? aнтинoвocти2(1 знак., 19.06.2023 13:01, ссылка)
- Это как с HAL. Вместо того, чтобы писать на АСМе, нужно будет
разбираться в куче встроенных функций с их опциями, аргументами и
прочей хренью. То есть менять шило на мыло. Нет уж, свят, свят.
свят... Изыди, сОтона... )))) - my504(19.06.2023 13:06)
- А на АСМе не нужо знать про работу КЭШей, памяти, механизмов
синхронизации между ядрами? Вопрос: будет ли отличаться
"производительность" (в циклах) двух и более потоков, выполняющихся
на разных ядрах CPU, пишущих (пусть мусор) в одну и туже ячейку
пямяти, или в разные, находящиеся в разных КЭШ линиях? - aнтинoвocти3(19.06.2023 13:17, )
- Какое отношение это имеет к VLIW? - my504(19.06.2023 13:56)
- Думаю, будут. В первом случае будет коллизия, на ее разруливание
уйдут такты. - Evgeny_CD(19.06.2023 13:26)
- Вот и получается, у каждой архитектуры/платформы есть ньюансы, и если хочется выжать максимум, их надо учитывать aнтинoвocти3(1 знак., 19.06.2023 13:40, , ссылка)
- А на АСМе не нужо знать про работу КЭШей, памяти, механизмов
синхронизации между ядрами? Вопрос: будет ли отличаться
"производительность" (в циклах) двух и более потоков, выполняющихся
на разных ядрах CPU, пишущих (пусть мусор) в одну и туже ячейку
пямяти, или в разные, находящиеся в разных КЭШ линиях? - aнтинoвocти3(19.06.2023 13:17, )
- Это как с HAL. Вместо того, чтобы писать на АСМе, нужно будет
разбираться в куче встроенных функций с их опциями, аргументами и
прочей хренью. То есть менять шило на мыло. Нет уж, свят, свят.
свят... Изыди, сОтона... )))) - my504(19.06.2023 13:06)
- __builtin_prefetch() это нужно? aнтинoвocти2(1 знак., 19.06.2023 13:01, ссылка)
- Всегда было интересно как компилятор отличит алгоритм "бабочки" от
простого умножения и суммы. В каком месте Си есть инструменты
предвыборки. В смысле как указать компилятору о чем вообще идет
речь. До сих пор я видел только библиотеки написанные на АСМе или
на встроенных функциях, что одно и тоже. - my504(19.06.2023 12:50)
- Почему это "компилятор ничего не знает"? Надо ему разъяснить
политику партии, йащетаю! А без шуток - есть пример
Tensilica/Cadense. Где к RISC ядру прикручивается черта лысого и
VLIW впридачу. И компилятор под это безобразие - тоже есть. - LightElf(19.06.2023 12:45)
- Дело ведь не только в длине команды. Нужен многоканальный доступ к
ОЗУ. Под VLIW нужно писать на АСМе. Компилятор ничего не знает про
многоэтажную конструкцию длинных команд. Поэтому от RISC там ничего
не остается. Во VLIW-процессорах ведь не все команды длинные. - my504(19.06.2023 12:42)
- Сделать "из него" можно что угодно. VLIW уже не RISC. Может я чего
то не понимаю, но идеология RISC противоречит длинным инструкциям. - my504(19.06.2023 12:29)
- Были более здравые идеи. Часть ядер RISC, часть VLIW. Но победила
религия Эльбруса. - Evgeny_CD(19.06.2023 12:02)
- Насколько я знаю, НТЦ "Модуль" именно так и делает. Отдельно ARM
ядра, отдельно Neuro. Ситуация сходная. - my504(19.06.2023 12:09)
- NeuroMatrix - это отдельная история. Крутая штука, но есть ли
компилятор? Evgeny_CD(1 знак., 19.06.2023 12:57, ссылка)
- Полагаю, что как и в случае с DSP VLIW это будет НЕ Си. Главное -
создать эффективные интерфейсы подключения к традиционным
программам, я так понимаю. Просто из-за маргинальности таких
компиляторов они будут стоить невменяемых денег. - my504(19.06.2023 13:03)
- Мы получили шикарную ПОС. VLIW эффективен для ограниченного круга
задач. Компилятор для него либо кривой и косой, либо стоит
неадекватных денег, что приводит к схлопыванию даже его родных ниш. - Evgeny_CD(19.06.2023 13:15)
- Есть выход для ограниченного круга задач. Писать критические
участки кода на АСМе. Выигрыш столь велик, что никакой RISC за ним
не угонится. Кратно выше скорость. - my504(19.06.2023 13:58)
- И мы получаем RISC + SIMD, эта связка и побеждает в нашем мире IRL. - Evgeny_CD(19.06.2023 14:14)
- VLIW - это Xtensa Hi-Fi, Qualcomm Hexagon и TI C66x/C7000. Все живы
и здравствуют. Но никто не пытается запускать прикладное/серверное
ПО. Они используются только как ускорители вычислений. - lloyd(19.06.2023 14:12)
- Тут проблема курицы и яйца. Нет высокопроизводительных VLIW процов,
потому никто под них не точит прикладной софт. А в отсутствии
VLIW-оптимизированного софта никто не хочет делать VLIW-процы
высокой производительности. Т.е. Эльбрусу бы взять какой SQL-сервер
и не просто портировать, а заточить под свой камень до блеска. Хоть
на асме. Шоб он всех рвал как тузик грелку. И собрать сие в
монобинарь с кусками линуксячего ядра (такое существует - не помню
как проект называется). И LightElf(47 знак., 19.06.2023 16:00)
- Бочка дерьма в ложку меда. Хранимые процедуры. На пытоне или жабаскрыпте. И писец, приплыли. Нужна не просто БД, а JS JIT под Эльбрус, и оптимизированный питонячий стек. Наша шарашка начинает напоминать небольшой город типа Долгопрудного. - Evgeny_CD(19.06.2023 16:16)
- Шарашки. Шарашки нужны. Без них не получится. Толковые спецы по БД стоят взрослых денег, и их почти нет на рынке. Все устроены. А так план прекрасен! - Evgeny_CD(19.06.2023 16:12)
- +1. TI OMAP - классика архитектуры ARM + DSP как ускоритель. - Evgeny_CD(19.06.2023 15:56)
- Вооот! И я о том. Такие процессоры сильно дешевле FPGA реализующего тот же функционал. - my504(19.06.2023 14:20)
- Тут проблема курицы и яйца. Нет высокопроизводительных VLIW процов,
потому никто под них не точит прикладной софт. А в отсутствии
VLIW-оптимизированного софта никто не хочет делать VLIW-процы
высокой производительности. Т.е. Эльбрусу бы взять какой SQL-сервер
и не просто портировать, а заточить под свой камень до блеска. Хоть
на асме. Шоб он всех рвал как тузик грелку. И собрать сие в
монобинарь с кусками линуксячего ядра (такое существует - не помню
как проект называется). И LightElf(47 знак., 19.06.2023 16:00)
- Есть выход для ограниченного круга задач. Писать критические
участки кода на АСМе. Выигрыш столь велик, что никакой RISC за ним
не угонится. Кратно выше скорость. - my504(19.06.2023 13:58)
- Мы получили шикарную ПОС. VLIW эффективен для ограниченного круга
задач. Компилятор для него либо кривой и косой, либо стоит
неадекватных денег, что приводит к схлопыванию даже его родных ниш. - Evgeny_CD(19.06.2023 13:15)
- Полагаю, что как и в случае с DSP VLIW это будет НЕ Си. Главное -
создать эффективные интерфейсы подключения к традиционным
программам, я так понимаю. Просто из-за маргинальности таких
компиляторов они будут стоить невменяемых денег. - my504(19.06.2023 13:03)
- NeuroMatrix - это отдельная история. Крутая штука, но есть ли
компилятор? Evgeny_CD(1 знак., 19.06.2023 12:57, ссылка)
- Насколько я знаю, НТЦ "Модуль" именно так и делает. Отдельно ARM
ядра, отдельно Neuro. Ситуация сходная. - my504(19.06.2023 12:09)
- Cadense Xtensa - в базе - простенький RISC, а сделанный из него
HiFi4 DSP - VLIW. Каг жыдь? - LightElf(19.06.2023 12:23)
- VLIW не может стать "просто расширением" RISC из за принципиально
иной требуемой архитектуры шин. - my504(19.06.2023 11:58 - 12:10)
- Еще раз. Байкал-С против Эльбруса 16С. Одинаковый техпроцесс
(16нм), почти одинаковая площадь кристалла. На Linpack Байкал
быстрее в 2.5 раза. Т.е. даже в сфере числомолотилок он качественно
сливает современным процессорам. - Evgeny_CD(19.06.2023 11:15)
- Помнится, был такой процессор Cyrix MII, тоже показывал много
"попугаев". ;-) - Costic(19.06.2023 15:51)
- Я уже забыл историю. Там было какое-то наипалово... - Evgeny_CD(19.06.2023 15:58)
- А МЦСТ до сих пор компилятор на LLVM не перевела? Все так же с LCC
страдает? - LightElf(19.06.2023 12:00)
- У МЦСТ очень мало людей сейчас. Ядро высосало всех толковых. Все, кто остался - кадровый отстой :( - Evgeny_CD(19.06.2023 15:52)
- А вот тут пышуть, что не все так однозначно. Врут поди. max(1 знак., 19.06.2023 11:21, ссылка)
- Читаем каменты. Они подобрали задохлика Intel и методику тестирования. Мухляж. - Evgeny_CD(19.06.2023 11:31)
- Помнится, был такой процессор Cyrix MII, тоже показывал много
"попугаев". ;-) - Costic(19.06.2023 15:51)
- Процессор сделан, так значит надо его использовать. По-хозяйски
отнестись к делу. Оставить небольшую группу для сопровождения и
баги отлавливать. Копирование/производство относительно дёшего,
когда уже есть готовый образец и даже серия рабочая. - Costic(19.06.2023 15:46)
- Как и всякий VLIW, Эльбрус является тупиком. Это не страшно само по
себе, если вовремя осознать и принять меры. Но вместо этого МЦСТ
накрылся одеялом и пилит миллиарды на этом тупике. - Evgeny_CD(19.06.2023 11:12)
- Обыкновенная заказуха для журнашлюх, разом они возбудились. aнтинoвocти(109 знак., 19.06.2023 08:14, youtube)
- В ролике 100% правда. - Evgeny_CD(19.06.2023 08:52)
- Ролик почти 100% пересказ статьи на хабре, является в основном,
эмоциональным высером и пропагандой, с примесями правды. НО чем им
помешал Эльбрус? вот в чём мой главный вопрос? (знаю про сбер,
кто-то ещё?) мой метод детекции: "кто не хочет - ищет причины, кто
хочет - ищет возможности". - aнтинoвocти(19.06.2023 09:16)
- Эльбрус - вполне перспективная штука, если не пилить на нем бабосы и не нарушать лицензии! Eddy_Em(184 знак., 19.06.2023 09:37)
- Ролик почти 100% пересказ статьи на хабре, является в основном,
эмоциональным высером и пропагандой, с примесями правды. НО чем им
помешал Эльбрус? вот в чём мой главный вопрос? (знаю про сбер,
кто-то ещё?) мой метод детекции: "кто не хочет - ищет причины, кто
хочет - ищет возможности". - aнтинoвocти(19.06.2023 09:16)
- В ролике 100% правда. - Evgeny_CD(19.06.2023 08:52)
- Правильно пишет. А за нарушение GPL этих уродов еще давным-давно стоило бы за яйца вздернуть! - Eddy_Em(19.06.2023 08:01)
- У автора определенно какие-то личные претензии к Эльбрусам и МЦСТ - AlexG(19.06.2023 05:43)
- До корыта не допускают - LightElf(19.06.2023 12:01)
- Что следующим? RISC-V? - Dingo(19.06.2023 04:49)
- Что там у него с плавающей точкой (FPU)? эмуляция? - aнтинoвocти(19.06.2023 09:38, )
- А что не так? Чем тебе не угодила ихняя плывучка? - =AlexD=(19.06.2023 10:00)
- Вот что-то не радует, какие-то лишние сложности на мой взгляд. aнтинoвocти1(1 знак., 19.06.2023 10:12, ссылка)
- и чо? Отдельный блок регистров с плывучкой - обычное дело. - =AlexD=(19.06.2023 10:19)
- копировать архитектурные атавизмы за интелом, который их тянет для
совместимости - это по моему странно. - aнтинoвocти1(19.06.2023 10:24)
- Кто-то скажет атавизм, кто-то - развязывание лишних регистровых
зависимостей. Никакой проблемы в этом не вижу. У DSP бывает и
указатели в отдельных регистрах живут. - =AlexD=(19.06.2023 10:30)
- Ну да, что-то мне подсказывает, что этот проект - сливной бачок для дизайн центров его поддерживающих, чтоб они всегда догоняли интел. aнтинoвocти1(415 знак., 19.06.2023 10:43)
- Кто-то скажет атавизм, кто-то - развязывание лишних регистровых
зависимостей. Никакой проблемы в этом не вижу. У DSP бывает и
указатели в отдельных регистрах живут. - =AlexD=(19.06.2023 10:30)
- копировать архитектурные атавизмы за интелом, который их тянет для
совместимости - это по моему странно. - aнтинoвocти1(19.06.2023 10:24)
- и чо? Отдельный блок регистров с плывучкой - обычное дело. - =AlexD=(19.06.2023 10:19)
- Вот что-то не радует, какие-то лишние сложности на мой взгляд. aнтинoвocти1(1 знак., 19.06.2023 10:12, ссылка)
- А что не так? Чем тебе не угодила ихняя плывучка? - =AlexD=(19.06.2023 10:00)
- Весьма вероятно, т.к. новых отчественных разработок на ARM ядрах
мы, скорее всего, не увидим. - AlexG(19.06.2023 05:46)
- Байкал С2 будет. 128 ядер. На ближайшие 5 лет хватит. - Evgeny_CD(19.06.2023 11:33)
- А с лицензиями от ARM как? Например, у НИИЭТа и Миландра ARM-ядра
из дальнейших планов исчезли. - AlexG(19.06.2023 23:15)
- Вопрос какого рода планы доступны. Официально все компании в РФ ни ни, ни грама в рот, ни мм в жопу. - Evgeny_CD(19.06.2023 23:42)
- Все нужные лицензии у них есть и активны. Как описал выше, я категероически не хочу знать как. Лицензий на следующее поколение ядер ARM не будет, да и фиг с ним. Текущие достаточно быстры, чтобы быть актуальным ближайшие 5 лет. - Evgeny_CD(19.06.2023 23:41)
- Точно будет? А кто его будет делать? ...Вообще вся эта дискуссия
смахивает на "ужас нерожденного" :-) - _volkanaft_(19.06.2023 12:52)
- Будет. Я запретил Байкалу рассказывать мне, как они
телепортируются. - Evgeny_CD(19.06.2023 13:03)
- А свой дистрибутив у Байкала будет? А то я просил образ линуха у
производителя материнки, т.к. не мог найти ничего работающего. Как
итог Байкал валяется у меня под столом немым укором бесполезно
потраченных денег. - =AlexD=(19.06.2023 13:24)
- Напиши в суппорт. Суппортом у них толковый человек заведует. - Evgeny_CD(19.06.2023 13:31)
- Пыонятно! Евгений с " Байкалом" в доле... :-) - _volkanaft_(19.06.2023 15:10)
- Напиши в суппорт. Суппортом у них толковый человек заведует. - Evgeny_CD(19.06.2023 13:31)
- А свой дистрибутив у Байкала будет? А то я просил образ линуха у
производителя материнки, т.к. не мог найти ничего работающего. Как
итог Байкал валяется у меня под столом немым укором бесполезно
потраченных денег. - =AlexD=(19.06.2023 13:24)
- Будет. Я запретил Байкалу рассказывать мне, как они
телепортируются. - Evgeny_CD(19.06.2023 13:03)
- Для чего? вот есть в доступе xeon 56 ядер, есть приложение,
запускаю его на 1-12 ядер из 56, рост производительности почти
линейный, а после куй, почему? - aнтинoвocти2(19.06.2023 11:41)
- Возможно так написано приложение. Возможно планировщик ОС не умеет нормально раскидывать потоки на такое число ядер. Надо профайлить и оптимизировать, а не в пустыне вопить. - LightElf(19.06.2023 12:04)
- Серверный рынок. Облачный хостинг. Закон Амдала. Evgeny_CD(1 знак., 19.06.2023 11:52, ссылка)
- Этому приложению до этого закона ещё далеко, всё проще, потоки в
КЭШах мешают друг другу, какая нибудь криптография сможет и все 56
ядер утилизировать (много считает, мало к памяти обращается),
правда рост будет не совсем лнейный, но будет, а некоторые
приложения могут даже снижать производительность при росте отданных
им ядер. Так для чего хватит 128 ядер? - aнтинoвocти2(19.06.2023 12:34)
- Пущать 128 разных задач. Или 128 экземпляров одинаковых задач для
128 разных клиентов. - LightElf(19.06.2023 12:35)
- Или 127 виртуальных машин. 128е ядро - для гипервизора - Evgeny_CD(19.06.2023 13:01)
- Пущать 128 разных задач. Или 128 экземпляров одинаковых задач для
128 разных клиентов. - LightElf(19.06.2023 12:35)
- Этому приложению до этого закона ещё далеко, всё проще, потоки в
КЭШах мешают друг другу, какая нибудь криптография сможет и все 56
ядер утилизировать (много считает, мало к памяти обращается),
правда рост будет не совсем лнейный, но будет, а некоторые
приложения могут даже снижать производительность при росте отданных
им ядер. Так для чего хватит 128 ядер? - aнтинoвocти2(19.06.2023 12:34)
- А с лицензиями от ARM как? Например, у НИИЭТа и Миландра ARM-ядра
из дальнейших планов исчезли. - AlexG(19.06.2023 23:15)
- Ядро силами "цифровых решений" свой АРМ готовят. - POV(19.06.2023 08:00)
- Байкал С2 будет. 128 ядер. На ближайшие 5 лет хватит. - Evgeny_CD(19.06.2023 11:33)
- Что там у него с плавающей точкой (FPU)? эмуляция? - aнтинoвocти(19.06.2023 09:38, )
- Картинки интересные, а текст - стоны юзверя. Танчики не погонять
задешево. Там были и более профессиональные статьи. - max(19.06.2023 11:05)