Здравствуйте, alpha21264, Вы писали:
a> a>> На технологии посмотри!
a> R>У 32с 7 нм, у M4 3 нм (так у него и тфлопсов больше в полтора раза). У M1 5 нм и он практически равен по tflops 32c. Причем, тфлопсы 32c они планируемые.
a> Скажи понятно, что ты имеешь в виду.
Здравствуйте, vdimas, Вы писали:
V>>>Не систему трейдинга, V>·>Disruptor в первую очередь разрабатывался для системы трейдинга. V>Так ты не меня поправляй, а Синклера, который спорил с тезисом о необходимости эффективного обмена данными м/у потоками, при этом сами же привёл пример подсистемы, спроектированной именно для такого обмена. Это вышло вдвойне забавно, бо и без этого его позиция улыбала донельзя. ))
Он не с этим спорил. Ты как всегда приписываешь свои фантазии оппонентам и их опровергаешь.
V>А для трейдинга или нет — в контексте обмена аргументами не принципиально, пустое твоё замечание, лишь бы вставить бесполезные 5 копеек.
В контексте было об "общей архитектуры и применяемых решений". В lmax придумали общую архитектуру и дизраптор в качестве решения.
V>>>а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе... V>·>Гвоздём там является секвенсер: V>·>
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.
V>·>
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>Опять эта брехня...
Аргумент вида: "Вы всё врёти!!!"
V>Подставь некую свою тормозную очередь в Disruptor, и система будет тормозить как обычное Джава-приложение.
Софизм: "ложная дилемма". Почему ты решил, что вместо кольца непременно надо подставлять тормозную очередь?
V>Ага, я помню твои попытки обвинить окружающих в том, что они не понимают отличие константности от иммутабельности.
Демагогия.
V>·>В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера. V>Не говори о том, о чём не знаешь.
Демагогия.
V>Некоторые биржи генерят десятки миллионов сообщений в секунду
Некоторые это такие как lmax? Внезапно?
V>суммарно по различным инструментам в пике на одном узле.
Да беда в том, что в том же lmax инструменты вроде как различные, но 90% трафика идёт на какой-нибудь eurusd. И различность инструментов рояли не играет.
V>Наша система способна работать в качестве как клиентской, так и серверной. V>И на клиента тоже миллионы в секунду могут неожиданно упасть в пике, т.е. умение шустро перелопатить трафик тоже важно.
Молодцы! Почти достигли то, что в lmax делали ~20 лет назад, на оборудовании того времени.
V>Так вот, именно в пиковой нагрузке этот Disruptor сливает, потому что требует обязательно 1-2 CAS-операций на чтение каждого элемента очереди в общем случае.
Откуда этот бред? И ведь про батчинг я тебе уже упоминал, но ты ж не читатель.
V>Другое дело, что для Джавы это похер, бо на парсинге сообщений и прикладной обработке сжирается столько, что лишние пару CAS на каждое сообщение не видны и под микроскопом. )) V>В нейтиве зато эти лишние CAS ой как видны, бо там другие порядки расходов на прикладные вещи.
Я уже давно знаю, что в джаве ты полный ноль, зачем это в очередной раз демонстрируешь?
V>И да, наша реализация изначально умеет работать в режиме multiple producer, что дорого для круговой interlocked-очереди,
lmax disruptor тоже. Ты с докой, очевидно, до сих пор не ознакомился.
V>И да, спин-ожидание у нас тоже присутствует в кач-ве опции (полезно на клиентской стороне) и средняя реакция consumer в сотню-другую наносекунд на появление данных в очереди — тут уже предел современных систем обеспечения когерентности в разных потоках. Кстате, тоже можно producer+consumer посадить на одно ядро, разнеся по гипертредингу, тоже будет максимально быстро.
А что так у вас плохо? У lmax было 50ns афаир, несколько лет назад.
V>А в Джаве можно указать, на каких аппаратных ядрах исполнять тот или иной поток?
Нет, конечно. Это указывается в ОС, а не в ЯП. Или ты хотел узнать, можно ли из джавы позвать соответствующий сискол? Ясен пень, что можно.
V>·>Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy. V>Я уже делал замечание — в случае задействования механизма ожидания на примитиве синхронизации, вся эта система начинает дико тормозить, потому что тормозится Producer, который в этом случае дёргает примитив синхронизации в своём колбэке, вызываемом после помещения элемента в очередь. И там сразу полная ж-па наступает.
Дёргает в смысле notify шлёт? В общем не знаю что там у вас тормозит.
V>Да и вообще, событийная модель на виртуальных вызовах... V>Всё это какое-то одно сплошное нубство.
Твои познания в джаве — полный мрак.
V>>>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor. V>·>Без фиксированной ёмкости у тебя будет проблема с latency. V>Одно косвенное чтение, т.е. примерно плюс 0-8 наносекунд, бо косвенное безусловное чтение зачастую делается процами еще на этапе предвыборки механизмом ОоО. V>И минус многие сотни наносекунд и даже микросекунд на всём остальном, в сравнении с реализацией Disruptor. V>Потому что круговая очередь — это изначально не самая дешевая lock-free структура для передачи данных м/у потоками. V>А еще эта очередь засирает и инвалидирует кеш!
Именно, поэтому и изобрели disruptor.
V>У нас тоже получается де-факто круговая очередь, но она динамическая — растёт в максимуме нагрузки и отдаёт постепенно элементы обратно в память, если не требуются.
Ну так работа с кучей тебе даст длиннющий хвост в латенси.
V>реализация не уступает нейтивной по эффективности.
Что за "у вас"-то такое? Где можно поглядеть на это чудо?
V>·>Доки-то хоть читал? https://lmax-exchange.github.io/disruptor/user-guide/index.html#_alternative_wait_strategies V>И доку читал и исходники внимательно изучал.
Врёшь. Откуда тогда твои пассажи про отсутствие альтернативных стратегий ожидания?
V>[демагогия и распальцовки поскипаны]
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Это первый в мире ноутбук на базе архитектуры RISC-V, который вышел ровно год назад. Правда, выпущено было очень мало экземпляров — всего около 1 000. Причем для покупки требовалось связываться с производителем, уточняя цену и спецификации устройства.
В то же время у компании нет производственных лицензий на CPU, которые в настоящее время находятся в разработке. Это, в том числе, Baikal M2, Baikal L, Baikal S2. Пока что на них имеются лишь проектировочные лицензии.
...
Отказ от ARM в пользу другой архитектуры может оказаться одним из немногих путей решения проблемы, с которой столкнулась «Байкал электроникс». Опрошенные изданием эксперты считают, что снизить зависимость от иностранных компаний поможет выбор в пользу открытых архитектур, в том числе RISC-V, MIPS, VLIW. Но, по их мнению, это потребует значительных, вплоть до 1 млрд руб., денежных вливаний, и двух-трех лет на разработку CPU на базе новой архитектуры.
Альтернативный вариант – это поиск фабрики, которая согласится выпускать ARM-процессоры без производственных лицензий ARM. Но это будет считаться нарушением патентных прав британской компании.
R>Проблемы с производством касаются любых очественных чипов т.к. собственных подходящих фабрик в отечестве нет.
но есть нюанс в виде лицензирования иностранной архитектуры, который всё это ещё несколько усугубляет.
R>Там есть график. Цифр нет.
График из рекламы от производителя/продавца товара — выглядит объективно и непредвзято.
Ну, вот сравнение Эльбруса с Интелом:
Сравнительные тесты процессоров среднего уровня Эльбрус и Intel для задач хранения данных показали примерно равные и одинаково достойные результаты, при этом каждый процессор показал свои интересные особенности.
Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.
При случайной записи небольшими блоками оба процессора показывают равные результаты.
По показателям задержки Эльбрус выглядит значительно лучше Intel-а в потоковой нагрузке, т.е. в последовательном чтении и записи большими блоками.
Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Отличный Эльбрус же, а тебе что-то не нравится
R>Не-не-не. Ты перевираешь мои слова. Если смотреть бенчи, то эльбрус сливает не топам, а процам десятилетней давности.
Внимание: тестируется инженерный процессор с частично отключенным кешем, у серийного образца результаты должны быть лучше.
...
ВНИМАНИЕ: Сборка тестов производилась с подбором флагов оптимизации и использования профилировщика и на результаты влияет версия компилятора (я являюсь энтузиастом и собирал код своими силами и, надеюсь, МЦСТ смогут собрать более правильно).
R>Я этого не говорил, не ври.
Ну, ты тут пишешь, что в архитектуре Эльбрус есть проблемы, которые не решаются. При этом предлагаешь RISC-V, якобы лишённую этих проблем.
Так процессоры на RISC-V круче Эльбрусов или убогие Эльбрусы вдруг их уделывают и тогда не понятно зачем от них отказываться и бросаться скорее RISC-V всем осваивать?
R>Ну вот же: https://servernews.ru/1095656 слова есть, график есть. Тебе абсолютные цифры нужны? Их нет.
В глаза бросаются несколько центральных графиков, где удаётся получить более чем двукратный прирост по сравнению с GeForce RTX 4090. Вот только если обратить внимание на данные ниже, то можно убедиться в том, что речь идёт не о чистой производительности.
...
Очевидно, что руководство NVIDIA прекрасно осознаёт проблему, поэтому сделало всё, чтобы пустить геймерам пыль в глаза. Так, особый упор был сделан на технологию масштабирования. Ещё совсем недавно DLSS считалась приятным дополнением, позволяющим продлить жизненный цикл видеокарт, ну а сегодня она всё активнее берёт на себя роль основного двигателя прогресса.
Где относительно независимые бенчмарки от энтузиастов, которые купили в магазине один из множества компьютеров на RISC-V и сравнили с какими-то аналогами на x86 и/или ARM?
Даже по маргинальным Эльбрусам такое есть.
Здравствуйте, karbofos42, Вы писали:
k> R>У бизнеса есть потребность в отечественных камнях, им государство так постановило.
k> Так оказывается российский бизнес на паузе, т.к. с отечественными процессорами беда?
Ну как на паузе... Я же тебе ссылку дал, где написано о серверах на байкале. Свежая ссылка же
k> R>https://habr.com/ru/companies/ru_mts/articles/821921/
k> Ни одного знакомого названия, да и:
k> Это первый в мире ноутбук на базе архитектуры RISC-V, который вышел ровно год назад. Правда, выпущено было очень мало экземпляров — всего около 1 000. Причем для покупки требовалось связываться с производителем, уточняя цену и спецификации устройства.
Ну вот, а ты говорил на бумаге...
k> удивляет почему столь массовые и популярные модели не завезли в ДНС. k> А всякие ASUS, Lenovo, Acer,... решили отказаться от огромной доли рынка ноутбуков и отдали RISC-V каким-то ноунеймам?
Baikal-S, 2021.
k> В то же время у компании нет производственных лицензий на CPU, которые в настоящее время находятся в разработке. Это, в том числе, Baikal M2, Baikal L, Baikal S2. Пока что на них имеются лишь проектировочные лицензии.
Новая партия Baikal-S обещается в конце этого года.
k> R>Проблемы с производством касаются любых очественных чипов т.к. собственных подходящих фабрик в отечестве нет.
k> но есть нюанс в виде лицензирования иностранной архитектуры, который всё это ещё несколько усугубляет.
Вот, в том числе и поэтому риск-пять и зарулит все прочее (там, где задумываются о разработке своих камней).
k> График из рекламы от производителя/продавца товара — выглядит объективно и непредвзято.
Лживые ублюдки! Но, других графиков у меня для вас нет
k> Ну, вот сравнение Эльбруса с Интелом: k> ... k> Отличный Эльбрус же, а тебе что-то не нравится
Все бы по СХД процами меряться
k> R>Не-не-не. Ты перевираешь мои слова. Если смотреть бенчи, то эльбрус сливает не топам, а процам десятилетней давности.
k> Внимание: тестируется инженерный процессор с частично отключенным кешем, у серийного образца результаты должны быть лучше. k> ... k> ВНИМАНИЕ: Сборка тестов производилась с подбором флагов оптимизации и использования профилировщика и на результаты влияет версия компилятора (я являюсь энтузиастом и собирал код своими силами и, надеюсь, МЦСТ смогут собрать более правильно).
Ну так собрали и показали более правильно, на не инженерном? Покажешь? (видишь, я тоже так умею).
k> R>Я этого не говорил, не ври.
k> Ну, ты тут пишешь, что в архитектуре Эльбрус есть проблемы, которые не решаются. При этом предлагаешь RISC-V, якобы лишённую этих проблем.
Все, что я сказал о риск-пять, это сослался на слова Шигорина о том, что там с исполнением "скриптов" все очень хорошо. У эльбруса не хорошо. Вот и все.
k> Так процессоры на RISC-V круче Эльбрусов или убогие Эльбрусы вдруг их уделывают и тогда не понятно зачем от них отказываться и бросаться скорее RISC-V всем осваивать?
Уверен, что будущее (и российское в том числе) за риск-пять (европа и китай уже сделали ставку на эту архитектуру. нет, пруфов не будет. в гугле все есть), а эльбрусы, либо останутся в узкой нише военного применения (если вояки совсем ку-ку), либо радикально изменят архитектуру и у них что-то получится, либо будут никому не нужны.
k> R>Ну вот же: https://servernews.ru/1095656 слова есть, график есть. Тебе абсолютные цифры нужны? Их нет.
k> Где относительно независимые бенчмарки от энтузиастов, которые купили в магазине один из множества компьютеров на RISC-V и сравнили с какими-то аналогами на x86 и/или ARM? k> Даже по маргинальным Эльбрусам такое есть.
Риск-пять в начале пути. Каких бенчмарков из бытового сегмента ты ждешь
Здравствуйте, rudzuk, Вы писали:
R>Ну как на паузе... Я же тебе ссылку дал, где написано о серверах на байкале. Свежая ссылка же
Целых 350 материнок собрали на процессорах из 2021 года, а серверы пока только оформляют как отечественные.
Звучит как массовое производство, закрывающее потребности отечественного бизнеса.
R>Аппетит приходит во время еды? Понимаю
Нет. Это показатель того, что в ближайшие годы архитектура конечным пользователям не интересна.
Спрос отсутствует, крупные производители не парятся.
R>Baikal-S, 2021.
Уже 4 года процессору, а новые модели на ARM им производить нельзя. Выглядит перспективно, нужно больше в ARM вкладываться, а не в убогий VLIW, который всё ещё можно развивать.
R>Новая партия Baikal-S обещается в конце этого года.
Партия старой модели, производство новой никто и не обещает.
R>Вот, в том числе и поэтому риск-пять и зарулит все прочее (там, где задумываются о разработке своих камней).
Может быть, когда-нибудь, но это не точно.
R>Лживые ублюдки! Но, других графиков у меня для вас нет
R>Все бы по СХД процами меряться
Хорошо, что про RISC-V ты не переживаешь по поводу правдивости и объективности графиков, веришь на слово.
R>Уверен, что будущее (и российское в том числе) за риск-пять (европа и китай уже сделали ставку на эту архитектуру. нет, пруфов не будет. в гугле все есть), а эльбрусы, либо останутся в узкой нише военного применения (если вояки совсем ку-ку), либо радикально изменят архитектуру и у них что-то получится, либо будут никому не нужны.
Главное — верить.
R>Риск-пять в начале пути. Каких бенчмарков из бытового сегмента ты ждешь
Ты же меня тут сам убеждаешь, что ноутбуки производятся и процессоры не только на бумаге существуют.
По Эльбрусам вот бенчмарки есть, но тебе сразу позитивные бенчи не такие и всё там не так.
Как RISC-V — картинок хватает, отличная архитектура просто потому что кто-то там занимается и красивые обещания даёт.
K>Как RISC-V — картинок хватает, отличная архитектура просто потому что кто-то там занимается и красивые обещания даёт.
ну я хоть и за то, чтобы Эльбрус развивать, думаю что с RISC-V всё будет зашибись. Это будет точка приложения усилий большей части индустрии, как PC когда-то, и как PC победил всякие интересные компы несмотря на свои недостатки, так и RISC-V победит и все будут страдать, что уж в этот раз можно было сделать по уму и как он такой несовершенный вообще победил
Здравствуйте, koenig, Вы писали:
K>ну я хоть и за то, чтобы Эльбрус развивать, думаю что с RISC-V всё будет зашибись. Это будет точка приложения усилий большей части индустрии, как PC когда-то, и как PC победил всякие интересные компы несмотря на свои недостатки, так и RISC-V победит и все будут страдать, что уж в этот раз можно было сделать по уму и как он такой несовершенный вообще победил
Сильно зависит от политики. Как доступ к платному ARM прикрыли из-за политики, так и к "открытой" архитектуре могут завтра закрыть дорогу тем же китайским учёным.
Ну, а Китай без возможности влиять на развитие RISC-V будет пилить свой форк RISC-X. Первое время конечно они будут на 99.9% похожи, но потенциально всё же не будет одной точки приложения усилий.
У нас уже СССР поступил "мудро", похоронил все свои наработки и ушёл в копирование западных чипов.
Этим и тот же Intel популяризировали и своё ничего не развивали.
Против RISC-V ничего не имею, но не считаю, что это некая "серебряная пуля" и не нужно ничего своего делать.
Эльбрусы уже есть, как-то там работают — значит можно это поддерживать и дальше развивать.
Кто сейчас RISC-V занимается и в итоге выдаст годный результат — пусть тоже заходят на огонёк, там уже можно выбирать что лучше.
Когда будут существовать и Эльбрусы и RISC-V и ещё что-то может быть — там уже можно сливать аутсайдеров или разводить по разным углам где что будет лучше применимо.
А вот эти истории, когда существующее задвигают и начинаются рассказы про новые будущие прорывы — это пока приводит к тому, что нет ни плохо VLIW, ни хорошего RISC.
Разработчики из компании Red Hat объявили о реализации начальной поддержки архитектуры RISC-V в репозитории CentOS Stream 10, выступающем основой для разработки Red Hat Enterprise Linux 10. До этого пакеты выпускались для архитектур x86_64 (x86_64_v3 в RHEL 10), Aarch64, ppc64le (POWER9) и s390x (IBM z14). Red Hat также представил экспериментальные сборки RHEL 10 для систем RISC-V, развиваемые совместно с компанией SiFive.
Архитектура RISC-V получила статус альтернативно поддерживаемой и в отличие от первичных архитектур (x86_64, Aarch64, ppc64le и s390x) не будет блокировать выпуск релизов для других архитектур. Наличие специфичных для RISC-V проблем в пакетах не будет останавливать публикацию сборок этих пакетов для других архитектур.
При работе на плате VisionFive 2 и в QEMU будет задействовано штатное ядро из состава RHEL 10, а при работе на платах серии SiFive HiFive Premier P550 отдельное ядро от производителя оборудования. Разработка сборки ведётся в сотрудничестве с проектом Fedora. Время релиза Rocky Linux 10 пока не сообщается.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
V>>·>Disruptor в первую очередь разрабатывался для системы трейдинга. V>>Так ты не меня поправляй, а Синклера, который спорил с тезисом о необходимости эффективного обмена данными м/у потоками, при этом сами же привёл пример подсистемы, спроектированной именно для такого обмена. Это вышло вдвойне забавно, бо и без этого его позиция улыбала донельзя. )) ·>Он не с этим спорил.
ДА ты задолбал уже этой убогостью...
Или говоришь предметно, раскрывая свою мысль тезисно, или идёшь менять себе памперсы.
Здравствуйте, vdimas, Вы писали:
V>ДА ты задолбал уже этой убогостью... V>Или говоришь предметно, раскрывая свою мысль тезисно, или идёшь менять себе памперсы.
Я спорил с тезисом о том, что ускорение межпоточного обмена информацией требует "размечать память вручную".
Прикладному программисту, который хочет эффективно перекидывать свои объекты между потоками при помощи LMAX Disruptor или аналогичной структуры, совершенно не нужно ни о чём таком заботиться.
Ему было бы нужно это делать, если бы он самостоятельно пытался пилить класс "торговая заявка" со встроенной "потокобезопасностью". Но зачем? Меняем архитектуру, и на выравнивание данных внутри объекта становится наплевать.
Более того — в самом LMAX Disruptor нет никаких следов ручной разметки памяти.
Вы, как обычно, за деревьями не видите леса. Чёрт с ним, что вы не сумели прочитать от LMAX Disruptor ни доку, ни исходники — это же мелочи. Общая-то картинка должна была сложиться, по крайней мере у профессионала.
Вместо обсуждения чего-то полезного вы опять начинаете метать чушь про single-producer и про то, что ваша мифическая скоростная реализация сильно быстрее дисруптора потому, что там внутре сделана ручная разметка.
Поскольку кодом вы свои заявления подкрепить не можете, сядьте и дышите в свой памперс. Можете предварительно его сменить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, novitk, Вы писали:
N>Ты не понимаешь смысл PGO. Там вся фишка, что оно работает с продакшен данными и таймингами.
Дык, я именно что не вижу проблем эмуляции таймингов, тем более, что приличную часть карьеры отлаживал проги именно на эмуляторах процов именно с потактовыми таймингами происходящего.
Здравствуйте, Sinclair, Вы писали:
V>>Или говоришь предметно, раскрывая свою мысль тезисно, или идёшь менять себе памперсы. S>Я спорил с тезисом о том, что ускорение межпоточного обмена информацией требует "размечать память вручную".
Ты ставил вопрос о вообще необходимости этого обмена.
А что разнесение данных по линейкам кеша позволяет этот обмен ускорить порой на порядок — это хорошо известно уже давно, тут не я первоисточник — для меня это точно так же когда-то в нулевых было открытием на многоядерных процах, я лишь потратил несколько раз время на тщательную проверку этих эффектов.
S>Более того — в самом LMAX Disruptor нет никаких следов ручной разметки памяти.
Что говорит о том, что ты не вникал в исходники.
Мне вообще иногда кажется, что исходники коллег или исходники обсуждаемых неких открытых вещей на этом сайте читаю только я. ))
В Disruptor операции просто над буфером байт, т.е. вся типизация происходит "в уме" — просто по смещениям читают и пишут данные как в ассемблере, когда пишут и читают в сырую нетипизированную память.
Ну и плюс круговая очередь, с её хорошо известными недостатками — оно принципиально живёт лишь при небольшом размере кругового буфера, иначе постоянно инвалидируется кеш данных и тормозит уже вся система в целом, не только целевой алгоритм.
В общем, максимальная пропускная способность Disruptor достигается, когда курсор чтения заметно отстаёт от курсора записи, т.е. при наихудшей задержке.
Такие системы неплохо себя показывают в узких диапазонах нагрузок.
Как только нагрузка динамически скачет, в т.ч. при разделённой обработке данных "нагрузкой" в том числе считаются задержки в прикладных колбэках — система резко впадает в ступор, потом что Distruptor не может писать в очередь, он начинает вечно сидеть в CAS-цикле, замораживая колбэк в потоке Producer, т.е. в этом сценарии LMAX начинает терять входящие UDP-пакеты.
Это именно та причина, по которой использование очередей небольшого фиксированного размера не рекомендуется в этой предметной области.
Поэтому, да, приходится ломать голову в поисках альтернативных решений.
За счёт лишней косвенности на каждый инфраструктурный "вагончик" нашей реализации удалось решить кучу вещей:
— динамический размер очереди;
— избегание инвалидирования кеша — каждый раз берутся последние использованные "вагончики", т.е. наиболее "разогретые" участки памяти.
Учитывая, что во всём остальном косвенность при агрегировании объектов из их составных частей примерно на порядок меньше, чем в Джаве, это относительно дешевый размен.
Плюс, хорошо еще работает предвыделение "вагончиков" в их пулы свободных объектов, т.е. заведомое их последовательное расположение в более крупных кластерах памяти, которыми оперируют кеши более высоких уровней. Тот же эффект достигается в круговой очереди автоматически — это единственный её плюс. ))
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, alpha21264, Вы писали:
a>> a>> На технологии посмотри!
a>> R>У 32с 7 нм, у M4 3 нм (так у него и тфлопсов больше в полтора раза). У M1 5 нм и он практически равен по tflops 32c. Причем, тфлопсы 32c они планируемые.
a>> Скажи понятно, что ты имеешь в виду.
R>Что из сказанного не понятно?
Всё. Все междуметия. И весь контекст.
И ещё, у меня впечатление, что ты не знаешь, что технология — это не только нанометры.
Я подозреваю, что для процессора Эппл М4 производилось топологическое проектирование со всеми его оптимизациями,
а для Эльбруса просто отдали на фабрику verilog.
A>Я подозреваю, что для процессора Эппл М4 производилось топологическое проектирование со всеми его оптимизациями,
завод же чужой? так вообще для чужих заводов делают? наверняка бы мы узнали, т.к. это нефиговый обмен информацией между компаниями, не может он бесследно для сторонних наблюдателей пройти
Здравствуйте, koenig, Вы писали:
A>>Я подозреваю, что для процессора Эппл М4 производилось топологическое проектирование со всеми его оптимизациями,
K>завод же чужой? так вообще для чужих заводов делают? наверняка бы мы узнали, т.к. это нефиговый обмен информацией между компаниями, не может он бесследно для сторонних наблюдателей пройти
Ну в зависимости от отношений между копаниями производитель может делиться информацией о слоях.
И там довольно широкий диапазон, начиная от того, что просто дают ограничения типа
"в таком-то слое расстояние между проводниками должно быть не менее чем..."
и до полной информации о толщинах, материалах и диэлектрической проницаемости.
Разумеется всё это под НДА.
Здравствуйте, alpha21264, Вы писали:
A>Всё. Все междуметия. И весь контекст. A>И ещё, у меня впечатление, что ты не знаешь, что технология — это не только нанометры. A>Я подозреваю, что для процессора Эппл М4 производилось топологическое проектирование со всеми его оптимизациями, A>а для Эльбруса просто отдали на фабрику verilog.
Очень вряд ли. Я от темы далёк, но насколько я знаю, ФАБы не принимают "просто верилог". Именно поэтому идеи "нам отказали TSMC, давайте просто перезакажем на SMIC", будучи красивыми в теории, на практике труднореализуемы.
Насколько я знаю, всё же разработчик чипа получает от фабрики спецификации линий, и делает топологическое проектирование сам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>Я спорил с тезисом о том, что ускорение межпоточного обмена информацией требует "размечать память вручную". V>Ты ставил вопрос о вообще необходимости этого обмена.
Это пять! В следующий раз когда мне понадобится форумный телепат, который лучше меня знает о чём я говорю, я знаю к кому обратиться.
S>>Более того — в самом LMAX Disruptor нет никаких следов ручной разметки памяти. V>Что говорит о том, что ты не вникал в исходники. V>Мне вообще иногда кажется, что исходники коллег или исходники обсуждаемых неких открытых вещей на этом сайте читаю только я. )) V>В Disruptor операции просто над буфером байт, т.е. вся типизация происходит "в уме" — просто по смещениям читают и пишут данные как в ассемблере, когда пишут и читают в сырую нетипизированную память.
Надеюсь тебя не затруднит привести конкретную строчку где есть "операции просто над буфером байт"? Вот тут исходники, если ты их ещё не видел: https://github.com/LMAX-Exchange/disruptor/tree/master/src/main/java
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
