чтобы можно было продолжать все что можно говнокодить на питоне делать это на питоне, классно же, молодежно опять же.

требовательного числодробления очень вряд ли, что в ближайшие лет 10 понадобится не х86-64

а почему не взять POWER?

борща?

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

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

Это я его встречать борщом научил, с тебя пиво :3

Для не слишком требовательного кода не все ли равно как математика скомпилируется?

Да, только тебя в пять разных архитектур нужно эту математику компилировать, то есть, пять разных программ или просто функций — примерно так и выглядят всякие кодеки для видео. У меня проц AVX512 не поддерживает, например, а у меня последнее поколоение десктопных процев. Что говорить про сервер, на котором проц из нулевых стоит? На 64-битках, как правило, нужно использовать SSE в таких случаях, потому что MMX регистры содержатся в соглашениях вызова и не могут быть выкинуты из архитектуры. Соответственно, оттуда проходишь всю историю: SSE2, AVX, AVX2, AVX512. Именно такой набор целевых архитектур у MSVC: AVX, AVX2, AVX512, IA32, SSE, SSE2, где IA32 — это x87.

А для требовательного числодробления очень вряд ли, что в ближайшие лет 10 понадобится не х86-64, если же таки нужно не на х86-64

CPGPU и ARM — последний уделывает x86 во всём, но просто-напросто не получил широкого распространения, потому серверные решения на нем стоят дорого. Тот же Amazon сделал собственное массовое произвоство ARM серверов и продает их заметно дешевле, чем x86.

а почему не взять POWER?

Или SPARC. Проблема, как обычно, заключается в том, где найти доступные готовые процессоры. Под ARM это заметно проще сделать. Как бы дело не в том, что SPARC/Power/ARM хороши — просто x86 сильно плохой.

Питон используется, но в некритических по скорости местах. В остальных — С++

а почему не взять POWER?

Тогда x86 не нужен :)

где найти

Для РФ они уже под санкциями?

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

Код может быть двумя из трёх: портабельным, высокооптимизированным, написанным на универсальном языке. Но не всем сразу

CPGPU и ARM — последний уделывает x86 во всём, но просто-напросто не получил широкого распространения, потому серверные решения на нем стоят дорого.

GPGPU требует оптимизации. ARM тоже. Как и POWER

C++ давно дорос если пользоваться лишь Qt5, тогда и C++11 будет полезен для пищеварения

Это точно мне ответ?

где найти

Для РФ они уже под санкциями?

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

GPGPU требует оптимизации.

Неа:

https://www.researchgate.net/profile/Thomas_Scogland/publication/229034386_Ar...

Здесь видно, что разница по производительности довольно смехотворна. Да, у нвидии есть тензорные ядра, которые дают где-то 2-кратный рост производительности на считанных задачах — а я напомню, что видеокарты на задачах параллельных вычислений дают рост производительности в десятки раз по сравнению с ЦП, а если сравнивать с SSE, то будут и сотни.

Код может быть двумя из трёх: портабельным, высокооптимизированным, написанным на универсальном языке. Но не всем сразу
GPGPU требует оптимизации. ARM тоже. Как и POWER

Если ты пользуешься какими-то узкоспецифичными для конкретного проца фичами, вроде бездумно скопированного с x86 SIMD, то да, твоя фраза актуальна. И это скорее проблема любого SIMD, нежели проблема конкретной архитектуры: если ты пользуешься SIMD, то твой код всегда не будет портируемым. Именно отсюда выросло заблуждение «код не бывает портируемым и оптимизированным одновременно».

Серьезное отличие еще есть в многопоточке, поскольку механизмы целостности данных довольно сильно отличаются у ARM-Power и x86 — но это именно разница между классами архитектур, внутри же проблем нет.

У ARM когда-то был примитивный умножитель, не было аппаратного делителя, и даже не было кэша — но это было давно и неправда. Где-то с v7 ARM получил умножение/деление со знаком/без, 16-битные immediate value для засовывания в регистр 32-битного числа за 2 инструкции и 64-битного за 4 инструкции, linked load/store conditional и выкинут SWAP, а с Thumb 2 и AArch64 (последний уже в v8 был) отправлено на пенсию условное выполнение и битовые сдвиги из большинства инструкций — ARM превратился в такой каноничный RISC, слабо отличный от Alpha, Power, RISC-V, i960, и еще кучи забытых архитектур, а потому не требующий специальных оптимизаций.

Там access types. Но это не то же самое, что сишечные «указатели». И знание сишечных указателей в аде не сильно помогает, скорее мешает.

А что, в perl есть указатели? Вот в питоне нет. Как же питонистов собеседовать…

ARM превратился в такой каноничный RISC, слабо отличный от Alpha, Power, RISC-V, i960, и еще кучи забытых архитектур, а потому не требующий специальных оптимизаций

брехня

https://github.com/ARM-software/optimized-routines

если ты пользуешься SIMD, то твой код всегда не будет портируемым. Именно отсюда выросло заблуждение «код не бывает портируемым и оптимизированным одновременно».

если ты не пользуешься SIMD твой код по определению тормозное г-но

https://developer.arm.com/documentation/100891/0612/sve-overview/introducing-sve

SVE is a SIMD instruction set for AArch64, that introduces the following architectural features for High Performance Computing (HPC)

ну веруй-веруй, кто тебе не даёт…

При чём тут вера? Или игры уже на Java начали писать?

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

а программисты?

10к строк кода на Си биндинга к питону

Это цифра ни о чём. Может ты как индус пилишь.

Да, неплохо бы борщеца с салом и черным хлебушком навернуть.

Ну так что характерно minecraft на java и написан. Вроде как игра и вроде как популярная достаточно, думаю попрофитнее всяких крайзисов. А вот minetest на C++ никак не взлетит. А кабы на расте его написали, то вообще 2 пользователя бы было и оба разработчики.

Аналитика уровня ЛОР.

Или игры уже на Java начали писать?

хмм… Android ? :D

а программисты?

Тоже есть, но у них разнообразия значительно больше.

хотите сказать что женщинам кроме питона ничего не светит?) вот это неплохой вброс

нет хочу сказать, что женщинам питонить больше нравиться. змея там … фрейд :D :D :D

Там такие «игры», что лучше сразу вдоль. А все навороченные конечно на плюсах.

я и говорю веруйте-веруйте. когда надоест сравните сколько людей пишет движки к играм класса A, а сколько людей пишет игры под андройты и айпады. сравните порядки и найдёте нишу c++. и так по всем пунктам ну и получите там 2-5%. вот и вся ниша… и сокращается. и слава богу - Франкенштейн под именем с++ должен успокоиться.

Ниша не может сокращаться, ибо альтернатив нет.

брехня
https://github.com/ARM-software/optimized-routines

Ну, и каким образом это опровергает мои слова? Единственный исходник в папке networking — это chksum_simd.c. Все асмовые файлы из string — это векторные операции. math — и вовсе кроссплатформенный код на Си. А я как раз и писал о том, что SIMD — это полный провал, оно родилось когда процы были слабыми, векторы были маленькими, особо не из чего было выбирать, задачи у векторов были чем-то вроде «быстрее кодировать MPEG» и кол-во операций было строго ограниченным. Оно изначально было узко специализированным под конкретную задачу, что обрекало его на непортируемость. Вместо того, чтобы переделать его хорошо и портируемо, процессоростроители просто докинули мусора в кучу, как они это любят делать. В итоге под каждую версию процессора код приходится переписывать.

если ты не пользуешься SIMD твой код по определению тормозное г-но

А ты что-то помимо числодробилок писал в свое жизни?

кроссплатформенный код на Си. А я как раз и писал о том, что SIMD — это полный провал

странный вывыод, SIMD это уже стандарт для современных ЦПУ и компиляторы продвинулись в этом направлении.

Это кроме Сишки, мой список на изучение

1. Nim 1.1 Pony
2. внезапно picoLisp (замена всяких/любых SQL)
3. Crystal+Lua (Web и не только)
4. для фана microPython

(замена всяких/любых SQL)

Поясни пожалуйста

SIMD это уже стандарт для современных ЦПУ и компиляторы продвинулись в этом направлении

Проблема не в SIMD как в классе. Проблема здесь не в том, что компиляторы что-то не поддерживают, а в том, что написанная тобой программа непортируема. То есть, на старом процессоре она не запустится, а на новом — будет работать медленно. Если тебе интересен пример хорошей реализации конкретно для ЦП — есть векторное расширение для RISC-V.

Также я напомню, что весь смысл центрального процессора заключается именно в неограниченной гибкости онного, способности выполнять любые задачи. Если я захочу сделать какую-то узко заточенную логику, то я возьму FPGA. Но именно потому FPGA и малопопулярны, что ЦП в большинстве случаев хватает.

есть векторное расширение для RISC-V

каким образом оно решает проблему несовместимости для разных процессоров ?

Если я захочу сделать какую-то узко заточенную логику, то я возьму FPGA

как раз чтобы не заморачиваться со всякой херней и придумали SIMD в ЦПУ. А фиаско - это про FPGA, дальше протоипирования оно не пошло.

Это для программеров список :) А мне нужен ЯП не для IT специальностей, а для различных задач вычислительной физики...

P.S. Посмотрел по вакансиям, много где требуют Matlab, так что Julia как альтернатива ему вполне подходит... Ну и Питон, конечно

каким образом оно решает проблему несовместимости для разных процессоров?

Программа с SIMD на RISC-V запускается на любом процессоре RISC-V с поддержкой векторного расширения, независимо от ширины вектора в процессоре и с максимальной производительностью. Код запрашивает доступную ширину вектора для всех векторных инструкций, но при желании может использова вектор меньше. Цена вопроса, как правило — лишний занятый регистр с размером вектора. Кроме того, можно поставить нулевую длину вектора, устраняя таким образом векторные регистры из состояния потока при переключении контекста — такая себе микрооптимизация.

как раз чтобы не заморачиваться со всякой херней и придумали SIMD в ЦПУ. А фиаско - это про FPGA, дальше протоипирования оно не пошло

FPGA очень даже конкурентно. Если бы оно было более популярно, то для узкоспециализированных задач аля кодирование видео и нейронные сети уделывало бы процессоры общего назначения в хлам по соотношению производительность/цена — слишком уж неэффективно современные процессоры используют транзисторы. Поскольку есть еще и третий конкурент, GPU, который умеет делать много параллельных вычислений с производительность/цена лучше, чем у FPGA, то ниш остается не так много. Недавно nvidia сделал тензорные ядра a.k.a. ASIC, забрав еще одну нишу у FPGA.

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

Программа с SIMD на RISC-V запускается на любом процессоре RISC-V с поддержкой векторного расширения, независимо от ширины вектора в процессоре и с максимальной производительностью

вот видишь какая красота - SIMD рулит

FPGA очень даже конкурентно

медленно, дорого, энергопрожорливо, сложно = ненужно

Недавно nvidia сделал тензорные ядра a.k.a. ASIC, забрав еще одну нишу у FPGA.

GPU это тоже ASIC по сути и вот эти ASIC по всем параметрам рвут в клочья FPGA

Это как бы старая добрая традиция западного IT

там умеют считать деньги. И не только в IT.

В контексте про x86 vs ARM - ну пока amd64 уделывает arm по производительности на ядро, насколько я знаю. А это очень серьезный параметр, многие задачи решаются рекуррентными алгоритмами и поэтому параллелятся плохо.

например

https://m.habr.com/ru/post/177791/

Где уделывает?

https://www.ixbt.com/news/2020/09/03/qualcomm-snapdragon-8cx-gen-2-5g-core-i5.amp.html

сколько лет прошло с момента начала написания до момента, когда этим стало можно пользоваться?.. :)

ну так никто не знает, время еще идет ))

Ну мне интересно сравнение самых производительных ядер на базе AArch64 и amd64. То что в отдельных случаях arm предпочтительнее x86 это бесспорно, но интересна именно максимальная производительность на ядро без оглядки на тепловыделение, энергопотребление и прочее.

вот видишь какая красота - SIMD рулит

Это правильные пчелы, и у них правильный SIMD.

FPGA очень даже конкурентно

медленно, дорого, энергопрожорливо, сложно = ненужно

Не путай «не осилил» и «сложно». Кому-то и ARM «сложно».

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

там умеют считать деньги. И не только в IT

Я уже много раз отвечал на это — нет, не умеют в IT считать деньги. Как правило, решения принимаются из расчета «сделать и забыть», «еще месяц выжили — и то хорошо», независимо от того, каким убытком для фирмы выльется это решение после твоего ухода. Отсюда столько потерянных с AWS, которые спустя год разработки на нем выяснили, что AWS — это очень дорого, даже если у вашего проекта большой бюджет. Весь код написан, контейнеры налажены, индусы скоординированы, протоколы написаны, регламент составлен — а потом оказывается, что затраты на AWS растут сильно быстрее, чем растет доход.

GPU это тоже ASIC по сути

Нет, потому что логика полностью програмируемая. Когда-то видеокарты имели жесткую логику, но это было давно и неправда. К тому же, на тех видеокартах нельзя было вести вычисления. Именно с тех пор, как они позволили выполнять на себе произвольную логику, они перестали быть «Application Specific», и стали «General Purpose».

GPU это тоже ASIC по сути и вот эти ASIC по всем параметрам рвут в клочья FPGA

Блин, ну гуглится же:

https://ieeexplore.ieee.org/document/8425482

И таких статей валом. FPGA всегда уделывают процессоры по производительности и эффективности на узких задачах, а вот с GPU еще тягаются, но FPGA, как правило, оказывается более энергоэффективным, хоть и дороже GPU. Потому что малый тираж. Если делать большую систему из тысяч FPGA, то там цены будут поприятнее. Просто из того расчета, что разработка FPGA плюс изготовление масок — это несколько миллионов/десяток миллионов долларов, а если делить эту сумму на тысячи, то получается цена одного FPGA чипа, сравнимая с ценой видеокарты.

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

В контексте про x86 vs ARM - ну пока amd64 уделывает arm по производительности на ядро, насколько я знаю. А это очень серьезный параметр, многие задачи решаются рекуррентными алгоритмами и поэтому параллелятся плохо

Многие задачи пишутся индусами через анус, потому не только параллелятся плохо, но вообще плохо работают и постоянно падают. Последовательное выполнение команд — это путь вникуда, и сам x86 это доказал, перейдя на суперскалярное выполнение. Видеокарта просто в сто раз быстрее производит вычисления при равной мощности и размере кристалла — и что ты будешь с этим делать? Вот примерно настолько x86 неэффективен.