>>1065530 (OP)
Однопроходный компилятор. </thread>

>>1065655
Т.е. эта проблема с C++ навсегда?

>>1065691
>Т.е. эта проблема с C++ навсегда?
Скорее всего нет, добьют году к двадцатому:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4681.pdf

>>1065702
Даже если добьют, останется куча легаси. А если ОПу не нравится текущее положение дел, ему не нужно ждать 2020, он может нарисовать себе внешний препроцессор или даже обертку для компилятора, которые будут предоставлять няшные модули на уровне исходного кода, скрывать факт наличия хедеров, а также предоставлять модули и в компилированном виде тоже, скрывая наличие либ и объектников. Никакой технической проблемы в этом нет. Кому было нужно - запилили - проекты, в которых такое сделано в том или ином виде, иногда встречаются.

>>1065707
Например? Что гуглить?

>>1065707
смешно, да

>>1065530 (OP)
Какие именно проблемы тебя интересуют? Если тебя интересует в целом, откуда там проблемы, то ответ в ОП посте ты уже сам привел - всякое легаси. Из крестов ничего не убирают, это закон и местами даже мем. Если что-то сделано единожды, сделано навсегда. Другого ответа на такой общий вопрос ты не получишь (ну, кроме этого >>1065655). Хочешь конкретики - приводи примеры проблем.

На работе предложили перейти на проект, где процессор на не самой распространенной архитектуре RISCV. Сказали: перестанешь писать на ассемблере, будешь писать только на C++.
Ну и в итоге ни одну задачу не понимаю, как решать на C++. Приходится постоянно работать с регистрами процессора, нужно списывать значения CSR, например, таймера, обращаться к определенным ячейкам памяти - ну и как это все делать на C++? Может я чего-то не понимаю?
Сказали, например, что регистры можно собрать в структуру и обращаться к ним через эту структуру. Как это сделать? Чувствую, что меня наебывают и держат на проекте, которым никто больше не хочет заниматься.

>>1067732
>Сказали, например, что регистры можно собрать в структуру и обращаться к ним через эту структуру
А раньше ты как к ним обращался? Через дефайны?
struct CoreCtlRegBits {
    uint32_t enable:1;
    uint32_t bypass:1;
    ...
};

// union исключительно для удобства. Можно оставить
// что-нибудь одно.
union CoreCtlReg {
    CoreCtlRegBits bits;
    uint32_t value;
};

struct ClockControl {
    volatile CoreCtlReg core_ctl;
    volatile uint32_t core_fraction;
    volatile uint32_t hdmi_clock;
    ...
};

Как ты потом положишь ClockControl clock_ctl по адресу, где у тебя соответствующие регистры - зависит от компилятора. Где-то есть атрибуты, иногда можно линкером положить, можно задефайнить что-нибудь типа #define CLOCK_CONTROL (∗(ClockControl ∗) 0x10001000)

>>1067823
А раньше ты как к ним обращался? Через дефайны?
Наверное раньше он только на ассемблере писал:
>Сказали: перестанешь писать на ассемблере

>по адресу, где у тебя соответствующие регистры
Вот только эти регистры могут находиться в отдельном адресном пространстве, для обращения к которому даже инструкции другие используются. Например как в 8051. Не зря же он отделяет "CSR" и "определенные ячейки памяти".

>>1067732
>не самой распространенной архитектуре RISCV.
Почему не MicroBlaze или Nios II?

>>1065530 (OP)
тред отсоса байтоебов объявился открытым?

>>1067823
>>1067842

Да, регистры лежат в отдельном адресном пространстве.
И сейчас я делаю ассемблерные вставки посреди кода. Например, чтобы записать что-нибудь в один из GPRов: lw s1, 0x1234(x0)
Или списать тот же счетчик времени: rdtime x31
Где можно подробнее прочитать про организацию структур, через которые можно сразу обращаться к регистрам? Глубоких знаний по C++ нет, так что приведенный пример вызывает массу вопросов (что такое enable:1 и bypass:1? как вообще компилятор из такой структуры понимает, что эти переменные относятся к GPR или CSR?)

>>1067853
>Глубоких знаний по C++
А у меня вообще никаких знаний по C++ нет, но это:
>что такое enable:1 и bypass:1?
скорее относится к C, а не C++. Называется это битовыми полями. Для обращения к такому:
>регистры лежат в отдельном адресном пространстве.
использовать скорее всего не получится, судя по тому как это делается в 8051.
Такое можно использовать только для:
>обращаться к определенным ячейкам памяти
Но битовые поля при этом использовать не стоит, т.к. не гарантируется порядок бит, выравнивание и прочее в зависимости от компилятора.

>>1067862
> скорее относится к C, а не C++
А что, в C++ битовые поля Страуструп лично запретил?

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

>>1067935
>Вдалбливают дебилам в говнокнижках.
Например в ARM битовыми полями не пользуются. По твоему там одни дибилы?

>код, работающий с портами напрямую уже привязан к платформе намертво.
Ошибаешься. Во первых речь шла про RISCV, а значит этот процессор почти наверняка сделан на ПЛИС. Это означает что можно будет поменять все вплоть до архитектры процессора.
Во вторых даже если процессор сделан не на ПЛИС, а взят готовый, то это:
>обращаться к определенным ячейкам памяти
может происходить по внешней шине (интерфейс к статической памяти). Например это может быть взаимодействие с ПЛИС или дисплеем. В таком случае возможно изменение типа процессора при сохранении конфигурации ПЛИС.

>>1068080

Вот этот анон верно говорит. Проц сделали на плисине и сейчас ее тестируем.
Верно ли я тогда понимаю, что пока самостоятельно не напишу библиотечку для C/C++ так и буду считывать регистры на ассемблере?

>>1068080
> Например в ARM битовыми полями не пользуются
А мужики-то не знают. Вон выше структурки, которые я приводил, из SDK для ARM SoC известного вендора. Им почему-то норм.

>>1067970
Т.е. знание C++ заставляет его ненавидеть? Что же тогда это за мазохизм?

>>1077267
Обычно переход к плюсам это вынужденная мера. Либо уже есть прототип, и он работает слишком медленно, либо с самого начала вычислительные ресурсы стоят столько, что premature оптимизации быть не может в принципе.
Представь, сколько процессоро-часов сэкономит 1% оптимизации популярной СУБД?
Выбора у тебя не особо много: 1) Си 2) Си с плюсиками 3) Иногда фортран
Из всего этого плюсы наименее кровавые (Си плохо справляется с исключениями, хотя там можнозделоть) и начинаешь писать на плюсах. А этот язык натурально ужасен. Опыт работы на плюсах в пять-шесть лет может завести в психушку.
> Что же тогда это за мазохизм?
Программист это не кодировщик на языке программирования. Ты решаешь задачу. Решение работает медленно. Ты начинаешь его переписывать на плюсах, проклиная жизнь. Свалить эту работу на кого-то другого обычно очень тяжело, так как у "чистого" программиста просто нет нужных знаний в предметной области.

>>1077287
>Выбора у тебя не особо много
Я забыл Rust, который недавно появился на ринге. К сожалению, у Rust нет многих библиотек, которые нельзя линкануть (они сходу забодяжены на плюсовых шаблонах, или используют под капотом капризную библиотеку вроде MPI), зато есть проблемы с векторизацией: язык слишком молодой.

>>1065530 (OP)
А какие с этим проблемы вообще? Хотя я только IDE пользуюсь. И там всё до банальности просто и в несколько шагов.
Сначала в настройках проекта указываешь директорию с иклюдами твоей либы. Потом в препроцессоре дефайны пишешь. Потом в линковщике указываешь путь к либам и там же зависимости дописываешь, которые название подключаемых библиотек. Иногда ещё в самой ОС в переменные среды нужно прописать путь до какой нибудь bin папки из скаченной либы.
Где сложности то? Или я чего-то не понимаю?

>>1077302
Ты достаточно кровавых библиотек не видел просто.

>>1077304
Например

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

PETSc
– Может быть shared, а может быть static
– Версия MPI в приложении и в библиотеке должна точно совпадать
– Версия компилятора обычно должна полностью совпадать
– Типично 3-4 отдельных скомпилированных варианта библиотеки в разных конфигурациях
– Сама библиотека использует ещё десяток библиотек в качестве prerequisites, часть из которых придётся компилировать самому
– Чуть не забыл, саму библиотеку 100% надо компилировать самому
– Иногда приходится фиксить баги прямо внутри библиотеки...
– Библиотеки-prerequisites имеют несколько возможных конфигураций, и у каждой конфигурации отдельный инклюд
– У библиотеки собственный сборочный скрипт, который управляет make
Кажется достаточным адом? Как тебе такой вариант
libMesh
– PETSc это prerequisite, получаешь весь геморр выше
– Библиотека напичкана крестовыми шаблонами, никаких сишных интерфейсов
– В prerequisites ещё несколько крупных библиотек, например, VTK, и они могут иметь разные версии, и работать должна конкретная
– Опять везде нужны одинаковые версии компилятора
– У этой библиотеки опять отдельный сборочный скрипт, который не похож ни на PETSc, ни на CMAKE!
– Тебе обязательно нужно напрямую использовать библиотеки, которые использует PETSc
Кажется достаточным адом? Как тебе такой вариант
MOOSE Framework
– libMesh это prerequisite, получаешь весь геморр выше, до самого начала поста
– Цепочка зависимостей разрастается до неприличных глубин (например, для MOOSE нужен libMesh, для libMesh нужен PARMETIS, для PARMETIS нужен METIS. Это только самый очевидный путь и, готов поспорить, не самый короткий.
Кажется достаточным адом? Как тебе такой вариант
– Теперь тебе надо скомпилировать PETSc, чтобы вся эта колда работала на видоекартах. Теперь ты билдишь код для видеокарт с помощью nvcc (у него под капотом gcc), всё остальное icpc, а потом всё это дело линкаешь.

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

>>1077323
>и, готов поспорить, не самый короткий.
Не самый длинный

>>1077323
Спаси меня жвм от нечистых безумцев!

>>1077356
Если бы это можно было написать на жабе (а лучше на шарпе или скале), я бы написал, мамой клянусь.

>>1077287
>А этот язык натурально ужасен.
Ой ой ой, ну надо же, оказывается понимание архитектуры системы, понимание тонкостей работы с указателями и прочее что необходимо для оптимизации это теперь "ужасность языка". Это не ужасность языка, а сложность современного софта и железа которые нужно знать чтобы что-то сделать и не только знать, а еще и выстраивать все эти ебические логические конструкции оптимизации и держать их в голове. Но стоит только начать писать на жаве, где нихуя нет никаких указателей и тебя совершенно не ебет что там в памяти так внезапно язык становиться прекрасным. Ну так может тогда не стоит углубляться в ебическую оптимизацию, неделями дроча на профайлер и все ок будет? Сам язык то ту причем?

>>1065530 (OP)
Во первых оп хуй, потому-что два треда вниз есть C++ тред.
Во вторых толи я не понял вопрос, толи я не понял в чём сложность прописать одну строку include.

>>1077504
Тебе говорят, что ПЛЮСЫ ЕТО ГОВНО, але блядь, а ты про архитектуру системы начинаешь. Говеный язык с говеной инфраструктурой и говеным КОММЬЮНИТИ, на котором нормальный человек будет писать только в ситуации, описанной >>1077287-аноном. раст приде порядок наведе

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

Лично я вижу в этом >>1077287 посте долбоеба, который тупо не осилил С++ и понимание его возможностей вызывает у этой обезъяны головную боль, буквально. Ему комфортно писать на жава говне, а потом оказывается что она хуево работает и нужно было на плюсах писать. Это не тупая жава виновата, а С++ плохой, лол.

Парад ебанутых клоунов.

>>1077287
>Когда я устраивался работать программистом я думал что буду просто кнопочки на формочки шлёпать
>А тут оказывается СЛОЖНА
>Маи программы работают медленно
>Надо писать быстрые а это СЛОЖНА
В голосину с этого поста просто.

>>1077705
> Это не тупая жава виновата, а С++ плохой, лол.
Чувак, в параде ёбаных клоунов ты идёшь в первой колонне и несёшь флаг ёбаных клоунов.
> Compiler vectorization support in HotSpot was improved a lot lately (June 2017) due to contributions by Intel. Performance-wise the yet unreleased jdk9 (b163 and later) currently wins over jdk8 due to bug-fixes enabling AVX2. Loops must fulfill a few constraints for auto-vectorization to work, e.g. use: int counter, constant counter increment, one termination condition with loop-invariant variables, loop body without method calls(?), no manual loop unfolding! Details are available in: cr.openjdk.java.net/~vlivanov/talks/…
В жабе до сих пор нет нормальной векторизации, и до сих пор нельзя нормально писать код под ускорители (и никогда будет нельзя). Ты как макака этого знать не можешь, так как не осилил векторизацию. Можешь себя опущенным считать.
>>1077932
Ты идёшь за ёбаным клоуном >>1077705
Мои программы работают быстро. Они работают на ферме из сотни нод с Tesla'ми. Когда вы сможете это переписать на Java, тогда приходите, а пока предлагаю вам, петухам, отправиться к своей параше.

>>1065530 (OP)
> C++
Нинужное говно без задач.

>>1077996
Шизофреник разбушевался! Клоун, ты вообще в последовательность беседы можешь? Нахуй ты мне пишешь про векторизацию в жаве, ты сам с собой разговариваешь? И да - жава по умолчанию медленнее с++ т.к. она выполняется на виртуальной машине, а на плюсах можно писать нативные приложения, ты клоун даже в логику не можешь.

По тебе четко видно, что твой мозг тупо не осилил плюсы, для тебя СЛОЖНА использовать и знать низкоуровневые приемы работы с памятью и архитектуру системы, для твоего балезного мозга проще вообще об этом не думать и как психологическую компенсацию своей ущербности ты не признаешь себя тупым, а говоришь, что это с++ говно.

Ты просто очередной клоун на параде тупых.

>>1078099
> И да - жава по умолчанию медленнее с++ т.к. она выполняется на виртуальной машине
Это по сути не верно с учётом JIT.
Вейт, нет, с тобой я разговаривать не буду, прими вначале нейролептики.

>>1067847
Кто нибудь понял, что он имел ввиду?

>>1078099
>И да - жава по умолчанию медленнее с++
Адаптивная оптимизация HotSpot.

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

JIT в v8 — давно уже вплотную приблизился по скорости к нативному C,C++. Прямую ссылку не дам, но пару лет назад на конференции разрабов Unity3D — достаточно подробно тему проивзодительности JS в современных браузерах обсасывали. Меня тогда очень поразило, что связка C#->LLVM->ASM.JS уже тогда могла работать быстрее чем нативный C#->IL->JIT из MONO 2.10 в unity3d.

>>1065530 (OP)
Поясните ньюфане по поводу второй пикчи. В чём цимус? В том, что это Сишные либы?

>>1082296

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

>>1082161
>JIT в v8 — давно уже вплотную приблизился по скорости к нативному C,C++
Вплотную это в 8 раз медленнее? "Вплотную" - это по сравнению со всяким скриптоговном, которое обычно в 20 раз медленее и более.
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=gpp
Можешь еще потребление памяти сравнить.

>Адаптивная оптимизация HotSpot
Мммм... Hotspot. Я это еще в 2005 слышал. Как говорится, времена меняются, java все так же тормозит.

>>1066066
>Из крестов ничего не убирают, это закон и местами даже мем
Помоши ручкой в могилку auto_ptr и прочих триграфов

>>1068127
Ебани на хаскеле обертку всей низкоуровневой шелухи, и работай с ней как король.

>>1082335
Живой ньюфаг! Путает жабу и жабаскрипт! В 2к17!

>>1082436

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

>>1082441
Зашквар и параша, нет нормального компилятора, убогий синтаксис. На помойку вместе с адой и паскалем.

>>1082436
Давайте разберём часто встречающиеся комбинации.
C+Fortran=чухан-байтоёб.
Haskell+Lisp=чёрт-борщехлёб.
PHP+JS=Обиженка-пыхомразь (считаю самое зашкварное сочетание)
Java=Энтерпрайзогребец, мужик
Ruby+F#+JS=Продвинутый веб-макак, мужик
Python+C=Юникс-программист, мужик
Java+Scala/Haskell=Крутой энтерпрайзогребец, стремящийся
C#+F#=Крутой спермогребец, стремящийся
C++, Java, Scala, Haskell, Python, Ruby=Вор и блатной, коронуем в хате
C#+F#+Haskell+C+++JS=Евангелист майкрософт, коронуем в хает

>>1082446
Python + C++\C + PHP + JS + Lua + Go - я чухан?

>>1082794
Мужик, если за Go в хате сможешь пояснить и обосновать, то вообще стремящийся.

>>1082794
>я чухан
да

>>1083476
> не гринтекстит знак вопроса
> отвечает на вопрос
Чухан детектед

Я контрибьютор glibc и gcc и я нихуя не понял, о чем ОП. Какая бывает линковка и как она работает не понимаешь? Что такое юниты компиляции не понимаешь? В чем разница между инклудами и линковкой не понимаешь? Рот ебал, ботай матчасть.

>>1084019
+ добавлю, сейчас уже отлично работает линк тайм оптимизации. Так что уже все настолько пиздато, насколько можно.

>>1084020
Но всё равно, стервец, в два раза медленее icpc