Этого треда уже нет.
Это копия, сохраненная 23 ноября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 23 ноября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Олдфаги приглашаются в тред
Я думаю многие знают какие по истинне гумозные трудности представляет собой сборка, подключение библиотек и различные операции с include в C++.
У всех кого я спрашивал - отвечали, что это связанно с тяжелым прошлым C++ и тогда сделать подобного рода хуйню - казалось очень умной и здравой затеей.
Могут ли олдфаги или просто знающие пояснить - почему так исторически сложилось?
Тут бампать можно или чего? Ну я бампну пару раз, вы меня только не баньте
Я думаю многие знают какие по истинне гумозные трудности представляет собой сборка, подключение библиотек и различные операции с include в C++.
У всех кого я спрашивал - отвечали, что это связанно с тяжелым прошлым C++ и тогда сделать подобного рода хуйню - казалось очень умной и здравой затеей.
Могут ли олдфаги или просто знающие пояснить - почему так исторически сложилось?
Тут бампать можно или чего? Ну я бампну пару раз, вы меня только не баньте
>>1065530 (OP)
Однопроходный компилятор. </thread>
Однопроходный компилятор. </thread>
>>1065691
Скорее всего нет, добьют году к двадцатому:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4681.pdf
>Т.е. эта проблема с C++ навсегда?
Скорее всего нет, добьют году к двадцатому:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4681.pdf
>>1065702
Даже если добьют, останется куча легаси. А если ОПу не нравится текущее положение дел, ему не нужно ждать 2020, он может нарисовать себе внешний препроцессор или даже обертку для компилятора, которые будут предоставлять няшные модули на уровне исходного кода, скрывать факт наличия хедеров, а также предоставлять модули и в компилированном виде тоже, скрывая наличие либ и объектников. Никакой технической проблемы в этом нет. Кому было нужно - запилили - проекты, в которых такое сделано в том или ином виде, иногда встречаются.
Даже если добьют, останется куча легаси. А если ОПу не нравится текущее положение дел, ему не нужно ждать 2020, он может нарисовать себе внешний препроцессор или даже обертку для компилятора, которые будут предоставлять няшные модули на уровне исходного кода, скрывать факт наличия хедеров, а также предоставлять модули и в компилированном виде тоже, скрывая наличие либ и объектников. Никакой технической проблемы в этом нет. Кому было нужно - запилили - проекты, в которых такое сделано в том или ином виде, иногда встречаются.
>>1065707
Например? Что гуглить?
Например? Что гуглить?
>>1065707
смешно, да
смешно, да
>>1065530 (OP)
Какие именно проблемы тебя интересуют? Если тебя интересует в целом, откуда там проблемы, то ответ в ОП посте ты уже сам привел - всякое легаси. Из крестов ничего не убирают, это закон и местами даже мем. Если что-то сделано единожды, сделано навсегда. Другого ответа на такой общий вопрос ты не получишь (ну, кроме этого >>1065655). Хочешь конкретики - приводи примеры проблем.
Какие именно проблемы тебя интересуют? Если тебя интересует в целом, откуда там проблемы, то ответ в ОП посте ты уже сам привел - всякое легаси. Из крестов ничего не убирают, это закон и местами даже мем. Если что-то сделано единожды, сделано навсегда. Другого ответа на такой общий вопрос ты не получишь (ну, кроме этого >>1065655). Хочешь конкретики - приводи примеры проблем.
На работе предложили перейти на проект, где процессор на не самой распространенной архитектуре RISCV. Сказали: перестанешь писать на ассемблере, будешь писать только на C++.
Ну и в итоге ни одну задачу не понимаю, как решать на C++. Приходится постоянно работать с регистрами процессора, нужно списывать значения CSR, например, таймера, обращаться к определенным ячейкам памяти - ну и как это все делать на 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)
>Сказали, например, что регистры можно собрать в структуру и обращаться к ним через эту структуру
А раньше ты как к ним обращался? Через дефайны?
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
Почему не MicroBlaze или Nios II?
А раньше ты как к ним обращался? Через дефайны?
Наверное раньше он только на ассемблере писал:
>Сказали: перестанешь писать на ассемблере
>по адресу, где у тебя соответствующие регистры
Вот только эти регистры могут находиться в отдельном адресном пространстве, для обращения к которому даже инструкции другие используются. Например как в 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?)
>>1067842
Да, регистры лежат в отдельном адресном пространстве.
И сейчас я делаю ассемблерные вставки посреди кода. Например, чтобы записать что-нибудь в один из GPRов: lw s1, 0x1234(x0)
Или списать тот же счетчик времени: rdtime x31
Где можно подробнее прочитать про организацию структур, через которые можно сразу обращаться к регистрам? Глубоких знаний по C++ нет, так что приведенный пример вызывает массу вопросов (что такое enable:1 и bypass:1? как вообще компилятор из такой структуры понимает, что эти переменные относятся к GPR или CSR?)
>>1067853
А у меня вообще никаких знаний по C++ нет, но это:
скорее относится к C, а не C++. Называется это битовыми полями. Для обращения к такому:
использовать скорее всего не получится, судя по тому как это делается в 8051.
Такое можно использовать только для:
Но битовые поля при этом использовать не стоит, т.к. не гарантируется порядок бит, выравнивание и прочее в зависимости от компилятора.
>Глубоких знаний по C++
А у меня вообще никаких знаний по C++ нет, но это:
>что такое enable:1 и bypass:1?
скорее относится к C, а не C++. Называется это битовыми полями. Для обращения к такому:
>регистры лежат в отдельном адресном пространстве.
использовать скорее всего не получится, судя по тому как это делается в 8051.
Такое можно использовать только для:
>обращаться к определенным ячейкам памяти
Но битовые поля при этом использовать не стоит, т.к. не гарантируется порядок бит, выравнивание и прочее в зависимости от компилятора.
>>1067862
А что, в C++ битовые поля Страуструп лично запретил?
Вдалбливают дебилам в говнокнижках. В embedded у тебя один, максимум два компилятора на платформу, а в пределах компилятора все гарантируется (да и вообще в большинстве компиляторов есть соответствующие ключики, потому что мир стандартом языка не ограничивается). И о переносимости кукарекать не нужно, потому что код, работающий с портами напрямую уже привязан к платформе намертво.
> скорее относится к C, а не C++
А что, в C++ битовые поля Страуструп лично запретил?
> не гарантируется порядок бит
Вдалбливают дебилам в говнокнижках. В embedded у тебя один, максимум два компилятора на платформу, а в пределах компилятора все гарантируется (да и вообще в большинстве компиляторов есть соответствующие ключики, потому что мир стандартом языка не ограничивается). И о переносимости кукарекать не нужно, потому что код, работающий с портами напрямую уже привязан к платформе намертво.
36,8 Мб, webm, 1280x720, 4:53
Множества тех, кто знает C++ и тех, кто Любит - не пересекаются.
>>1067935
Например в ARM битовыми полями не пользуются. По твоему там одни дибилы?
Ошибаешься. Во первых речь шла про RISCV, а значит этот процессор почти наверняка сделан на ПЛИС. Это означает что можно будет поменять все вплоть до архитектры процессора.
Во вторых даже если процессор сделан не на ПЛИС, а взят готовый, то это:
может происходить по внешней шине (интерфейс к статической памяти). Например это может быть взаимодействие с ПЛИС или дисплеем. В таком случае возможно изменение типа процессора при сохранении конфигурации ПЛИС.
>Вдалбливают дебилам в говнокнижках.
Например в ARM битовыми полями не пользуются. По твоему там одни дибилы?
>код, работающий с портами напрямую уже привязан к платформе намертво.
Ошибаешься. Во первых речь шла про RISCV, а значит этот процессор почти наверняка сделан на ПЛИС. Это означает что можно будет поменять все вплоть до архитектры процессора.
Во вторых даже если процессор сделан не на ПЛИС, а взят готовый, то это:
>обращаться к определенным ячейкам памяти
может происходить по внешней шине (интерфейс к статической памяти). Например это может быть взаимодействие с ПЛИС или дисплеем. В таком случае возможно изменение типа процессора при сохранении конфигурации ПЛИС.
>>1068080
Вот этот анон верно говорит. Проц сделали на плисине и сейчас ее тестируем.
Верно ли я тогда понимаю, что пока самостоятельно не напишу библиотечку для C/C++ так и буду считывать регистры на ассемблере?
Вот этот анон верно говорит. Проц сделали на плисине и сейчас ее тестируем.
Верно ли я тогда понимаю, что пока самостоятельно не напишу библиотечку для C/C++ так и буду считывать регистры на ассемблере?
>>1068080
А мужики-то не знают. Вон выше структурки, которые я приводил, из SDK для ARM SoC известного вендора. Им почему-то норм.
> Например в ARM битовыми полями не пользуются
А мужики-то не знают. Вон выше структурки, которые я приводил, из SDK для ARM SoC известного вендора. Им почему-то норм.
>>1077267
Обычно переход к плюсам это вынужденная мера. Либо уже есть прототип, и он работает слишком медленно, либо с самого начала вычислительные ресурсы стоят столько, что premature оптимизации быть не может в принципе.
Представь, сколько процессоро-часов сэкономит 1% оптимизации популярной СУБД?
Выбора у тебя не особо много: 1) Си 2) Си с плюсиками 3) Иногда фортран
Из всего этого плюсы наименее кровавые (Си плохо справляется с исключениями, хотя там можнозделоть) и начинаешь писать на плюсах. А этот язык натурально ужасен. Опыт работы на плюсах в пять-шесть лет может завести в психушку.
Программист это не кодировщик на языке программирования. Ты решаешь задачу. Решение работает медленно. Ты начинаешь его переписывать на плюсах, проклиная жизнь. Свалить эту работу на кого-то другого обычно очень тяжело, так как у "чистого" программиста просто нет нужных знаний в предметной области.
Обычно переход к плюсам это вынужденная мера. Либо уже есть прототип, и он работает слишком медленно, либо с самого начала вычислительные ресурсы стоят столько, что premature оптимизации быть не может в принципе.
Представь, сколько процессоро-часов сэкономит 1% оптимизации популярной СУБД?
Выбора у тебя не особо много: 1) Си 2) Си с плюсиками 3) Иногда фортран
Из всего этого плюсы наименее кровавые (Си плохо справляется с исключениями, хотя там можнозделоть) и начинаешь писать на плюсах. А этот язык натурально ужасен. Опыт работы на плюсах в пять-шесть лет может завести в психушку.
> Что же тогда это за мазохизм?
Программист это не кодировщик на языке программирования. Ты решаешь задачу. Решение работает медленно. Ты начинаешь его переписывать на плюсах, проклиная жизнь. Свалить эту работу на кого-то другого обычно очень тяжело, так как у "чистого" программиста просто нет нужных знаний в предметной области.
>>1077287
Я забыл Rust, который недавно появился на ринге. К сожалению, у Rust нет многих библиотек, которые нельзя линкануть (они сходу забодяжены на плюсовых шаблонах, или используют под капотом капризную библиотеку вроде MPI), зато есть проблемы с векторизацией: язык слишком молодой.
>Выбора у тебя не особо много
Я забыл Rust, который недавно появился на ринге. К сожалению, у Rust нет многих библиотек, которые нельзя линкануть (они сходу забодяжены на плюсовых шаблонах, или используют под капотом капризную библиотеку вроде MPI), зато есть проблемы с векторизацией: язык слишком молодой.
>>1065530 (OP)
А какие с этим проблемы вообще? Хотя я только IDE пользуюсь. И там всё до банальности просто и в несколько шагов.
Сначала в настройках проекта указываешь директорию с иклюдами твоей либы. Потом в препроцессоре дефайны пишешь. Потом в линковщике указываешь путь к либам и там же зависимости дописываешь, которые название подключаемых библиотек. Иногда ещё в самой ОС в переменные среды нужно прописать путь до какой нибудь bin папки из скаченной либы.
Где сложности то? Или я чего-то не понимаю?
А какие с этим проблемы вообще? Хотя я только IDE пользуюсь. И там всё до банальности просто и в несколько шагов.
Сначала в настройках проекта указываешь директорию с иклюдами твоей либы. Потом в препроцессоре дефайны пишешь. Потом в линковщике указываешь путь к либам и там же зависимости дописываешь, которые название подключаемых библиотек. Иногда ещё в самой ОС в переменные среды нужно прописать путь до какой нибудь bin папки из скаченной либы.
Где сложности то? Или я чего-то не понимаю?
>>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 и компилятора
Даже не верю, что я отвечаю пидору, который не удосужился поставить вопросительный знак. Ну ладно, народ надо обучать, держи пример.
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 и компилятора
>>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 и компилятора
Даже не верю, что я отвечаю пидору, который не удосужился поставить вопросительный знак. Ну ладно, народ надо обучать, держи пример.
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 и компилятора
>>1077356
Если бы это можно было написать на жабе (а лучше на шарпе или скале), я бы написал, мамой клянусь.
Если бы это можно было написать на жабе (а лучше на шарпе или скале), я бы написал, мамой клянусь.
>>1077287
Ой ой ой, ну надо же, оказывается понимание архитектуры системы, понимание тонкостей работы с указателями и прочее что необходимо для оптимизации это теперь "ужасность языка". Это не ужасность языка, а сложность современного софта и железа которые нужно знать чтобы что-то сделать и не только знать, а еще и выстраивать все эти ебические логические конструкции оптимизации и держать их в голове. Но стоит только начать писать на жаве, где нихуя нет никаких указателей и тебя совершенно не ебет что там в памяти так внезапно язык становиться прекрасным. Ну так может тогда не стоит углубляться в ебическую оптимизацию, неделями дроча на профайлер и все ок будет? Сам язык то ту причем?
>А этот язык натурально ужасен.
Ой ой ой, ну надо же, оказывается понимание архитектуры системы, понимание тонкостей работы с указателями и прочее что необходимо для оптимизации это теперь "ужасность языка". Это не ужасность языка, а сложность современного софта и железа которые нужно знать чтобы что-то сделать и не только знать, а еще и выстраивать все эти ебические логические конструкции оптимизации и держать их в голове. Но стоит только начать писать на жаве, где нихуя нет никаких указателей и тебя совершенно не ебет что там в памяти так внезапно язык становиться прекрасным. Ну так может тогда не стоит углубляться в ебическую оптимизацию, неделями дроча на профайлер и все ок будет? Сам язык то ту причем?
>>1065530 (OP)
Во первых оп хуй, потому-что два треда вниз есть C++ тред.
Во вторых толи я не понял вопрос, толи я не понял в чём сложность прописать одну строку include.
Во первых оп хуй, потому-что два треда вниз есть C++ тред.
Во вторых толи я не понял вопрос, толи я не понял в чём сложность прописать одну строку include.
>>1077667
Долбоеб, ты серишь, тебе этот чувак прямым текстом написал что вынужденность возникает из-за необходимости низкоуровневой оптимизации т.к. плюсы имеют доступ к низкому уровню, а вское жава говно нет. При этом он делает охуетельное заявление, что плюсы оказывается говно.
Лично я вижу в этом >>1077287 посте долбоеба, который тупо не осилил С++ и понимание его возможностей вызывает у этой обезъяны головную боль, буквально. Ему комфортно писать на жава говне, а потом оказывается что она хуево работает и нужно было на плюсах писать. Это не тупая жава виновата, а С++ плохой, лол.
Парад ебанутых клоунов.
Долбоеб, ты серишь, тебе этот чувак прямым текстом написал что вынужденность возникает из-за необходимости низкоуровневой оптимизации т.к. плюсы имеют доступ к низкому уровню, а вское жава говно нет. При этом он делает охуетельное заявление, что плюсы оказывается говно.
Лично я вижу в этом >>1077287 посте долбоеба, который тупо не осилил С++ и понимание его возможностей вызывает у этой обезъяны головную боль, буквально. Ему комфортно писать на жава говне, а потом оказывается что она хуево работает и нужно было на плюсах писать. Это не тупая жава виновата, а С++ плохой, лол.
Парад ебанутых клоунов.
>>1077287
В голосину с этого поста просто.
>Когда я устраивался работать программистом я думал что буду просто кнопочки на формочки шлёпать
>А тут оказывается СЛОЖНА
>Маи программы работают медленно
>Надо писать быстрые а это СЛОЖНА
В голосину с этого поста просто.
>>1077705
Чувак, в параде ёбаных клоунов ты идёшь в первой колонне и несёшь флаг ёбаных клоунов.
В жабе до сих пор нет нормальной векторизации, и до сих пор нельзя нормально писать код под ускорители (и никогда будет нельзя). Ты как макака этого знать не можешь, так как не осилил векторизацию. Можешь себя опущенным считать.
>>1077932
Ты идёшь за ёбаным клоуном >>1077705
Мои программы работают быстро. Они работают на ферме из сотни нод с Tesla'ми. Когда вы сможете это переписать на Java, тогда приходите, а пока предлагаю вам, петухам, отправиться к своей параше.
> Это не тупая жава виновата, а С++ плохой, лол.
Чувак, в параде ёбаных клоунов ты идёшь в первой колонне и несёшь флаг ёбаных клоунов.
> 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, тогда приходите, а пока предлагаю вам, петухам, отправиться к своей параше.
>>1077996
Шизофреник разбушевался! Клоун, ты вообще в последовательность беседы можешь? Нахуй ты мне пишешь про векторизацию в жаве, ты сам с собой разговариваешь? И да - жава по умолчанию медленнее с++ т.к. она выполняется на виртуальной машине, а на плюсах можно писать нативные приложения, ты клоун даже в логику не можешь.
По тебе четко видно, что твой мозг тупо не осилил плюсы, для тебя СЛОЖНА использовать и знать низкоуровневые приемы работы с памятью и архитектуру системы, для твоего балезного мозга проще вообще об этом не думать и как психологическую компенсацию своей ущербности ты не признаешь себя тупым, а говоришь, что это с++ говно.
Ты просто очередной клоун на параде тупых.
Шизофреник разбушевался! Клоун, ты вообще в последовательность беседы можешь? Нахуй ты мне пишешь про векторизацию в жаве, ты сам с собой разговариваешь? И да - жава по умолчанию медленнее с++ т.к. она выполняется на виртуальной машине, а на плюсах можно писать нативные приложения, ты клоун даже в логику не можешь.
По тебе четко видно, что твой мозг тупо не осилил плюсы, для тебя СЛОЖНА использовать и знать низкоуровневые приемы работы с памятью и архитектуру системы, для твоего балезного мозга проще вообще об этом не думать и как психологическую компенсацию своей ущербности ты не признаешь себя тупым, а говоришь, что это с++ говно.
Ты просто очередной клоун на параде тупых.
>>1078099
Это по сути не верно с учётом JIT.
Вейт, нет, с тобой я разговаривать не буду, прими вначале нейролептики.
> И да - жава по умолчанию медленнее с++ т.к. она выполняется на виртуальной машине
Это по сути не верно с учётом JIT.
Вейт, нет, с тобой я разговаривать не буду, прими вначале нейролептики.
>>1067847
Кто нибудь понял, что он имел ввиду?
Кто нибудь понял, что он имел ввиду?
>>1078099
Адаптивная оптимизация HotSpot.
"HotSpot часто называют самой производительной виртуальной машиной Java в своем классе. В теории с помощью адаптивной оптимизации программа, которая выполняется в этой JVM может быть более производительной, чем эквивалентная ей программа в машинных кодах".
JIT в v8 — давно уже вплотную приблизился по скорости к нативному C,C++. Прямую ссылку не дам, но пару лет назад на конференции разрабов Unity3D — достаточно подробно тему проивзодительности JS в современных браузерах обсасывали. Меня тогда очень поразило, что связка C#->LLVM->ASM.JS уже тогда могла работать быстрее чем нативный C#->IL->JIT из MONO 2.10 в unity3d.
>И да - жава по умолчанию медленнее с++
Адаптивная оптимизация HotSpot.
"HotSpot часто называют самой производительной виртуальной машиной Java в своем классе. В теории с помощью адаптивной оптимизации программа, которая выполняется в этой JVM может быть более производительной, чем эквивалентная ей программа в машинных кодах".
JIT в v8 — давно уже вплотную приблизился по скорости к нативному C,C++. Прямую ссылку не дам, но пару лет назад на конференции разрабов Unity3D — достаточно подробно тему проивзодительности JS в современных браузерах обсасывали. Меня тогда очень поразило, что связка C#->LLVM->ASM.JS уже тогда могла работать быстрее чем нативный C#->IL->JIT из MONO 2.10 в unity3d.
>>1065530 (OP)
Поясните ньюфане по поводу второй пикчи. В чём цимус? В том, что это Сишные либы?
Поясните ньюфане по поводу второй пикчи. В чём цимус? В том, что это Сишные либы?
>>1082161
Вплотную это в 8 раз медленнее? "Вплотную" - это по сравнению со всяким скриптоговном, которое обычно в 20 раз медленее и более.
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=gpp
Можешь еще потребление памяти сравнить.
Мммм... Hotspot. Я это еще в 2005 слышал. Как говорится, времена меняются, java все так же тормозит.
>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 и прочих триграфов
>Из крестов ничего не убирают, это закон и местами даже мем
Помоши ручкой в могилку auto_ptr и прочих триграфов
>>1082335
Живой ньюфаг! Путает жабу и жабаскрипт! В 2к17!
Живой ньюфаг! Путает жабу и жабаскрипт! В 2к17!
103 Кб, 700x975
>>1082335
Давайте разберёмся. У нас есть прямо тиры
1) C-tier
Входит си, плюсы, раст и фортран
(прим. авт.: на пике фортран во втором тире, так как не нашлось программиста, который бы хорошо писал на фортране)
Отличается самой высокой скоростью работы, прекрасной векторизацией, суперсовременными компиляторами. Весь код, который должен работать быстро, пишется на C-tier, и самым компромиссным языком из C-tier являются плюсы.
Нет смысла расчехлять C-tier, если большая часть программы (СУБД, математическая библиотека, движок) и так на нём написана, но это определённо единственный выбор для производительного софта. А производительный софт ни на чём другом особо и не пишут. Мало кто знает, но кто действительно хорошо знает -- хороший программист. Если человек не умеет писать за пределами этой группы, то он байтоёб, опущенный.
2) Java/C#-tier
Отстаёт от C-tier в скромных два раза, при этом поддерживается сборка мусора.
(прим. авт.: Ada, которая не поддерживает сборку мусора -- просто бесполезное говно, которое зря попало в бенчмарки, мусорный язык)
Писать гораздо быстрее и легче, используются для написания тяжёлой операционной логики, а шарп хорош и для десктоп-приложений.
Отличные языки "по умолчанию", позволяют разрабатывать быстро, и сохраняют _очень_ близкую к родной производительность.
Эти языки используют больше памяти, но сборка мусора на самом деле является более совершенным решением с точки зрения производительности "средней" программы: выделение памяти с помощью new проихсодит быстрее, чем при ручном управлении памятью, и это даёт определённые преимущества в том случае, если память есть в избытке. Сравнивать по объёму памяти языки с GC и ручным управлением памятью гатегорически неправильно: программы используют очень разные стратегии.
Java, C#, Scala, Swift, Objective C и, может быть, Golang -- наименее зашкварные языки, воровские и блатные. Уже достаточно далеки от байтоёбства, но и до тупого крудошлёпства ещё далеко. Можно хорошо знать один-два языка этой группы и не горевать.
3) Академический tier
Тут живут языки, которые никогда не используются в продакшене. Затесался паршивый паскаль. Для каких-то индустриальных нужд категорически непригодны. Никто не пишет. Многие знают, уметь писать на хаскелле, лиспе или ocaml/F# -- не зашквар. Человек, который не умеет писать за пределами третей группы -- уже зашкварный борщехлёб, опущенный.
4) Пыхоплеяда-tier
Группа совместного отсоса по производительности. Можно использовать только в одном случае: 99% времени работает не ваша программа, а СУБД или математическая библиотека. Чаще всего используются в наиболее нетребовательных к производительности приложениях наиболее низкоквалифицированными программистами (эти люди, однако, могут иметь высокую квалификацию в предметно области -- тогда их записываем в мужики). В пыхоплеяде есть три подгруппы. "Удачные, но тормозные" python и ruby отлично подходят для относительно простых задач вроде веб-девелопмента, калькуляторов, прототипов и скриптов. "По горло в легаси-говне" JS, производные JS и Lua используются потому, что их пользователи по горло в легаси-говне. Это самые опущенские языки программирования, на них пишут петухи программача, от природы тупые и обиженные хуесосы. "Даже легаси на этом поддерживтать стыдно" в виде Perl, Smalltalk и прочего винтажа помещают своих пользователей под толстый слой говна. Это уже зашквар без разговоров.
Немного отдельно от пыхоплеяды стоит Erlang: у него очень специфическая область применения.
В общем, резюме. Люди, которые знают языки из категорий пикрелейтеда (по крайней мере один из соотв. группы):
Одновременно 1, 2, 3, 4: воры, блатные, элита программача.
2 и один-два из 1, 3 или 4 на выбор: стремящиеся.
Только 2 или 3 и 4, или 1 и 4: мужики.
Только 4: обиженки.
Только 3: черти.
Только 1: чуханы.
1 и 3: козлы.
Давайте разберёмся. У нас есть прямо тиры
1) C-tier
Входит си, плюсы, раст и фортран
(прим. авт.: на пике фортран во втором тире, так как не нашлось программиста, который бы хорошо писал на фортране)
Отличается самой высокой скоростью работы, прекрасной векторизацией, суперсовременными компиляторами. Весь код, который должен работать быстро, пишется на C-tier, и самым компромиссным языком из C-tier являются плюсы.
Нет смысла расчехлять C-tier, если большая часть программы (СУБД, математическая библиотека, движок) и так на нём написана, но это определённо единственный выбор для производительного софта. А производительный софт ни на чём другом особо и не пишут. Мало кто знает, но кто действительно хорошо знает -- хороший программист. Если человек не умеет писать за пределами этой группы, то он байтоёб, опущенный.
2) Java/C#-tier
Отстаёт от C-tier в скромных два раза, при этом поддерживается сборка мусора.
(прим. авт.: Ada, которая не поддерживает сборку мусора -- просто бесполезное говно, которое зря попало в бенчмарки, мусорный язык)
Писать гораздо быстрее и легче, используются для написания тяжёлой операционной логики, а шарп хорош и для десктоп-приложений.
Отличные языки "по умолчанию", позволяют разрабатывать быстро, и сохраняют _очень_ близкую к родной производительность.
Эти языки используют больше памяти, но сборка мусора на самом деле является более совершенным решением с точки зрения производительности "средней" программы: выделение памяти с помощью new проихсодит быстрее, чем при ручном управлении памятью, и это даёт определённые преимущества в том случае, если память есть в избытке. Сравнивать по объёму памяти языки с GC и ручным управлением памятью гатегорически неправильно: программы используют очень разные стратегии.
Java, C#, Scala, Swift, Objective C и, может быть, Golang -- наименее зашкварные языки, воровские и блатные. Уже достаточно далеки от байтоёбства, но и до тупого крудошлёпства ещё далеко. Можно хорошо знать один-два языка этой группы и не горевать.
3) Академический tier
Тут живут языки, которые никогда не используются в продакшене. Затесался паршивый паскаль. Для каких-то индустриальных нужд категорически непригодны. Никто не пишет. Многие знают, уметь писать на хаскелле, лиспе или ocaml/F# -- не зашквар. Человек, который не умеет писать за пределами третей группы -- уже зашкварный борщехлёб, опущенный.
4) Пыхоплеяда-tier
Группа совместного отсоса по производительности. Можно использовать только в одном случае: 99% времени работает не ваша программа, а СУБД или математическая библиотека. Чаще всего используются в наиболее нетребовательных к производительности приложениях наиболее низкоквалифицированными программистами (эти люди, однако, могут иметь высокую квалификацию в предметно области -- тогда их записываем в мужики). В пыхоплеяде есть три подгруппы. "Удачные, но тормозные" python и ruby отлично подходят для относительно простых задач вроде веб-девелопмента, калькуляторов, прототипов и скриптов. "По горло в легаси-говне" JS, производные JS и Lua используются потому, что их пользователи по горло в легаси-говне. Это самые опущенские языки программирования, на них пишут петухи программача, от природы тупые и обиженные хуесосы. "Даже легаси на этом поддерживтать стыдно" в виде Perl, Smalltalk и прочего винтажа помещают своих пользователей под толстый слой говна. Это уже зашквар без разговоров.
Немного отдельно от пыхоплеяды стоит Erlang: у него очень специфическая область применения.
В общем, резюме. Люди, которые знают языки из категорий пикрелейтеда (по крайней мере один из соотв. группы):
Одновременно 1, 2, 3, 4: воры, блатные, элита программача.
2 и один-два из 1, 3 или 4 на выбор: стремящиеся.
Только 2 или 3 и 4, или 1 и 4: мужики.
Только 4: обиженки.
Только 3: черти.
Только 1: чуханы.
1 и 3: козлы.
103 Кб, 700x975
>>1082335
Давайте разберёмся. У нас есть прямо тиры
1) C-tier
Входит си, плюсы, раст и фортран
(прим. авт.: на пике фортран во втором тире, так как не нашлось программиста, который бы хорошо писал на фортране)
Отличается самой высокой скоростью работы, прекрасной векторизацией, суперсовременными компиляторами. Весь код, который должен работать быстро, пишется на C-tier, и самым компромиссным языком из C-tier являются плюсы.
Нет смысла расчехлять C-tier, если большая часть программы (СУБД, математическая библиотека, движок) и так на нём написана, но это определённо единственный выбор для производительного софта. А производительный софт ни на чём другом особо и не пишут. Мало кто знает, но кто действительно хорошо знает -- хороший программист. Если человек не умеет писать за пределами этой группы, то он байтоёб, опущенный.
2) Java/C#-tier
Отстаёт от C-tier в скромных два раза, при этом поддерживается сборка мусора.
(прим. авт.: Ada, которая не поддерживает сборку мусора -- просто бесполезное говно, которое зря попало в бенчмарки, мусорный язык)
Писать гораздо быстрее и легче, используются для написания тяжёлой операционной логики, а шарп хорош и для десктоп-приложений.
Отличные языки "по умолчанию", позволяют разрабатывать быстро, и сохраняют _очень_ близкую к родной производительность.
Эти языки используют больше памяти, но сборка мусора на самом деле является более совершенным решением с точки зрения производительности "средней" программы: выделение памяти с помощью new проихсодит быстрее, чем при ручном управлении памятью, и это даёт определённые преимущества в том случае, если память есть в избытке. Сравнивать по объёму памяти языки с GC и ручным управлением памятью гатегорически неправильно: программы используют очень разные стратегии.
Java, C#, Scala, Swift, Objective C и, может быть, Golang -- наименее зашкварные языки, воровские и блатные. Уже достаточно далеки от байтоёбства, но и до тупого крудошлёпства ещё далеко. Можно хорошо знать один-два языка этой группы и не горевать.
3) Академический tier
Тут живут языки, которые никогда не используются в продакшене. Затесался паршивый паскаль. Для каких-то индустриальных нужд категорически непригодны. Никто не пишет. Многие знают, уметь писать на хаскелле, лиспе или ocaml/F# -- не зашквар. Человек, который не умеет писать за пределами третей группы -- уже зашкварный борщехлёб, опущенный.
4) Пыхоплеяда-tier
Группа совместного отсоса по производительности. Можно использовать только в одном случае: 99% времени работает не ваша программа, а СУБД или математическая библиотека. Чаще всего используются в наиболее нетребовательных к производительности приложениях наиболее низкоквалифицированными программистами (эти люди, однако, могут иметь высокую квалификацию в предметно области -- тогда их записываем в мужики). В пыхоплеяде есть три подгруппы. "Удачные, но тормозные" python и ruby отлично подходят для относительно простых задач вроде веб-девелопмента, калькуляторов, прототипов и скриптов. "По горло в легаси-говне" JS, производные JS и Lua используются потому, что их пользователи по горло в легаси-говне. Это самые опущенские языки программирования, на них пишут петухи программача, от природы тупые и обиженные хуесосы. "Даже легаси на этом поддерживтать стыдно" в виде Perl, Smalltalk и прочего винтажа помещают своих пользователей под толстый слой говна. Это уже зашквар без разговоров.
Немного отдельно от пыхоплеяды стоит Erlang: у него очень специфическая область применения.
В общем, резюме. Люди, которые знают языки из категорий пикрелейтеда (по крайней мере один из соотв. группы):
Одновременно 1, 2, 3, 4: воры, блатные, элита программача.
2 и один-два из 1, 3 или 4 на выбор: стремящиеся.
Только 2 или 3 и 4, или 1 и 4: мужики.
Только 4: обиженки.
Только 3: черти.
Только 1: чуханы.
1 и 3: козлы.
Давайте разберёмся. У нас есть прямо тиры
1) C-tier
Входит си, плюсы, раст и фортран
(прим. авт.: на пике фортран во втором тире, так как не нашлось программиста, который бы хорошо писал на фортране)
Отличается самой высокой скоростью работы, прекрасной векторизацией, суперсовременными компиляторами. Весь код, который должен работать быстро, пишется на C-tier, и самым компромиссным языком из C-tier являются плюсы.
Нет смысла расчехлять C-tier, если большая часть программы (СУБД, математическая библиотека, движок) и так на нём написана, но это определённо единственный выбор для производительного софта. А производительный софт ни на чём другом особо и не пишут. Мало кто знает, но кто действительно хорошо знает -- хороший программист. Если человек не умеет писать за пределами этой группы, то он байтоёб, опущенный.
2) Java/C#-tier
Отстаёт от C-tier в скромных два раза, при этом поддерживается сборка мусора.
(прим. авт.: Ada, которая не поддерживает сборку мусора -- просто бесполезное говно, которое зря попало в бенчмарки, мусорный язык)
Писать гораздо быстрее и легче, используются для написания тяжёлой операционной логики, а шарп хорош и для десктоп-приложений.
Отличные языки "по умолчанию", позволяют разрабатывать быстро, и сохраняют _очень_ близкую к родной производительность.
Эти языки используют больше памяти, но сборка мусора на самом деле является более совершенным решением с точки зрения производительности "средней" программы: выделение памяти с помощью new проихсодит быстрее, чем при ручном управлении памятью, и это даёт определённые преимущества в том случае, если память есть в избытке. Сравнивать по объёму памяти языки с GC и ручным управлением памятью гатегорически неправильно: программы используют очень разные стратегии.
Java, C#, Scala, Swift, Objective C и, может быть, Golang -- наименее зашкварные языки, воровские и блатные. Уже достаточно далеки от байтоёбства, но и до тупого крудошлёпства ещё далеко. Можно хорошо знать один-два языка этой группы и не горевать.
3) Академический tier
Тут живут языки, которые никогда не используются в продакшене. Затесался паршивый паскаль. Для каких-то индустриальных нужд категорически непригодны. Никто не пишет. Многие знают, уметь писать на хаскелле, лиспе или ocaml/F# -- не зашквар. Человек, который не умеет писать за пределами третей группы -- уже зашкварный борщехлёб, опущенный.
4) Пыхоплеяда-tier
Группа совместного отсоса по производительности. Можно использовать только в одном случае: 99% времени работает не ваша программа, а СУБД или математическая библиотека. Чаще всего используются в наиболее нетребовательных к производительности приложениях наиболее низкоквалифицированными программистами (эти люди, однако, могут иметь высокую квалификацию в предметно области -- тогда их записываем в мужики). В пыхоплеяде есть три подгруппы. "Удачные, но тормозные" python и ruby отлично подходят для относительно простых задач вроде веб-девелопмента, калькуляторов, прототипов и скриптов. "По горло в легаси-говне" JS, производные JS и Lua используются потому, что их пользователи по горло в легаси-говне. Это самые опущенские языки программирования, на них пишут петухи программача, от природы тупые и обиженные хуесосы. "Даже легаси на этом поддерживтать стыдно" в виде Perl, Smalltalk и прочего винтажа помещают своих пользователей под толстый слой говна. Это уже зашквар без разговоров.
Немного отдельно от пыхоплеяды стоит Erlang: у него очень специфическая область применения.
В общем, резюме. Люди, которые знают языки из категорий пикрелейтеда (по крайней мере один из соотв. группы):
Одновременно 1, 2, 3, 4: воры, блатные, элита программача.
2 и один-два из 1, 3 или 4 на выбор: стремящиеся.
Только 2 или 3 и 4, или 1 и 4: мужики.
Только 4: обиженки.
Только 3: черти.
Только 1: чуханы.
1 и 3: козлы.
>>1082436
а как же Delphi, он же тоже конпилируестя в наривный код, даже можно ассемблерные вставки делать
а как же 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=Евангелист майкрософт, коронуем в хает
Давайте разберём часто встречающиеся комбинации.
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=Евангелист майкрософт, коронуем в хает
>>1082794
Мужик, если за Go в хате сможешь пояснить и обосновать, то вообще стремящийся.
Мужик, если за Go в хате сможешь пояснить и обосновать, то вообще стремящийся.
Я контрибьютор glibc и gcc и я нихуя не понял, о чем ОП. Какая бывает линковка и как она работает не понимаешь? Что такое юниты компиляции не понимаешь? В чем разница между инклудами и линковкой не понимаешь? Рот ебал, ботай матчасть.
>>1084019
+ добавлю, сейчас уже отлично работает линк тайм оптимизации. Так что уже все настолько пиздато, насколько можно.
+ добавлю, сейчас уже отлично работает линк тайм оптимизации. Так что уже все настолько пиздато, насколько можно.
>>1084020
Но всё равно, стервец, в два раза медленее icpc
Но всё равно, стервец, в два раза медленее icpc
Тред утонул или удален.
Это копия, сохраненная 23 ноября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 23 ноября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.