Здравствуйте, netch80, Вы писали:
V>>В любом случае, эффективно обыграть эту проблему с целью утилизации выч. блоков получилось только с аппаратной многопоточностью, а не через ОоО и переименование регистров. V>>Единственно что, 2x аппаратная многопоточность оказалась недостаточной, более хорошо выглядели 4x и даже 16x многопоточность. N>Так "утилизация выч. блоков" никогда не была прямой целью.
Это совершенно новая для меня мысль. ))
N>А вот сократить задержки на команды в целом — да.
Это в "лапшееобразном" коде т.н. "бизнес-логики", где куча if-ов и простейших перемещений данных в памяти, зачастую даже без вычислений.
Т.е. где код заведомо неэффективный-непродуманный с произвольной итерацией по графу косвенно связанных блоков данных произвольной же глубины этих связей.
Именно под такой непродуманный код требуется ОоО.
А где происходят именно полезные вычисления над сколь-нибудь заметными объёмами данных, там все эти вещи прекрасно обыгрываются через prefetch, да и сам лейаут данных в памяти продуман всяко лучше, чем эти бесконечные виноградные гроздья т.н. бизнес-объектов в памяти, особенно в языках наподобие Джавы или C#, провоцирующих просто чудовищную косвенность хранения данных, что предсказать промахи кеша на этапе компиляции действительно невозможно. ))
Здравствуйте, netch80, Вы писали:
V>>На сегодня уже понятно, что NUMA-архитектура наиболее выгодно реализуется как набор многоядерных UMA-узлов с программируемой связью м/у узлами. V>>Т.е., данные из других узлов надо забирать-отправлять явным образом. N>Ну то есть вместо другого домена другой узел, просто связь не выглядит как Ethernet, Infiniband или кого там будут использовать вместо. Максимум — с контролируемым RDMA.
Именно так.
Собсно, в процах Cell присутствуют развитые ср-ва управления перекачкой памяти (управление множеством автоматов DMA), потому что без этого архитектура не работает.
V>>Это напоминает общение с памятью видеокартеек. N>Там сама карта не очень контролирует вмешательство в её память.
Это просто хорошо известный пример гетерогенной по памяти архитектуры. В том числе, когда видеоускоритель встроенный и сидит на той же самой памяти.
При двусторонних подобных ср-вах выбор логики управления (кто там master, а кто slave) будет происходить уже на программном уровне и на более мелком уровне — на уровне прикладных сущностей, ИМХО.
Здравствуйте, netch80, Вы писали:
N>Теперь, наблюдая текущие проблемы, попробуй вычислить, где же был обман
Обман случился в начале нулевых, когда разработанный в РФ для ASML коротковолновый лазер на парах олова и соотв. системы его фокусировки передали задаром в интеллектуальную собственность ASML, а теперь этой ASML запрещают продавать станки с лазером нашей разработки.
Напомню, что Intel и IBM так и ниасилили разработку своих коротковолновых лазеров, официально отказавшись в начале нулевых от дальнейших исследований в этом направлении.
ASML тоже ниасилили, этот лазер разработали в РФ именно по заказу ASML.
Теперь весь мир печатает микросхемы лазерами нашей разработки, но нам запрещено!
Кино и немцы!
Я рад, что в твоём мире у микроконтроллера (а не CPU) на RISC-V с частотой 85 МГц "с производительностью "скриптов" все в порядке".
А обещания выпустить что-то там на RISC-V — это значит уже делают и можно использовать.
Бенчмарки покажешь? Ну, наверняка же сравнили с топовыми интелами и убогими Эльбрусами, чтобы показать как RISC-V всех уделывает?
Здравствуйте, novitk, Вы писали:
N>Был ARM, MIPS и Sparc. Это проверенные работающие решение с развитым стеком стоимостью миллионы задочасов. Собственно китайцы так и поступили для Loongson(MIPS).
Микросхема центрального процессора 1891ВМ018 — вычислитель серверного класса. Содержит 8 ядер архитектуры «SPARC» 9-й версии с тактовой частотой до 2000 МГц. Позволяет строить многопроцессорные серверы и рабочие станции, а также бортовые вычислители, требовательные к скорости обработки и передачи информации.
Этот проц с Out-of-Order, т.е. МЦСТ прекрасно умеет в ОоО.
BE-T1000 – это отечественная система на кристалле на базе архитектуры MIPS Warrior P-class P5600.
N>Импортозаместись, а потом можно и попродвигать архитектуру.
Оно происходило одновременно, ес-но, бо жизненный цикл архитектур составляет десятилетия.
И давайте уже назвать вещи своими именами — Эльбрус изначально предназначен для выпуска не на самом передовом техпроцессе, но при этом должен уметь молотить чудовищные объёмы чисел.
Это ж банально способ сгладить эффект от технологического отставания в области печати микросхем.
"Голь на выдумку хитра!" (С)
Ну и, учитывая позиционирование сабжевого Эльбруса-Б на 90нм при целях "быть на уровне" или гипотетически на 5нм "быть за уровнем" — да это тот же самый трюк, хосподя.
Т.е., происходит попытка покрыть два основных направления:
E2k — мощный сигнальный процессор, код для него писать стоит вдумчиво, чтобы выжать из непростой этой балалайки максимум гигафлопсов;
Эльбрус-Б — "бытовой" проц для пресловутой "бизнес-логики", т.е. для задорного исполнения многопоточного джуниорского говнокода.
Здравствуйте, vdimas, Вы писали:
V>Не подскажешь, в каком из мейнстримовых интелов каждое ядро способно выполнить 8 целочисленных и 24 вещественных команды за один такт? V>А в каком из мейнстримовых интелов присутствует 6 векторных АЛУ на ядро?
Извиняюсь, а зачем это надо России?
Понимаешь...
Есть решения которые делаются при черезмерном богатстве, а есть решения, которые делаются от бедности.
Зачем нам 6 векторных АЛУ на ядро? Мы одно приличное АЛУ в кристалл впихнуть не можем.
И когда мы дождёмся отечественного процессора? С таким подходом — никогда.
A>Понимаешь... A>Есть решения которые делаются при черезмерном богатстве, а есть решения, которые делаются от бедности. A>Зачем нам 6 векторных АЛУ на ядро? Мы одно приличное АЛУ в кристалл впихнуть не можем.
A>И когда мы дождёмся отечественного процессора? С таким подходом — никогда.
ну да, приземлить этих ребят на отечественные техпроцессы было бы хорошо
Здравствуйте, vdimas, Вы писали:
S>>Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java. V>Не систему трейдинга,
Disruptor в первую очередь разрабатывался для системы трейдинга.
V>а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе...
Гвоздём там является секвенсер:
the Ring Buffer is only responsible for the storing and updating of the data (Events) that move through the Disruptor. For some advanced use cases, it can even be completely replaced by the user.
Sequencer: The Sequencer is the real core of the Disruptor. The two implementations (single producer, multi producer) of this interface implement all the concurrent algorithms for fast, correct passing of data between producers and consumers.
V>В любом случае, наша реализация межпоточной очереди заметно эффективней, да еще без ограничений на её размер, в отличие от наивной реализации Disruptor.
Что за ваша реализация?
Да, кстати, disruptor — это всё-таки не совсем очередь.
S>>И для этого не пришлось ни ломать JIT, ни переписывать компилятор, ни раскладывать данные по линейкам кеша. V>И да, разумеется, максимальный трафик перекачки достигается тогда, когда перекачиваемые данные разнесены по линейкам кеша и у них, и у нас, т.е. когда курсор чтения заметно отстаёт от курсора записи. V>Ну вот как раз именно в этом режиме "постоянного насыщения очереди" наша реализация оказалась резко эффективней, т.е. в режиме наибольшей нагрузки. V>В режиме передачи одиночных пакетов с паузой задержки оказались сравнимы.
В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера.
Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy.
V>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor.
Без фиксированной ёмкости у тебя будет проблема с latency.
V>Плюс у нас есть возможность ожидать на примитиве синхронизации уровня ОС, т.е. отправлять поток в спячку, освобождая аппаратный поток для других задач в отсутствии данных, а у тех безальтернативно спин-ожидание.
Доки-то хоть читал? https://lmax-exchange.github.io/disruptor/user-guide/index.html#_alternative_wait_strategies
V>В общем, самоучки от IT какие-то, простейшая дополнительная требуемая функциональность (рост очереди при необходимости, возможность ожидать на семафоре при необходимости) являются V>у них невозможными, резко замедляющими вообще всё, что весь профит улетучивается.
V>Ты код-то поизучай внимательно, он у них открыт. ))
Вот с этого и начни, прежде чем чушь нести.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Ну, это не мои слова, это Шигорин сказал. (заметь, я все время ссылаюсь на про-эльбрусовские источники. а ты меня хейтером обозвал)
k> А обещания выпустить что-то там на RISC-V — это значит уже делают и можно использовать.
Я сказал, что делают (это даже не означает, что начали выпускать). Про можно использовать ты сам придумал.
k> Бенчмарки покажешь? Ну, наверняка же сравнили с топовыми интелами и убогими Эльбрусами, чтобы показать как RISC-V всех уделывает?
О бенчмарках российского риска-пять говорить преждевременно, процесс только-только начался. Западный, говорят, уже дерет жопу эпикам.
Здравствуйте, rudzuk, Вы писали:
R>Ну, это не мои слова, это Шигорин сказал. (заметь, я все время ссылаюсь на про-эльбрусовские источники. а ты меня хейтером обозвал)
В видео сначала рассказ о том, что на Эльбрусе проблема с браузером, т.к. старый Firefox только портирован и нужно уже Chromium портировать.
Далее оказывается, что Google свернула портирование своего Chromium на RISC-V (ой, т.е. весь софт нужно портировать на RISC-V, примерно как на Эльбрусы и даже такая крупная корпорация не спешит это делать для такой отличной открытой и массовой архитектуры?).
Дальше про то, что у RISC-V проблем со скриптами быть не должно, но вопрос нужны ли вообще эти скрипты или скоро все назад откатятся к компилируемым программам.
Как из этого следует вывод, что микроконтроллер с частотой 85 МГц можно использовать в качестве ЦП вместо Эльбруса и он будет быстрее скрипты обрабатывать?
Если ты не понял, то ещё раз: мой посыл в том, что Эльбрусы существуют в виде реально существующих процессоров уже несколько лет,
некоторый софт портирован, при желании можно хоть программы под x86 запускать в режиме эмуляции.
Сегодня есть готовая альтернатива или только очередные планы о том, что вот-вот ещё через год/два/десять что-то может быть будет?
R>Я сказал, что делают (это даже не означает, что начали выпускать).
Ну, пусть занимаются, я не против.
R>Про можно использовать ты сам придумал.
Я просто зря ожидаю нормальный ответ, когда тут одна сплошная демагогия.
Пишу: никто альтернативу не сделал
Ответ: делают
В этом контексте по-моему логично воспринимать "делают" как: "процессоры уже производятся и можно использовать", а не: "люди занимаются, может когда-то что-то будут производить".
R>О бенчмарках российского риска-пять говорить преждевременно, процесс только-только начался. Западный, говорят, уже дерет жопу эпикам.
Рекламный пресс-релиз какой-то из 2022 года.
Я так понимаю, что не получилось найти даже бенчмарки реально существующих западных процессоров на RISC-V?
Точно они тот же Apple M4 уделывают или может врут?
Здравствуйте, karbofos42, Вы писали:
k> Далее оказывается, что Google свернула портирование своего Chromium на RISC-V (ой, т.е. весь софт нужно портировать на RISC-V, примерно как на Эльбрусы и даже такая крупная корпорация не спешит это делать для такой отличной открытой и массовой архитектуры?).
Не нужно. Но если где-то используется динамическая генерация кода, то такой код портировать придется, да.
k> Дальше про то, что у RISC-V проблем со скриптами быть не должно, но вопрос нужны ли вообще эти скрипты или скоро все назад откатятся к компилируемым программам.
Откатятся-откатятся. Все пойдем на сисиплюс, писать под эльбрус
k> Как из этого следует вывод, что микроконтроллер с частотой 85 МГц можно использовать в качестве ЦП вместо Эльбруса и он будет быстрее скрипты обрабатывать?
Я твои фантазии комментировать не буду, уж извини.
k> Если ты не понял, то ещё раз: мой посыл в том, что Эльбрусы существуют в виде реально существующих процессоров уже несколько лет, k> некоторый софт портирован, при желании можно хоть программы под x86 запускать в режиме эмуляции.
А мой посыл в том, что эта тупиковая ветвь, и нехай вояки с ней продолжают пердолиться, а бизнесу эта радость ни к чему.
k> Сегодня есть готовая альтернатива или только очередные планы о том, что вот-вот ещё через год/два/десять что-то может быть будет?
Есть байкал. Есть даже бенчмарки мобильного байкала против эльбруса (сам найдешь, если интересно. первая ссылка в гугле). Так вот мобильный байкал, с вдвое меньшим тдп, показывает сравнимые с эльбрусом результаты (кроме числодробилок).
k> Ну, пусть занимаются, я не против.
Ну прям от сердца отлегло...
k> Я просто зря ожидаю нормальный ответ, когда тут одна сплошная демагогия. k> Пишу: никто альтернативу не сделал k> Ответ: делают k> В этом контексте по-моему логично воспринимать "делают" как: "процессоры уже производятся и можно использовать", а не: "люди занимаются, может когда-то что-то будут производить".
А по-моему, в этом контексте, "делают", означает только процесс. Я не говорил, что у нас есть готовые решения на риске-пять. Да и откуда им взяться, когда российскому альянсу риск-пять всего три года.
k> Рекламный пресс-релиз какой-то из 2022 года.
Вот так и знал, пруфы просишь, а нихрена не читаешь. Там же написано, что это не бумажный анонс и у них есть комплекты для разработчиков. Кстати, уже вторая версия этого камня вышла.
k> Я так понимаю, что не получилось найти даже бенчмарки реально существующих западных процессоров на RISC-V?
Какой ты привиредливый. Пруфы тебе дай. Цифры тебе покажи. Тебе это правда нужно, или просто хочешь, чтобы я з@ебался?
k> Точно они тот же Apple M4 уделывают или может врут?
Они говорят, что рвут эпиков. Эпики примерно раз в 10 быстрее M4. Врут или нет... Ну проверь
Здравствуйте, vdimas, Вы писали:
V>>>В любом случае, эффективно обыграть эту проблему с целью утилизации выч. блоков получилось только с аппаратной многопоточностью, а не через ОоО и переименование регистров. V>>>Единственно что, 2x аппаратная многопоточность оказалась недостаточной, более хорошо выглядели 4x и даже 16x многопоточность. N>>Так "утилизация выч. блоков" никогда не была прямой целью. V>Это совершенно новая для меня мысль. ))
Да ну. "Идеальный вариант — реализации нет, а задача выполняется" ([Г.Альтшуллер]).
Важно выполнение команд, как можно быстрее, при условии, что точно и без перегрева. А сколько и каких вычислительнных блоков — какая разница? Потому просто нет смысла на этом концентрироваться. Хотя я понимаю, когда мыслишь в идеях, что важен в первую очередь SIMD, а его блоки дорогие, то начинаешь смещаться в эту сторону. Ну вот видимо потому в EPIC-Эльбрусах всё остальное страдает
N>>А вот сократить задержки на команды в целом — да. V>Это в "лапшееобразном" коде т.н. "бизнес-логики", где куча if-ов и простейших перемещений данных в памяти, зачастую даже без вычислений. V>Т.е. где код заведомо неэффективный-непродуманный с произвольной итерацией по графу косвенно связанных блоков данных произвольной же глубины этих связей. V>Именно под такой непродуманный код требуется ОоО.
Что он "лапшеобразный" — согласен. А вот что он "непродуманный" — нет.
Напоминаю, ещё когда в 1951-м или около того начали выпускать на рынок первые коммерческие компьютеры, спрос на "экономические" задачи оказался в 5 раз выше чем на вычислительные. А с тех пор стало только хуже. Ты повторяешь за Intel, когда они при проектировании Pentium4 оставили в фаворе только мультим*дию. Напомнить, чем закончилась история Pentium4?
V>А где происходят именно полезные вычисления над сколь-нибудь заметными объёмами данных,
Удивительно, что ты не сказал "прекрасные полезные вычисления"</irony>
V>там все эти вещи прекрасно обыгрываются через prefetch, да и сам лейаут данных в памяти продуман всяко лучше, чем эти бесконечные виноградные гроздья т.н. бизнес-объектов в памяти, особенно в языках наподобие Джавы или C#, провоцирующих просто чудовищную косвенность хранения данных, что предсказать промахи кеша на этапе компиляции действительно невозможно. ))
Дададад. Теперь осталось только вернуться в реальность и оценить долю задач с SIMD среди вероятных применений EPIC-Эльбруса... особенно когда его позиционируют в походные лаптопы. Или через 25 лет после первых радостных репортов на основании симуляции эмулятора — от этой идеи начали отказываться? Без иронии, я плотно не слежу.
Здравствуйте, karbofos42, Вы писали:
K>Как из этого следует вывод, что микроконтроллер с частотой 85 МГц можно использовать в качестве ЦП вместо Эльбруса и он будет быстрее скрипты обрабатывать? K>Если ты не понял, то ещё раз: мой посыл в том, что Эльбрусы существуют в виде реально существующих процессоров уже несколько лет, K>некоторый софт портирован, при желании можно хоть программы под x86 запускать в режиме эмуляции. K>Сегодня есть готовая альтернатива или только очередные планы о том, что вот-вот ещё через год/два/десять что-то может быть будет?
Моя подозревать, что в нынешних политических условиях вопрос надо ставить иначе: будут ли ещё существовать Эльбрусы-EPIC в виде производимого железа, или новых не будет, а над старыми будут трястись как над древними реликвиями? А RISC-V можно будет как раз ещё тащить караванами через монгольские степи, потому что он будет в любом холодильнике по десять штук и в утюге по три?
(Я обсуждать ответ на это не буду.)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, koenig, Вы писали:
K>>напихать в 200 раз больше исполняющих блоков чем кто-то, кого они считают образцом. S>Хорошая идея. Вопрос: откуда возьмётся в 200 раз больше места на кристалле? Интел, значит, со своими 11нм, еле как впихивает свои несколько десятков FMA-блоков, а мы со своими 90 впихнём столько же? S>Или там 192-ядерный RISC-V: чтобы впихнуть хотя бы в 30 раз больше, нужно как-то сделать площадь блоков в 30 раз меньше. Не говоря уже о 200х-кратном превышении.
Так там же большая часть занята предикторами, кешами команд и прочим. Нвидия как раз делает упор на алушки и в работе с нейросетями (НС) это срабатывает, потому что там условных переходов либо нет, либо они неэфективны до состояния их нет. Прогулки по памяти крайне однородны и прочая ботва. По производительности на схожем тех.процессе нвидиевцы как раз до 200 раз и дают. Но, как написать под это дело ось и драйверы, которые ни разу не НС, а будучи реализованными в виде НС как раз и сожрут весь прирост -- задача достойная белого человека.
Здравствуйте, ·, Вы писали:
S>>>Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java. V>>Не систему трейдинга, ·>Disruptor в первую очередь разрабатывался для системы трейдинга.
Так ты не меня поправляй, а Синклера, который спорил с тезисом о необходимости эффективного обмена данными м/у потоками, при этом сами же привёл пример подсистемы, спроектированной именно для такого обмена. Это вышло вдвойне забавно, бо и без этого его позиция улыбала донельзя. ))
А для трейдинга или нет — в контексте обмена аргументами не принципиально, пустое твоё замечание, лишь бы вставить бесполезные 5 копеек.
V>>а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе... ·>Гвоздём там является секвенсер: ·>
the Ring Buffer is only responsible for the storing and updating of the data (Events) that move through the Disruptor. For some advanced use cases, it can even be completely replaced by the user.
·>
Sequencer: The Sequencer is the real core of the Disruptor. The two implementations (single producer, multi producer) of this interface implement all the concurrent algorithms for fast, correct passing of data between producers and consumers.
Опять эта брехня...
Подставь некую свою тормозную очередь в Disruptor, и система будет тормозить как обычное Джава-приложение.
V>>В любом случае, наша реализация межпоточной очереди заметно эффективней, да еще без ограничений на её размер, в отличие от наивной реализации Disruptor. ·>Что за ваша реализация? ·>Да, кстати, disruptor — это всё-таки не совсем очередь.
Ага, я помню твои попытки обвинить окружающих в том, что они не понимают отличие константности от иммутабельности.
Эзотерика она такая, в отсутствии понимания даёт веру в некие плохообъяснимые свои ощущения. ))
·>В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера.
Не говори о том, о чём не знаешь.
Некоторые биржи генерят десятки миллионов сообщений в секунду суммарно по различным инструментам в пике на одном узле.
Наша система способна работать в качестве как клиентской, так и серверной.
И на клиента тоже миллионы в секунду могут неожиданно упасть в пике, т.е. умение шустро перелопатить трафик тоже важно.
Так вот, именно в пиковой нагрузке этот Disruptor сливает, потому что требует обязательно 1-2 CAS-операций на чтение каждого элемента очереди в общем случае.
В нашей реализации при максимуме нагрузки приходится по одному CAS на десятки-сотни элементов.
Другое дело, что для Джавы это похер, бо на парсинге сообщений и прикладной обработке сжирается столько, что лишние пару CAS на каждое сообщение не видны и под микроскопом. ))
В нейтиве зато эти лишние CAS ой как видны, бо там другие порядки расходов на прикладные вещи.
И да, наша реализация изначально умеет работать в режиме multiple producer, что дорого для круговой interlocked-очереди, а любой multicast-канал имеет обязательно два потока, которые надо сливать в один, упорядочивать и отбрасывать дубликаты — это стандарт для бирж.
И да, спин-ожидание у нас тоже присутствует в кач-ве опции (полезно на клиентской стороне) и средняя реакция consumer в сотню-другую наносекунд на появление данных в очереди — тут уже предел современных систем обеспечения когерентности в разных потоках. Кстате, тоже можно producer+consumer посадить на одно ядро, разнеся по гипертредингу, тоже будет максимально быстро.
А в Джаве можно указать, на каких аппаратных ядрах исполнять тот или иной поток?
·>Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy.
Я уже делал замечание — в случае задействования механизма ожидания на примитиве синхронизации, вся эта система начинает дико тормозить, потому что тормозится Producer, который в этом случае дёргает примитив синхронизации в своём колбэке, вызываемом после помещения элемента в очередь. И там сразу полная ж-па наступает.
Да и вообще, событийная модель на виртуальных вызовах...
Всё это какое-то одно сплошное нубство.
Кароч, нормально Disruptor работает только в режиме spin-wait со стороны consumer.
Там явно самоучки от IT пилили. ))
V>>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor. ·>Без фиксированной ёмкости у тебя будет проблема с latency.
Одно косвенное чтение, т.е. примерно плюс 0-8 наносекунд, бо косвенное безусловное чтение зачастую делается процами еще на этапе предвыборки механизмом ОоО.
И минус многие сотни наносекунд и даже микросекунд на всём остальном, в сравнении с реализацией Disruptor.
Потому что круговая очередь — это изначально не самая дешевая lock-free структура для передачи данных м/у потоками.
А еще эта очередь засирает и инвалидирует кеш!
У нас тоже получается де-факто круговая очередь, но она динамическая — растёт в максимуме нагрузки и отдаёт постепенно элементы обратно в память, если не требуются.
И эта очередь работает через стековую организацию в оба конца, т.е. при малом кол-ве сообщений в очереди "вагончиками" будут одни и те же как прикладные, так и инфраструктурные объекты, т.к. будут трогаться только верхние элементы всех стековых буферов. И такой подход на C# тоже дал офигенный профит, что реализация не уступает нейтивной по эффективности.
Просто надо ж понимать хотя бы самые базовые вещи обеспечения эффективности на современных архитектурах.
И доку читал и исходники внимательно изучал.
Детсад детсадом погоняет.
Это писали непрофессиональные разрабы ни в одном из своих мест.
Они тупо взяли одну из валяющихся в Сети реализаций lock-free кругового буфера и аккуратно перенесли на Джаву. ))
Но во всём остальном оставили такой же точно мрак — тупая событийная модель как в турбо-паскале 80-х, куча виртуальных вызовов где этого совершенно не требуется на данном уровне сущностей. В общем, вот это хорошо знакомое бессмысленное и беспощадное джавовское мельтешение в мелочах, на радость продавцам электричества.
Пороть вас некому... Натравить бы на вас Гринпис, а то они не с теми воюют. ))
V>>Ты код-то поизучай внимательно, он у них открыт. )) ·>Вот с этого и начни, прежде чем чушь нести.
Я-то поизучал внимательно еще в прошлый раз, в отличие от пустопорожнего тебя.
И я хорошо понимаю, что там происходит и почему. Но еще в прошлом нашем обсуждении этого Disruptor стало быстро понятно, что для тебя там всё тёмный лес — ты не понимаешь тонкостей. Значит, никогда всерьёз не вылизывал код на быстродействие, не видишь тонких мест современной аппаратуры, эрудиция в этой области у тебя примерно нулевая.
Понимаешь, даже похер, что у тебя непрофильное образование, но самому покрыть пробелы, набить руку можно было уже давно. Просто ты выбрал себе ту самую раздражающую других разрабов роль похериста от IT, которые преднамеренно сосредотачиваются исключительно и только на высоком уровне и собственном балабольстве с важным видом, вызывающим у окружающих только раздражение и насмешки. Не доходит до тебя, смотрю, что звиздеть — не мешки ворочать. ))
Здравствуйте, netch80, Вы писали:
N>Да ну. "Идеальный вариант — реализации нет, а задача выполняется" ([Г.Альтшуллер]).
Ну-ну-ну...
N>Важно выполнение команд, как можно быстрее, при условии, что точно и без перегрева. А сколько и каких вычислительнных блоков — какая разница? Потому просто нет смысла на этом концентрироваться. Хотя я понимаю, когда мыслишь в идеях, что важен в первую очередь SIMD, а его блоки дорогие, то начинаешь смещаться в эту сторону.
Ну потому что запихать много блоков и заставить их работать — это чудовищно дорого, это самый крайний край современного IT, от этого хочется получать соотв. отдачу, а как же? ))
Тем более, что эту отдачу можно получать, добавив всего 12% вентилей для конкурирующего аппаратного потока.
В общем, в любом инженерном решении обязан присутствовать баланс вложений и отдачи, и это не может подвергаться сомнению.
ОК, иногда можно, но лишь для того, чтобы опять убедиться в правильности этой мысли. ))
N>Ну вот видимо потому в EPIC-Эльбрусах всё остальное страдает
Страдают там компиляторы.
И то, если бы на дворе был 2000-й, то так нельзя было бы сказать, это они за последние 25+ лет нехило научились оптимизировать, и даже за последние 10- лет. ))
Но всё это прошло мимо архитектуры Эльбрус.
N>Что он "лапшеобразный" — согласен. А вот что он "непродуманный" — нет. N>Напоминаю, ещё когда в 1951-м или около того начали выпускать на рынок первые коммерческие компьютеры, спрос на "экономические" задачи оказался в 5 раз выше чем на вычислительные.
Так ты не понял мою мысль, получается.
Дело в том, что все, т.е. абсолютно все "бизнес-задачи" легко сводятся к тем самым "вычислительным" через преобразования формул и прочие подстановки эквивалентности.
И зачастую даже бизнес-задачи именно доводят до ума, что эффективность их обработки возрастает в сотни раз — взять те же реляционки или современные NoSQL — это выделенные задачи из бизнес-области. Всевозможные диспетчеры сообщений уже есть готовые достаточно эффективные (если бы еще народ понимал, для чего и как ими пользоваться) и прочее такое.
По-сути, любая задача в IT — это моделирование предметной области.
Это моделирование включает в себя доставку данных и вычисления над ними, усё!
Независимо от области моделирования.
Кто бы еще строил графы транспортировки и графы вычислений... ))
Здравствуйте, rudzuk, Вы писали:
R>А мой посыл в том, что эта тупиковая ветвь, и нехай вояки с ней продолжают пердолиться, а бизнесу эта радость ни к чему.
Бизнесу пока и RISC-V ни к чему. Сидят себе на параллельном импорте x86 и не парятся.
У RISC-V в целом пока только перспективы на бумаге и когда они станут реальностью для масс — неизвестно.
R>Есть байкал. Есть даже бенчмарки мобильного байкала против эльбруса (сам найдешь, если интересно. первая ссылка в гугле). Так вот мобильный байкал, с вдвое меньшим тдп, показывает сравнимые с эльбрусом результаты (кроме числодробилок).
Байкал был, ибо ARM они производить нигде не могут (разве что найдут фабрику, которая согласится поругаться ради небольших партий Байкалов с ARM).
Есть у Байкалов по-моему и на MIPS процессоры, но там производительность ни о чём.
R>Вот так и знал, пруфы просишь, а нихрена не читаешь. Там же написано, что это не бумажный анонс и у них есть комплекты для разработчиков. Кстати, уже вторая версия этого камня вышла.
Бенчмарки там есть? Ещё бы они в своём рекламном пресс-релизе написали, что ничего из себя не представляют.
R>Какой ты привиредливый. Пруфы тебе дай. Цифры тебе покажи. Тебе это правда нужно, или просто хочешь, чтобы я з@ебался?
Ну, ты утверждаешь, что Эльбрусы говно, т.к. сливают в существующих бенчмарках топовым интелам и эпплам.
RISC-V по твоим словам крутая архитектура, которая Эльбрус уж точно уделает.
Вот мне хочется узнать откуда такая уверенность.
R>Они говорят, что рвут эпиков. Эпики примерно раз в 10 быстрее M4. Врут или нет... Ну проверь
Ты принёс утверждение — значит твоя работа прикрепить это чем-то, кроме слов.
Я не нашёл сравнений процессоров на RISC-V с теми же интелами.
Здравствуйте, rudzuk, Вы писали:
a>> R>Блин, посмотрел на Apple M4, так даже он его уделывает. Мобильный проц уделывает эльбрус, который делали под супера
a>> На технологии посмотри!
R>У 32с 7 нм, у M4 3 нм (так у него и тфлопсов больше в полтора раза). У M1 5 нм и он практически равен по tflops 32c. Причем, тфлопсы 32c они планируемые.
Здравствуйте, karbofos42, Вы писали:
k> Бизнесу пока и RISC-V ни к чему. Сидят себе на параллельном импорте x86 и не парятся.
У бизнеса есть потребность в отечественных камнях, им государство так постановило.
k> У RISC-V в целом пока только перспективы на бумаге и когда они станут реальностью для масс — неизвестно.
Проблемы с производством касаются любых очественных чипов т.к. собственных подходящих фабрик в отечестве нет.
k> Бенчмарки там есть? Ещё бы они в своём рекламном пресс-релизе написали, что ничего из себя не представляют.
Там есть график. Цифр нет.
k> Ну, ты утверждаешь, что Эльбрусы говно, т.к. сливают в существующих бенчмарках топовым интелам и эпплам.
Не-не-не. Ты перевираешь мои слова. Если смотреть бенчи, то эльбрус сливает не топам, а процам десятилетней давности. А то, о чем ты говоришь (про топы), это я сравнивал бумажный эльбрус 32с с его планируемыми терафлопсами. Ну ты сам посуди: процессор который оптимизировали под суперкомпьютеры (т.е. суровый числогрыз), как числодробилка сливает мобильному процессору общего назначения (хоть и топу). И это передовой, но, бумажный 32с. Если смотреть на существующий 16с, то он сливает вообще более чем в два раза, потребляя, при этом 130 ватт, в те же два раза больше чем M4. Топы интела и амуде для эльбрусов просто не досягаемы, разница более чем в 10 раз. И все же моя основная претензия не производительность, а маргинальность архитектуры, но эту тему я развивать, пожалуй, не буду.
k> RISC-V по твоим словам крутая архитектура, которая Эльбрус уж точно уделает.
Я этого не говорил, не ври.
k> Я не нашёл сравнений процессоров на RISC-V с теми же интелами.
