Multicore OCaml таки вмержат в апстрим

Я сам давал линк на разраба раста, который описывал, почему компилятор уже никогда не ускорится значительно. Там было про требования глобальной согласованности трейтов и еще какие-то тезисы. Могу поискать, если интересно.

Ты перескочил от проблемы «раст не умеет в 10000 ядер искаропки» до «раст медленно компилирует».

Архитектуру же языка переделывать в плане упрощения кодописания и поддержки многозадачности уже никто не будет, поскольку это будет совершенно другой язык.

Да, ты сам ответил на свой вопрос. Никто не будет, потому что никому не нужно кроме тебя ничего свыше того что есть.

И ты повторяешь ту же проблему, только в профиль: сотни окружений с дублями библиотек.

Ииии? Один проект – одно окружение. Что не так в этом подходе? Если тебя беспокоит место на диске, есть ФС с дедупликацией.

Давно понял, потому свой код компилирую только с «-fno-strict-aliasing». Это одна из самых бессмысленных и беспощадных фич GCC.

Ну то есть, твой код уже не на стандартном C/C++. Тащемта, это ещё одна проблема почему эти языки надо выкинуть: их стандарты не применимы, а компиляторы их местами неточно или по-разному реализуют.

Да понял я, что ты предлагаешь сделать из раста питон.

Нет, питон я не предлагаю никому, потому что питон – адова всрань.

Но если ты предлагаешь низкий уровень делать тоже в расте, то ты неизбежно приходишь к unsafe.

Ещё раз: внутри unsafe {}, если ты не говнокодер, в итоге оказывается минимум хорошо отлаженного кода с вменяемым API снаружи, а не вообще весь код проекта. Я правда не понимаю, почему это так сложно понять.

по востребованности сравнимо со скалой

Ну да, также ниже шума.

А на двух сокетах 128 ядер ты можешь иметь уже сейчас. Или 256 ядер на четырёх сокетах. Системы с сотнями ядер на x86 – уже давно не новость ни для кого

Да, 256 — это и есть потолок. Было и на 8 сокетах, и аналогичное на четырех — но почему-то не хотят делать 512 на восьми сокетах. Вероятно, они знают что-то такое, что также знаю я. Например, что когерентный кэш с Total Store Ordering (TSO) на 512 ядрах будет работать с производительностью, подозрительно близкой к 256-ядреному серверу. Даже 256 ядер задействовать не так-то легко — для чего еще, кроме SAP и VMware они реально применяются? То есть, систем, состоящих по большей части из независимых процессов, которые при этом почему-то нужно обязательно засунуть в единственный сервер.

Netflix недавно выкладывал результаты внедрения серверов на ARM у них. На AWS ты можешь уже сейчас ARM арендовать. Только ты про это всё не в теме

А я тебе про что пишу? Уже более одного производителя делает ARM-ы для серверов, но простой народ это всё не колышет. «Можешь арендовать» не значит, что все рванулись свой x86-only софт портировать на ARM. Без TSO когерентный кэш ARM выдержит в несколько раз выше нагрузку, но и он ляжет ближе к тысячи.

Ты перескочил от проблемы «раст не умеет в 10000 ядер искаропки» до «раст медленно компилирует»

Ну давай поговорим о том, что тебя беспокоит, я ж не против. Раст не умеет в 10000 ядер, да, дальше что? Rust не умеет и в распределенные вычисления на больших кластерах. Столкнется ли средний «новичок» с вычислениями на более чем одной машине? Вряд ли. Ну так пусть пишет на C#.

Никто не будет, потому что никому не нужно кроме тебя ничего свыше того что есть

Ты подменяешь «никто не может родить ничего лучше» на «никому не нужно». Точно так же в штатах «никому не нужна» метрическая система, хотя на самом деле инертный бизнес просто не может потратить две копейки на переучивание персонала. Точно так же никто лишней копейки не отдаст на создание современного ЯП — вот тебе раст, и жри что дают.

Да, 256 — это и есть потолок.

А пруфы будут?

но почему-то не хотят делать 512 на восьми сокетах

Кто тебе сказал что не хотят?

То есть, систем, состоящих по большей части из независимых процессов, которые при этом почему-то нужно обязательно засунуть в единственный сервер.

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

А я тебе про что пишу?

Я, честно говоря, с большим трудом понимаю что ты пишешь. Ты хоть и не такой гений словесности, как Шомочка, но понять тебя иногда тоже сложно.

«Можешь арендовать» не значит, что все рванулись свой x86-only софт портировать на ARM.

Возможно, просто всем насрать на ARM. Ты не думал? Хотя как только Apple выпустил макбуки на ARM, все внезапно спортировали свой софт довольно таки быстро.

И ты повторяешь ту же проблему, только в профиль: сотни окружений с дублями библиотек

Ииии? Один проект – одно окружение. Что не так в этом подходе? Если тебя беспокоит место на диске, есть ФС с дедупликацией

Ну и зачем тебе пакетный менеджер? Чтобы один раз развернуть окружение? Из другого проекта ты часть библиотек вытащить все равно не сможешь, потому что там другие версии базовых либ.

Ну то есть, твой код уже не на стандартном C/C++. Тащемта, это ещё одна проблема почему эти языки надо выкинуть: их стандарты не применимы, а компиляторы их местами неточно или по-разному реализуют

Да, потому что стандартный C/C++ сам по себе — это полная херота, которую в полном объеме реализовали только вахтеры из GCC, достигнув глубин абсурда в этом своем стремлении, вроде вываливания выполнения за границу функции. Ну типа я не виноват в том, что комитет снял с себя ответственность за содержание стандарта, описав его максимально абстрактно и двусмысленно.

Нет, питон я не предлагаю никому, потому что питон – адова всрань

А что предлагаешь? Julia? Swift?

Ещё раз: внутри unsafe {}, если ты не говнокодер, в итоге оказывается минимум хорошо отлаженного кода с вменяемым API снаружи, а не вообще весь код проекта. Я правда не понимаю, почему это так сложно понять

Так работает весь питон. Сишная база, которая дергается из питоньего клея. Я ж не спорю, что такой подход работает. Моя претензия к тому, что это два разных языка, и с таким же успехом в раст можно инлайнить сишный код.

Да, 256 — это и есть потолок.

А пруфы будут?

Я делаю этот эмпирический вывод на базе разных попыток разных людей завести многопоточные вычисления на большом числе ядер. Как правило, почти всё ложится ближе к сотни, даже специально спроектированные под многоядра алгоритмы. Даже просто одна сраная маленькая ячеечка с блокировкой, к которой изредка обращаются рабочие потоки — тот 0.1% времени, которые тратился одним потоком, внезапно превращается в 90% времени ожидания сотней потоков, а не 10%, как наивному программисту может показаться, поскольку линейное масштабирование — это светлая, но недостижимая мечта. И по итогу твои сто потоков работают как десять. Да куда там, десять потоков побыстрее работать будут, чем сто — это и есть основное препятствие для наращивания параллелизма: потоков становится больше, а производительность при этом почему-то падает. Ты не замечал, что для для большинства серверных софтин советуют ставить число рабочих потоков равным или меньшим, чем число ядер процессора?

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

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

Стоимость таких серверов настолько запредельная, что я сомневаюсь, что их владельца колышет цена места в стойке.

А я тебе про что пишу?

Я, честно говоря, с большим трудом понимаю что ты пишешь. Ты хоть и не такой гений словесности, как Шомочка, но понять тебя иногда тоже сложно

Я тебе пишу о том, что бизнесов с серверами на ARM можно по пальцам пересчитать:

https://omdia.tech.informa.com/blogs/2021/a-historic-data-center-quarter-with...

4% серверов на ARM. Ты упомянул один Netflix — а Google и Facebook тем временем сидят на x86. И 95% рынка сидит на x86.

Возможно, просто всем насрать на ARM. Ты не думал? Хотя как только Apple выпустил макбуки на ARM, все внезапно спортировали свой софт довольно таки быстро

В два раза дешевле процессоры и их энергопотребление, не? Никому не нужно? Индустрия не развивается — что и требовалось доказать.

Я делаю этот эмпирический вывод на базе разных попыток разных людей завести многопоточные вычисления на большом числе ядер. Как правило, почти всё ложится ближе к сотни, даже специально спроектированные под многоядра алгоритмы.

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

Ну да, пока что так и есть. А почему это проблема-то?

В два раза дешевле процессоры и их энергопотребление, не? Никому не нужно? Индустрия не развивается — что и требовалось доказать.

В расчёте количества вычислений на единицу мощности? И при этом имеющий сотню ядер? Серьёзно? Где такой серверный ARM-чип есть в достаточных количествах? Я хочу посмотреть.

Таким образом, если мы пишем «высокопроизводительный» софт, то это либо GPGPU, либо FPGA, либо ASIC

Я краем уха слышал про «high frequency trading на java». Врут?

как задействовать тысячу ядер из процессора

Завязывал бы ты с демагогией. Ядра бывают разные. Я бы не стал сравнивать CPU и GPU ядра хотя бы потому что первые работают независимо друг от друга, а вторые молотя дружно одно и то же.

нет языков программирования, которые позволяли бы управлять тысячей независимых потоков

Ты бредишь. В 2008 году скручивали размер стека потока для демонов, чтобы внутри процессам могло 1500 тредов работать. Правильная формулировка проблемы: не все задачи допускают параллелизацию.

Современные массово использумые подходы к разработке

Че-то у меня это словосочетание ассоциируется с js-лапшой, которая насилет браузер со страшной силой без какой-либо пользы.

Даже специально разработанные под это дело Erlang и Go вряд ли вывезут тысячи потоков

А это смотря как писать будешь. Если по старинке с мьютексами и condvars — да, упрешься в синхронизацию. А если преобразуешь свой алгоритм в обмен сообщениями, может весьма годно получиться. Но читать такое, конечно будет очень тяжело.

Что дает раст в этой нише?

99.(9)% сегодняшних задач сводятся в конечном итоге к синхронизации между потоками. Rust сделает так, что некоторое подмножество некорректного кода не будет компилироваться. Как по мне, это вин: снижение затрат на разработку и тестирование.

arm

swift

А, понятно, ты из этих, из любителей техники с логотипом надкусанного фрукта. Это многое объясняет.

x86 не может масштабироваться на сотни ядер

Если не требовать наличия этих сотен ядер на одном кристалле, то это уже давным-давно реальность, см. «SMP cluster»

Вот например: https://www.fujitsu.com/global/about/resources/news/press-releases/2011/Fujitsu-Delivers-HPC-Price-Performance-Breakthrough-with.html

десять лет ждал

В реальных применениях эти 256 ядер больше похожи на сеть из четырех серверов, которые оборудованы особо быстродействующим сетевым соединением и аппаратным ускорением когерентности кэшей

Ну да, пока что так и есть. А почему это проблема-то?

Вся проблема в том, как организовать параллельное выполнение. Прикольно иметь полностью независимые задачи, но проблема организации в таком случае просто переносится на уровень выше. Как только ты начинаешь использовать аппаратные возможности (общую память) для взаимодействия, то прощаешься с производительностью и параллелизуемостью.

В расчёте количества вычислений на единицу мощности? И при этом имеющий сотню ядер? Серьёзно? Где такой серверный ARM-чип есть в достаточных количествах? Я хочу посмотреть

https://blog.cloudflare.com/arm-takes-wing/ — Смотри, Qualcomm Centriq. Прощу обратить особое внимание на самый последний график, где авторы замерили реально потребление мощности, и выяснилось, что на полной нагрузке ARM потребляет 60% своего TDP, в то время, как Intel потребляет 95% TDP. То есть, на самом деле в x86 производительность режется по мощности — иначе бы они с радостью потребляли все 150% заявленного TDP.

И по итогу получается соотношение x2.11-2.8 энергоэффективности по nginx. Да, там разные техпроцессы — хорошо, ладно, пусть будет двухкратная разница, погоды это не делает, все равно ARM серьезно укатывает x86 по энергоэффективности. А ты думаешь почему Amazon продает хостинг на ARM в два раза дешевле?

Я краем уха слышал про «high frequency trading на java». Врут?

Что за хай фриквенси? 100 млн транзакций в секунду? 10 млн? Если нет, то это не высокопроизводительный софт.

Завязывал бы ты с демагогией. Ядра бывают разные. Я бы не стал сравнивать CPU и GPU ядра хотя бы потому что первые работают независимо друг от друга, а вторые молотя дружно одно и то же

Ты прав, я ж не спорю. Хоть в видюхе выполняемые инструкции и одинаковые сразу для нескольких шейдерных ядер, тем не менее, условное выполнение и косвенная адресация может происходить независимо в одном цикле для каждого шейдера. Хотя, при косвенной адресации есть шанс вылететь из кэша.

В 2008 году скручивали размер стека потока для демонов, чтобы внутри процессам могло 1500 тредов работать. Правильная формулировка проблемы: не все задачи допускают параллелизацию

Эти демоны 99% времени ничего не делают. Я подозреваю, что кому-то нужен был такой костыль для обхода дебильной архитектуры некой софтины, которая не умела в асинхронность (как и весь старый никсовый софт).

Че-то у меня это словосочетание ассоциируется с js-лапшой, которая насилет браузер со страшной силой без какой-либо пользы

И это тоже. Поскольку хром не может толком задействовать ядра процессора под логику, то в потоках крутится сборка мусора, которая предельно тупа и предсказуема.

Если по старинке с мьютексами и condvars — да, упрешься в синхронизацию. А если преобразуешь свой алгоритм в обмен сообщениями, может весьма годно получиться. Но читать такое, конечно будет очень тяжело

Во-о-от, ты затронул настоящую проблему. И эту реальную проблему Rust не решает вообще никак. А ты пишешь реально работающие многозадачные системы?

99.(9)% сегодняшних задач сводятся в конечном итоге к синхронизации между потоками

99% сегодняшних задач сводятся к выполнению в одном потоке вообще без синхронизации. Особенно это касается PHP, JS, Python.

Если не требовать наличия этих сотен ядер на одном кристалле, то это уже давным-давно реальность, см. «SMP cluster»
Вот например: https://www.fujitsu.com/global/about/resources/news/press-releases/2011/Fujit...

InfiniBand же ж — высокопроизводительная сеть. Да, там есть фичи RDMA из коробки, но то же самое можно сделать, например, через Open MPI и обучную сеть. Да, работать через Ethernet это будет медленнее.

авторы замерили реально потребление мощности, и выяснилось, что на полной нагрузке ARM потребляет 60% своего TDP

Т.е. они 40% мощности на столе оставили? Молодцы, так держать!

То есть, на самом деле в x86 производительность режется по мощности — иначе бы они с радостью потребляли все 150% заявленного TDP.

Мне просто интересно, ты вот допрёшь до того, какая хрень в этой цитате написана или нет? Потребляемая мощность зависит в том числе от частоты процессора и напряжения. Их можно задать вообще любые, лишь бы VRM вытянул и кремний не поплавился. Оверклокеры гарантируют. Те же тредрипперы до киловатта разгоняли, при TDP в 300W.

InfiniBand же ж — высокопроизводительная сеть. Да, там есть фичи RDMA из коробки, но то же самое можно сделать, например, через Open MPI и обучную сеть. Да, работать через Ethernet это будет медленнее.

Чувак анонс из 2011 года приплёл. Сейчас можно кластер прямо на PCIe построить. Даже свитчи есть под это дело.

Т.е. они 40% мощности на столе оставили? Молодцы, так держать

Требование повышения частоты приводит к повышению процента брака (часть чипов не вытягивают такую частоту), а значит к повышению стоимости процессора. При той же производительности Qualcomm Centriq стоят примерно в 2-3 раза дешевле аналогичных по производительности Intel Xeon. К слову о том, почему Amazon продает хостинг на ARM в 2 раза дешевле, чем на x86.

Мне просто интересно, ты вот допрёшь до того, какая хрень в этой цитате написана или нет? Потребляемая мощность зависит в том числе от частоты процессора и напряжения. Их можно задать вообще любые, лишь бы VRM вытянул и кремний не поплавился. Оверклокеры гарантируют. Те же тредрипперы до киловатта разгоняли, при TDP в 300W

У процессора есть конкретная максимальная производительность при конкретной потребляемой мощности. При увеличении напряжения на ядре мощность растет квадратично, предельная частота, грубо говоря, растет линейно, а производительность растет менее чем линейно (потому что зависит и от других компонентов). Потому тредриперы с порезанной мощность, как ни странно, выдают хорошие показатели энергоэффективности по сравнению с работающими на полную ярость малоядерными x86. И даже несмотря на это обрезание мощности тредрипперы уделываются почти любым армом последних лет.

При увеличении напряжения на ядре мощность растет квадратично

Нет. Она растёт при увеличении частоты, что требует увеличить напряжение. Тут не прямая связь.

При той же производительности Qualcomm Centriq стоят примерно в 2-3 раза дешевле аналогичных по производительности Intel Xeon.

Удивительно, но и десктопные Ryzen уделывают Xeon по цене при аналогичной производительности. Мне кажется, дело тут не в этом слегка.

И даже несмотря на это обрезание мощности тредрипперы уделываются почти любым армом последних лет.

Или не уделываются.

Чувак анонс из 2011 года приплёл. Сейчас можно кластер прямо на PCIe построить. Даже свитчи есть под это дело

Да ради бога, на чем хочешь строй — проблемы координации это никак не решает.

Нет. Она растёт при увеличении частоты, что требует увеличить напряжение. Тут не прямая связь

А, ну да, итого примерно куб, если брать частоту и напряжение. Короче говоря, повышение энергопотребления — это очень хреновый способ повышения производительности.

Удивительно, но и десктопные Ryzen уделывают Xeon по цене при аналогичной производительности. Мне кажется, дело тут не в этом слегка

Амуда применяет чиплеты в сравнимых Threadripper-ах. А иначе только многосокетовая система. У AMD аналогов топовых Xeon нет в производстве вообще никаких. Centriq же — это один цельный чип на 48 ядер. Если ты посмотришь на зионы с большим числом ядер, то увидишь, что стоимость их растет примерно квадратично по отношению к числу ядер, то есть, при переходе от 8 ядер к 12 ядер стоимость удваивается. Чиплетные же тредрипперы обеспечивают линейный рост стоимости. Так ли «бесплатно» это деление на чиплеты? Не думаю.

И я сейчас говорю не про «чей папка круче», а про преимущества технологии ARM. И они примерно двухкратные.

И даже несмотря на это обрезание мощности тредрипперы уделываются почти любым армом последних лет.

Или не уделываются

https://browser.geekbench.com/v5/cpu/5434681 — мак на Apple M1
https://browser.geekbench.com/v5/cpu/5367591 — мак на AMD Ryzen 7 5800X

Примерно равная производительность, потребление порядка 15-20 Вт у Apple M1 против рузена на 105 Вт. MSRP $500 у рузена. К сожалению, Apple не продает свои процессоры, но заявленная себестоимость — $40-50, а цена самого дешевего Mac Mini на M1 — $700, и кристалл M1 120 mm² против 200 мм² в сумме у рузена. Может и не в два раза по стоимости, а только в полтора, но по энергоэффективности ARM разрывает рузены в клочья. Все-таки энергоэффективность у зионов повыше будет.

К слову о тысячеядерном ARM:

https://en.wikipedia.org/wiki/Adapteva#Epiphany_V

почему компилятор уже никогда не ускорится значительно. Там было про требования глобальной согласованности трейтов и еще какие-то тезисы

Нет. «Компилятор» (а на самом деле фронт к LLVM) никогда не ускорится значительно, потому что он (фронт) крайне примитивен, и делает куда меньше вещей, чем тот же clang. Он порождает гигантскую портянку, которую потом LLVM мучительно оптимизирует. Это следствие выбранного растом подхода к реализации женериков и const женериков. Выбор был сделан потому, что так было проще, и теперь он серьезно ограничивает развитие языка. При этом просто взять и переделать все нельзя – это неподъемная работа по полному переписыванию компилятора.

Да, потому что стандартный C/C++ сам по себе — это полная херота, которую в полном объеме реализовали только вахтеры из GCC,

Большая часть изменений (языковых) в стандарт носит дескриптивный характер, описывая то, что уже реализовано в компиляторах в качестве расширений. При этом степень реализация стандарта в MSVC и GCC примерно равна, clang в последнее время отстает.

«Компилятор» (а на самом деле фронт к LLVM) никогда не ускорится значительно, потому что он (фронт) крайне примитивен, и делает куда меньше вещей, чем тот же clang. Он порождает гигантскую портянку, которую потом LLVM мучительно оптимизирует

И как это объясняет неспособность раста эффективно параллелизоваться по ядрам?

При этом степень реализация стандарта в MSVC и GCC примерно равна, clang в последнее время отстает

И, тем не менее, в MSVC отсутствуют оптимизации strict aliasing. И он не вываливает выполнение за границу функции при отсутствии return у функции, возвращающей значение.

Никак. Это был ответ конкретно на цитату про малую скорость работу компилятора раста из-за необходимости обеспечения согласованности трейтов.

Согласен. Правда, с C++ то же правило работает — можно точно так же требовать от программистов писать unsafe возле любого небезопасного кода.

Нельзя, даже самый опытный программист этого сделать не может, в С++ в общем случае тупо невозможно по коду сказать что он опасный, какой нибудь банальный и как бы безопасный std::vector может на ровном месте выстрелить. В случае же rust unsafe хорошо локализует все потенциально опасные места и главное компилятор следит за тем чтобы опасные вещи не использовались вне unsafe.

Нет, тебе срать на ядра. Твоя задача 24 на 7 аттаковать Раст. Я даже не знаю почему.

Он же сам писал что не освоил с наскоку, весьма веская причина.

И что же у нас в 2021 году работает на 16 потоках так же хорошо, как на двух?

Еще нужно учитывать что далеко не все задачи даже в теории могут масштабироваться на десятки и тем более на десятки тысяч потоков. Закон Амдала никто не отменял. Для тех задач которые могут так масштабироваться давно придумали GPU и прочие ускорители, так что думаю для подавляющего большинства универсальных компьютеров, ядер больше десятков и сотен скорее всего никогда и не потребуется. Гораздо интереснее, и для большего класса задач, было бы поднять частоту хотя бы на порядок.

И как это объясняет неспособность раста эффективно параллелизоваться по ядрам?

Потому что это вообще не задача для ЯП общего назначения. Потому что ни ты никто другой не может сделать универсальный алгоритм распараллеливания для неопределенных данных, для неопределенных алгоритмов их обработки. Есть задачи которые легко паралелятся (теже неросетки и 3Д), но их абсолютно неэффективно делать на проце общего назначения и для этого придумали всякое специализированное железо. А есть задачи, которые требуют большой оперативы, и вот для них уже нужен мощный проц, и видяхи такое уже не тянут. и т.д. и т.п.

Итог, нельзя сделать ни железо, ни язык программирования, которые бы эффективно паралелили абсолютно любой алгоритм на любых данных.

так что завали хлебало и не гавкай на раст.

Что за хай фриквенси? 100 млн транзакций в секунду? 10 млн? Если нет, то это не высокопроизводительный софт.

Знаю только что там критичны задержки в обработке сообщений и борются буквально за такты.

Поскольку хром не может толком задействовать ядра процессора под логику, то в потоках крутится сборка мусора, которая предельно тупа и предсказуема.

Современные браузеры рисуют картинку достаточно быстро. Долго по сети пересылаются мегабайты минифицированной js-лапши.

А ты пишешь реально работающие многозадачные системы?

Да.

99% сегодняшних задач сводятся к выполнению в одном потоке вообще без синхронизации. Особенно это касается PHP, JS, Python.

Бинго! Ты осознал, что не все можно распараллелить.

https://browser.geekbench.com/v5/cpu/5367591 — мак на AMD Ryzen 7 5800X

А чо не 5950X?

https://browser.geekbench.com/v5/cpu/7421821

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

Вот пример на том же 5800X, который сильно больше очков набрал: https://browser.geekbench.com/v5/cpu/5874365

И я сейчас говорю не про «чей папка круче», а про преимущества технологии ARM. И они примерно двухкратные.

Где они? Я тоже не спорю чей папка круче, мне тащемта насрать подо что софт компилировать. Но ARM что-то как-то не взлетает, если его со всей силы не пинать, как это Apple делает.

в С++ в общем случае тупо невозможно по коду сказать что он опасный, какой нибудь банальный и как бы безопасный std::vector может на ровном месте выстрелить. В случае же rust unsafe хорошо локализует все потенциально опасные места и главное компилятор следит за тем чтобы опасные вещи не использовались вне unsafe

Ты затрагиваешь вполне конкретные проблемы библиотек C++, которые писались из соображения «UB? Читай документацию, дебил!», и в итоге вся стандартная либа — одно сплошное минное поле из «читай документацию». Вот как ты объяснишь вахтерам из GCC, что применение оптимизации strict aliasing недопустимо? Ты им говоришь «создаваемые ею ошибки исключительно тяжело найти», они тебе отвечают «зато она дает 2% ускорения в среднем». Это, конечно, клиники в терминальной стадии, но в сишке дофига проблем помягче. Например, в MSVC есть расширение для проверки размеров буферов и безопасные аналоги strcpy, strncat, которые вполне себе находятся в стандарте C11, но разрабам GCC просто похер, они сделали свое FORTIFY_SOURCE с хардкодом в компиляторе для printf и функций работы со строками.

Одна из первых моих реакций по этому поводу в отношении раста была «от одной крайности перешли к другой крайности». Ты никак не сможешь запретить особо упертому человеку стрелять себе в ногу, а помимо UB ошибок из-да некорректной работы с указателями в программе еще есть и ошибки логики. Но если ты начнешь закручивать гайки по безопасности в крестах, то поднимется вой «караул, нас 5% производительности лишают!». Сложность же программ на расте (и на C++ тоже) — это фактор, который повышает шанс алгоритмических ошибок.

В случае же rust unsafe хорошо локализует все потенциально опасные места и главное компилятор следит за тем чтобы опасные вещи не использовались вне unsafe

А дедлок и паника у нас в «потенциально опасные места» не входит?

Он же сам писал что не освоил с наскоку, весьма веская причина

Сраный раст я могу на приемлимо новичковом уровне изучить за пару-тройку недель. Но зачем? Я эту хрень ковыряю, а меня воротит, потому что я прямо вижу текущее по рекам смузи безразличие авторов языке к своему творению. Авторы Rust делали карьеру, они не делали язык, он прямо-таки заточен на то, чтобы на митинге доложить заглянувшему руководству про пятикратное снижение затрат на разработку браузера, но вне этой ниши у него весьма сомнительная применимость. Как я уже писал, однопоточные программы на C++ пора отправлять на пенсию, но вместо них нам почему-то предлагают двухпоточные программы на Rust.

Еще нужно учитывать что далеко не все задачи даже в теории могут масштабироваться на десятки и тем более на десятки тысяч потоков

Как правило, если задача подразумевает много работы, то почти всегда эту работу можно параллелизовать, хотя бы сменой алгоритма. Просто, последние 50 лет IT почему-то упорно идет в обратном направлении, пытаясь засунуть любое параллельное вычисление в строго пошаговую Тьюринг-машину.

Закон Амдала никто не отменял. Для тех задач которые могут так масштабироваться давно придумали GPU и прочие ускорители, так что думаю для подавляющего большинства универсальных компьютеров, ядер больше десятков и сотен скорее всего никогда и не потребуется

Выше правильно упомянули, что GPGPU на самом деле весьма ограничено в параллелизации — оно может выполнять только одну и ту же инструкцию сразу на группе вычислительных ядер, поскольку управляющее устройство на всю эту группу одно. Например, в Radeon RX 5500 всего 22 командных процессора на 1400 вычислительных ядер. Так что остается довольно жирная прослойка задач, которые могут параллелизоваться, но не на GPGPU.

Гораздо интереснее, и для большего класса задач, было бы поднять частоту хотя бы на порядок

Да, интересно, жаль что физически невозможно.

Потому что ни ты никто другой не может сделать универсальный алгоритм распараллеливания для неопределенных данных, для неопределенных алгоритмов их обработки

Более того — нельзя даже придумать алгоритм для написания однопоточного кода обработки неопределенных данных. Потому программирование и является такой хорошо оплачиваемой профессией.

так что завали хлебало и не гавкай на раст

Хорошо, давайте дальше писать на фортране.

Современные браузеры рисуют картинку достаточно быстро

«Достаточно». То есть, ты сам глубоко в душе понимаешь, что вообще-то не совсем достаточно, и порой совсем недостаточно.

99% сегодняшних задач сводятся к выполнению в одном потоке вообще без синхронизации. Особенно это касается PHP, JS, Python.

Бинго! Ты осознал, что не все можно распараллелить

Два последних года «неосознал», потому написал либу для параллелизации ванильного CPython.

А чо не 5950X?

В два раза дороже жи ж. Моя оценка стоимости Apple M1 — примерно $200-300. А ты его сравниваешь с процом за $800. 20-ваттный M1 против 100-ваттного 5950X. Еще бы с печкой на 300 Вт за $2000 сравнил.

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

Ради бога — смотри сравнения на серверных платформах, у которых примерно тот же результат. Но тебе и то не так, и это не так.

Вот пример на том же 5800X, который сильно больше очков набрал: https://browser.geekbench.com/v5/cpu/5874365

20% — это несерьезно, когда мы говорим про «в два раза».

Где они? Я тоже не спорю чей папка круче, мне тащемта насрать подо что софт компилировать. Но ARM что-то как-то не взлетает, если его со всей силы не пинать, как это Apple делает

Я написал это с самого начала: IT индустрия очень инертна, смена платформы требует денег, а на «свободном рыночке» даже 5% финансового преимущества значат многое, и потому рыночек исподволь будет беспощадно тормозить любой прогресс, пока не выйдет наконец корпорация с лишними миллиардами и не скажет «так, все быстро перешли на ARM». И то, даже этого не хватает, чтобы индустрия серьезно зашевелилась. Вот выбрось хотя бы $100 млрд на рынок — тогда мы подумаем, нужен ли нам ARM или нет.

в MSVC отсутствуют оптимизации strict aliasing. И он не вываливает выполнение за границу функции при отсутствии return у функции, возвращающей значение.

MSVC должен собирать работающими многие программы и библиотеки, и не только от Microsoft, но и программы различных партнёров. И зачастую это старые программы…

Так что да, часть оптимизаций отсутствует.

Вот, как пример: https://developercommunity.visualstudio.com/t/ClangCL-and-MFC-Undefined-Behaviour/1541392

20% — это несерьезно, когда мы говорим про «в два раза».

Это ты говоришь «в два раза». Я этих двух раз нигде не вижу. Всё, что я вижу, это лажовый бенчмарк, количество попугаев в котором зависит от туевой хучи сторонних условий.

Я написал это с самого начала: IT индустрия очень инертна, смена платформы требует денег, а на «свободном рыночке» даже 5% финансового преимущества значат многое, и потому рыночек исподволь будет беспощадно тормозить любой прогресс, пока не выйдет наконец корпорация с лишними миллиардами и не скажет «так, все быстро перешли на ARM»

Пока всё складывается так: ты утверждаешь, что ARM магическим способом увеличит производительность в два раза, но непонятно как и засчёт чего, а образцов такого почему-то нету. Apple M1 с миллиардами вложенными в него двух раз вообще не показывает.

Если ты посмотришь фотки кристаллов, то очень здоровую часть, чуть не половину площади иногда, там занимает ВНЕЗАПНО кэш. Естественно, если его выпилить, площадь кристалла уменьшится, а скорость в попугаях может даже вырасти засчёт меньшего количества активных транзисторов. Только в производительность в реальном софте, который от кэша может огого как зависеть, это не факт что как-то перетечёт.

Вот, как пример: https://developercommunity.visualstudio.com/t/ClangCL-and-MFC-Undefined-Behav...

Я нифига не понял, на что жалуется. Очередная некорректная оптимизация, используемая вместо алгебраических типов данных. Типа MSVC должен собирать старый софт, а Clang — нет, что ли? Зачем тогда clang нужен?

Я нифига не понял, на что жалуется.

В реализации MFC есть такой код,

pFont->GetSafeHandle(); // pFont = nullptr

GetSafeHandle видимо проверяет this на nullptr, и делает что-то другое. Не знаю, не смотрел реализацию. Но так как this не может быть nullptr или это UB, то clang выпиливает эти проверки. И потом падает в рантайме. А фиксить MFC в Microsoft не будут, поэтому и закрыли баг как Lower Priority.

Типа MSVC должен собирать старый софт, а Clang — нет, что ли?

Да.

Зачем тогда clang нужен?

Для чуть более быстрого нового софта.

Всё, что я вижу, это лажовый бенчмарк, количество попугаев в котором зависит от туевой хучи сторонних условий

Не «бенчмарк», а «бенчмарки». Я тебе дал два бенча, но тебе всё «лажовое». А вот от тебя я что-то бенчей не вижу.

ты утверждаешь, что ARM магическим способом увеличит производительность в два раза, но непонятно как и засчёт чего, а образцов такого почему-то нету. Apple M1 с миллиардами вложенными в него двух раз вообще не показывает

А интель с амудой нищие, что ли? Так-то большую часть разработки M1 произвел ARM Inc, и потому вряд ли Яббл потратил на его разработку больше миллиарда (хотя на маски им понадобилось порядка сотни млн).

Если тебе интересно за счет чего ARM уделывает x86, то я могу пояснить. AArch64 — это переписанная почти с нуля архитектура, которая хорошо адаптирована под современные технологии и сравнима с RISC-V. То есть, там нет десятков сотен слоев совместимости с древним машинным кодом, как в x86. При этом фиксированная длина команды в 32 байта, которая делает разбор инструкций нереально простым. Второй важный фактор — это слабая модель памяти ARM. x86 требует строгой упорядоченности почти всех операций доступа (за исключением store-load), хотя бы на уровне кэшей. Это сильно ограничивает возможности параллельного доступа к памяти в x86. Из-за этого x86 обросло сложным спекулятивным выполнением, которое заранее выполняет операции будто бы со слабой моделью памяти, но применяет их к кэшу только если требования строгой модели памяти были выполнены. ARM очень долгое время по факту выполнял доступ к памяти внеочередно, хотя формально производил лишь поочередное выполнение команд — просто потому, что ARM-у не нужно было выдерживать порядок доступа.

Точно так же еще в 90-х годах DEC Alpha уделал в хлам x86 теми же самыми приемами. Интелю понадобилось лет пять, чтобы догнать DEC Alpha по характеристикам. Только отвратительный подход владельцев бизнеса и менеджмента в DEC привел к тому, что нынче весь рынок серверов работает не на архитектуре Alpha. И именно адекватность руководства ARM привела к тому, что теперь эта архитектура является одной из двух крупнейших игроков. Причем, у ARM на самом деле нет никакой своей архитектуры команд: в разные времена процессоры ARM использовали три абсолютно непохожие наборы команд — это оригинальный ARM, который скорее CISC, чем RISC, это Thumb, который после ввода переменной длины команды стал 100% CISC, и это современный AArch64, который является типичным RISC набором. Были еще переходные Thumb с фиксированной 16-битной инструкцией и AArch32, которое является оригинальной ARM, переделанной для совместимости с AArch64, правда, цель этого поступка мне не совсем ясна — процессор AArch64 не может выполнять код AArch32 без супервизора на AArch64.

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

Если ты посмотришь фотки кристаллов, то очень здоровую часть, чуть не половину площади иногда, там занимает ВНЕЗАПНО кэш. Естественно, если его выпилить, площадь кристалла уменьшится, а скорость в попугаях может даже вырасти засчёт меньшего количества активных транзисторов

Проблема кэша заключается в том, что чрезмерное увеличение его объема не имеет смысла, поскольку задержка доступа начнет приближаться к задержке доступа к оперативной памяти. Эмпирически производители пришли к цифрам в 1.5-2.0 МБ кэша для низкопроизводительных процессоров, 3-4 МБ для высокопроизводительных и/или гипертреда. Высокопроизводительные ядра на M1 имеют 3 МБ кэша на ядро, у рузена 5800X — 4 МБ на ядро (гипертред же ж). Более забавным является тот факт, что число высокопроизводительных ядер на M1 в 2 раза меньше, и при этом он все равно дает столько же попугаев на бенчах. Это говорит нам, что важно не только иметь кэш, но еще и правильно им пользоваться.

GetSafeHandle видимо проверяет this на nullptr, и делает что-то другое. Не знаю, не смотрел реализацию. Но так как this не может быть nullptr или это UB, то clang выпиливает эти проверки

Ну что я могу сказать — это гениально, просто взять и выкинуть код. Меньше кода — быстрее работает программа. Сишные компиляторы в очередной раз доходят до абсурда в оптимизациях.

Не «бенчмарк», а «бенчмарки». Я тебе дал два бенча, но тебе всё «лажовое». А вот от тебя я что-то бенчей не вижу.

Ты мне дал ссылку на бенчмарк, где у одного процессора (Ryzen 5800X) результат прыгает чуть ли не на треть. Как это ещё интерпретировать, если не лажу? Второй нюанс в том, что бенч запускался на ОС, которая никогда официально на AMD не работала, а значит там может отсутствовать код, отвечающий за термалку и прочие ништяки.

А интель с амудой нищие, что ли?

В сравнении с Apple – вполне :DD

Так-то большую часть разработки M1 произвел ARM Inc

Каким местом? В Apple M1 оригинальные ядра, а не купленные у ARM.

При этом фиксированная длина команды в 32 байта, которая делает разбор инструкций нереально простым.

Это всё потрясно, только плотность кода получается никакущей. Итаник от этого тоже страдал. В итоге на бенчмарках, где весь код в L2 кэш влезает, всё в шоколаде, а в реальном мире – хтонь и срань, потому что шины памяти не хватает, чтобы код вместе с данными прогонять.

Более забавным является тот факт, что число высокопроизводительных ядер на M1 в 2 раза меньше, и при этом он все равно дает столько же попугаев на бенчах.

Дядя, ты чего? У тебя там приступ что ли? В твоём же гикбенче, который ты сам сюда притащил, у M1 – 7650 (https://browser.geekbench.com/v5/cpu/5434681), у 5800X – 12255 (https://browser.geekbench.com/v5/cpu/5874365). Это столько же попугаев? Потому я вижу, что AMD уделывает яббл больше чем в полтора раза. Что вообще не удивительно, потому что ты за каким-то хреном полез сравнивать десктопный и ноутбучный чипы.

P.S. Вообще, этот бенчмарк действительно вызывает вопросы, потому что вот у телефонного чипа попугаев в 4 раза больше на ядро чем у M1.

https://browser.geekbench.com/v5/cpu/10181699

Ну что я могу сказать — это гениально, просто взять и выкинуть код. Меньше кода — быстрее работает программа. Сишные компиляторы в очередной раз доходят до абсурда в оптимизациях.

Стандарт C это позволяет делать, потому что корректная программа не должна содержать UB. Тут либо в печь такой стандарт (да и язык заодно), либо не надо говнокод писать. Другими словами, либо трусы наденьте, либо крестик снимите.

В Apple M1 оригинальные ядра, а не купленные у ARM

ARM Inc уже лет 25 не производит процессоры, потому все ядра ARM — «оригинальные, а не купленные».

https://community.arm.com/developer/tools-software/tools/b/tools-software-ide...

Вот, один в один как в M1: Armv8.4-A, 4+4 ядра.

Это всё потрясно, только плотность кода получается никакущей. Итаник от этого тоже страдал. В итоге на бенчмарках, где весь код в L2 кэш влезает, всё в шоколаде, а в реальном мире – хтонь и срань, потому что шины памяти не хватает, чтобы код вместе с данными прогонять

Oh rly?

https://packages.debian.org/bookworm/git

Архитектура 	Размер пакета 	В установленном виде
amd64 	5 555,5 Кб	36 830,0 Кб
arm64 	5 483,0 Кб	36 576,0 Кб
i386 	6 407,9 Кб	40 921,0 Кб

https://packages.debian.org/bookworm/firefox-esr

Архитектура 	Версия 	Размер пакета 	В установленном виде
amd64 	78.14.0esr-1+b1 	54 083,8 Кб	199 893,0 Кб
arm64 	78.14.0esr-1+b1 	50 441,7 Кб	196 124,0 Кб
i386 	78.14.0esr-1+b1 	57 095,2 Кб	212 881,0 Кб

В твоём же гикбенче, который ты сам сюда притащил, у M1 – 7650 (https://browser.geekbench.com/v5/cpu/5434681), у 5800X – 12255 (https://browser.geekbench.com/v5/cpu/5874365). Это столько же попугаев? Потому я вижу, что AMD уделывает яббл больше чем в полтора раза. Что вообще не удивительно, потому что ты за каким-то хреном полез сравнивать десктопный и ноутбучный чипы

Уделал M1 в 1.6 раз при том, что потребляет в 7 раз больше и число транзисторов в ядрах в 1.6 раз больше (2.0 + 0.5 млрд у M1 против 4 млрд у рузена). Кстати, точное TDP ядер у M1 — 15 Вт.

Даже если по стоимости AMD и может тягаться с ARM, то по энергоэффективности AMD рядом не валялся.

P.S. Вообще, этот бенчмарк действительно вызывает вопросы, потому что вот у телефонного чипа попугаев в 4 раза больше на ядро чем у M1.
https://browser.geekbench.com/v5/cpu/10181699

Да ради бога — дай свои бенчи, правильные.

Стандарт C это позволяет делать, потому что корректная программа не должна содержать UB. Тут либо в печь такой стандарт (да и язык заодно), либо не надо говнокод писать. Другими словами, либо трусы наденьте, либо крестик снимите

Оба стандарта C и C++ на самом деле замалчивают эту проблему и никак не определяют это поведние. То есть, это не UB и не корректное поведение — как хочешь, так и реализуй. А проблема возникает из-за того, что стандарт C++ §5.2.5/3 говорит

If E1 has the type “pointer to class X,” then the expression E1->E2 is converted to the equivalent form (*(E1)).E2;

Но проблема в том, что оба стандарта отказываются говорить, что является настоящим доступом. (*(E1)).E2 — это lvalue, у которого, например, можно взять адрес, что де-факто большинство компиляторов интерпретирует как «доступа к значению по этому адресу не происходило». Например, я могу сделать

struct int_t {
  int a
};

int *pntr = &((int_t *)NULL)->a;

И ни один компилятор Си мне не выдаст ошибку при компиляции или выполнении. Вот если я разыменую полученный указатель дальше, например, через «return *pntr» — это ошибка, это UB. Стандарт C++ не определил, в какой момент происходит реальный доступ по некорректному адресу для статичных членов класса, из-за чего начался традиционный разброд и шатание, примерно как в случае strict aliasing.

Для нестатичных членов, к слову, этот момент вполне себе определен (§9.3.1/1):

If a nonstatic member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undefined.

И ни один компилятор Си мне не выдаст ошибку при компиляции или выполнении.

#include <stdlib.h>

typedef struct {
    int a;
} int_t;

int main() {
    int *pntr = &((int_t *)NULL)->a;
}

https://gcc.godbolt.org/z/zfTqEbefr

В clang:

/app/example.c:8:31: runtime error: member access within null pointer of type 'int_t'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.c:8:31 in 

А в gcc кстати норм :)