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

точнее людям, которые его запилили

а надо доверять спеке на процессор

Короче, бросайте вы эти умные словечки. Ассемблер и всё забыли!

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

ну так не кидай говна

а не компилятору

ну так не кидай говна

вот потому и на C

ни сишка, ни кресты - это не те языки, на которых можно безболезненно накидывать говно

вот потому и на C

нет, надо на крестах

там нет соблазна польститься на какую-то магию и подтирание соплей

нет, надо на крестах

нет, не надо

в контексте числодробилок низкоуровневых - не надо

в контексте числодробилок низкоуровневых - не надо

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

вот пишешь ты код под видюху, чтобы биткойны майнить или нейросетки считать, у тебя несколько уровней кэшей, содержимым которых надо жонглировать очень тонко. И что ты будешь использовать для аллокации, new?)) или таки malloc побайтовый с маппингом в конкретную память

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

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

чем меньше магии там - тем лучше

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

затем что не будет у тебя на 100% низкоуровнего кода близкого железу

вот пишешь ты код под видюху, чтобы биткойны майнить или нейросетки считать, у тебя несколько уровней кэшей, содержимым которых надо жонглировать очень тонко. И что ты будешь использовать для аллокации, new?)) или таки malloc побайтовый с маппингом в конкретную память

так это mmap а не малок же, маллок не дает мапить в выбранный участок

затем что не будет у тебя на 100% низкоуровнего кода близкого железу

в случае разработки векторных архитектурных либ - будет

так это mmap а не малок же, маллок не дает мапить в выбранный участок

да это понятно, я утрирую. Но идея ясна же

ну хрен знает короче

вот пишешь ты код под видюху, чтобы биткойны майнить или нейросетки считать, у тебя несколько уровней кэшей, содержимым которых надо жонглировать очень тонко. И что ты будешь использовать для аллокации, new?)) или таки malloc побайтовый с маппингом в конкретную память

тебе никто в крестах malloc вызвать не запретит

я сам до сих пор иногда передергиваюсь, когда смотрю на исходники cpython и вижу там везде оператор register

в случае разработки векторных архитектурных либ - будет

ну кстати на векторных либах числодробилки не заканчиваются

тебе никто в крестах malloc вызвать не запретит

никто мне не запретит на си писать и послать ненужные кресты

ну кстати на векторных либах числодробилки не заканчиваются

ну да, есть еще прошивки для ASIC/FPGA

и там тоже никаких плюсов, упаси боже

я вот сталкивался с такой штукой как OpenFOAM - это хрень для расчётов в области механники сплошных сред

и там как раз кресты

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

и там как раз кресты

ну, видимо, их устраивало то, что получили

и математика там неслабая

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

> DSL > на крестах

> DSL > на крестах

представь себе

представь себе

ну, жалко проект, чо

хотя, в принципе, он, видимо, решает задачу, для которой писался

ну, жалко проект, чо

жалко у пчёлки, а без такого DSL (который кстати быстро работает из-за шаблонной магии, инлайнов и прочих крестовых штук) код математики превратится в нечитаемое говно

жалко у пчёлки, а без такого DSL (который кстати быстро работает из-за шаблонной магии, инлайнов и прочих крестовых штук) код математики превратится в нечитаемое говно

не может ничего “быстро работать из-за шаблонной магии”. Тут либо удобство, либо скорость

сейчас конечно обычно не городят такие штуки и тупо юзают Python как обёртку

в этом случае выбрали удобство, и норм

не может ничего “быстро работать из-за шаблонной магии”. Тут либо удобство, либо скорость

тут ты не прав

тут ты не прав

прав в общем случае

шаблонная магия на то и шаблонная магия, что магичить на этапе компиляции

прав в общем случае

нет, не прав

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

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

ууууу

нет, не прав

ну, я не ставил целью тебя переубедить. Это просто так

ууууу

именно

единственная альтернатива, которая могла бы тягаться хоть как-то - это весьма узкоспециализированный JIT

ты примерно представляешь себе как шаблоны работают?

но с этим не к плюсам

потому что в плюсах нет никакого "генерик кода"

потому что в плюсах нет никакого "генерик кода"

шаблоны - это и есть генерик-код

шаблоны - это и есть генерик-код

сами шаблоны не компилируются ни в какой код

вот их специализации - да

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

шаблоны это кодогенерация

а не генерик код

шаблоны это кодогенерация

+1

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

генерик код это void *

а не генерик код

одно другого никак не исключает

ну .. да

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

ну не совсем, точнее не везде

генерик код это void *

не соглашусь

ну не совсем, точнее не везде

альтернативный пример?

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

альтернативный пример?

Java

ERROR: S client not available

если брать компиляторы, а не виртуальные машины

Java

Java не в кассу, там JIT и вообще другое устройство

в жаве не шаблоны, там генерики это компайл-тайм проверка типов

в жаве не шаблоны, там генерики это компайл-тайм проверка типов

именно

в рантайме специализации отсутствуют

в жаве не шаблоны, там генерики это компайл-тайм проверка типов

да, все так

и бойлерплейта собственно там нет, и кодогенерации аля плюсы тоже

и бойлерплейта собственно там нет, и кодогенерации аля плюсы тоже

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

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

а я и не с этим спорил

а я и не с этим спорил

а с чем? мне не нравится концепция “похер, компилятор порешает”. Во многих случаях реально порешает, но есть много задач, где это только мешает

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

а с чем? мне не нравится концепция “похер, компилятор порешает”. Во многих случаях реально порешает, но есть много задач, где это только мешает

ну так C++ не запрещает тебе руками порешать те места, даже на сишке, если уж так надо

но может быть это было на уровне фантастики

ну так C++ не запрещает тебе руками порешать те места, даже на сишке, если уж так надо

но зачем мне плюсы, если я могу просто на сишке накидать?

но зачем мне плюсы, если я могу просто на сишке накидать?

просто опять же, не все числодробилки - это прям низкоуровневый код

и я уже приводил пример

потому что за плюсы больше зарплату дают

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

и вот за счёт того что это всякое наворочено на крестах достигается выжимка парочки процентов производительности

наверное

просто опять же, не все числодробилки - это прям низкоуровневый код

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

ну это отдельный паззл

что не меняет того, что можно на это забить и писать хоть на джаваскрипте, но и работать оно будет как говно, не обессудьте

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

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

да, типа того

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

загрузчики тут немного ни при чем. Загрузчик - это простейшая штука

что не меняет того, что можно на это забить и писать хоть на джаваскрипте, но и работать оно будет как говно, не обессудьте

не надо тут сравнивать javascript и C++, который даёт огромный контроль и простор для всяких оптимизаций как руками так и компилятором

это смотря что от загрузчика требуется

это разные вещи, совершенно

не надо тут сравнивать javascript и C++, который даёт огромный контроль и простор для всяких оптимизаций как руками так и компилятором

я не сравниваю, я просто описываю разницу в уровнях языков

это смотря что от загрузчика требуется

да даже груб при всей своей развесистости не так сложен внутри