М.Двач / Программирование

Этого треда уже нет.
Это копия, сохраненная 23 ноября 2017 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.

Олдфаги приглашаются в тред Я думаю многие знают # OP 23 сен, 18:26 #1065530 В конец треда | Веб

10 Кб, 200x200

33 Кб, 505x98

30 Кб, 388x306

Олдфаги приглашаются в тред

Я думаю многие знают какие по истинне гумозные трудности представляет собой сборка, подключение библиотек и различные операции с include в C++.

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

Могут ли олдфаги или просто знающие пояснить - почему так исторически сложилось?

Тут бампать можно или чего? Ну я бампну пару раз, вы меня только не баньте

Ответы6565566066678477730277516780358229682431

sage 23 сен, 21:44 #2 #1065655

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

Ответы6569166066

23 сен, 23:15 #3 #1065691

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

Ответы65702

23 сен, 23:29 #4 #1065702

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

Ответы65707

sage 24 сен, 00:02 #5 #1065707

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

Ответы6571865938

24 сен, 00:46 #6 #1065718

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

24 сен, 19:15 #7 #1065938

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

25 сен, 02:27 #8 #1066066

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

Ответы82408

28 сен, 18:36 #9 #1067732

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

Ответы6782367842

sage 28 сен, 21:42 #10 #1067823

>>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)

Ответы6784267853

28 сен, 22:14 #11 #1067842

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

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

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

Ответы67853

28 сен, 22:17 #12 #1067847

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

Ответы82160

28 сен, 22:27 #13 #1067853

>>1067823
>>1067842

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

Ответы67862

28 сен, 22:54 #14 #1067862

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

Ответы67935

sage 29 сен, 01:45 #15 #1067935

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

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

Ответы68080

36,8 Мб, webm, 1280x720, 4:53

29 сен, 06:27 #16 #1067970

Множества тех, кто знает C++ и тех, кто Любит - не пересекаются.

Ответы77267

29 сен, 15:08 #17 #1068080

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

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

Ответы6812768202

29 сен, 17:36 #18 #1068127

>>1068080

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

Ответы82410

sage 29 сен, 19:15 #19 #1068202

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

17 окт, 19:48 #20 #1077267

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

Ответы77287

17 окт, 20:28 #21 #1077287

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

Ответы7729077504776677770577932

17 окт, 20:34 #22 #1077290

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

17 окт, 20:54 #23 #1077302

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

Ответы77304

17 окт, 20:55 #24 #1077304

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

Ответы77307

17 окт, 20:58 #25 #1077307

>>1077304
Например

Ответы77323

17 окт, 21:30 #26 #1077323

>>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 и компилятора

17 окт, 21:30 #26 #1077323

>>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 и компилятора

Показать весь текст
Ответы7732577356

17 окт, 21:32 #27 #1077325

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

17 окт, 22:34 #28 #1077356

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

Ответы77360

17 окт, 22:37 #29 #1077360

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

18 окт, 10:50 #30 #1077504

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

Ответы77667

18 окт, 11:18 #31 #1077516

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

18 окт, 16:05 #32 #1077667

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

Ответы77705

18 окт, 16:59 #33 #1077705

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

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

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

Ответы77996

19 окт, 01:32 #34 #1077932

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

Ответы77996

19 окт, 06:38 #35 #1077996

>>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, тогда приходите, а пока предлагаю вам, петухам, отправиться к своей параше.

Ответы78099

sage 19 окт, 09:19 #36 #1078035

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

19 окт, 12:02 #37 #1078099

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

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

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

Ответы7810182161

19 окт, 12:05 #38 #1078101

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

26 окт, 03:29 #39 #1082160

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

26 окт, 03:35 #40 #1082161

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

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

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

Ответы82335

26 окт, 14:46 #41 #1082296

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

Ответы82308

26 окт, 15:05 #42 #1082308

>>1082296

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

26 окт, 15:42 #43 #1082335

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

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

Ответы8241482436

26 окт, 19:11 #44 #1082408

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

26 окт, 19:16 #45 #1082410

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

26 окт, 19:27 #46 #1082414

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

4 Кб, 516x311

26 окт, 20:18 #47 #1082431

>>1065530 (OP)
>include
как что-то плохое

103 Кб, 700x975

26 окт, 20:22 #48 #1082436

>>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: козлы.

103 Кб, 700x975

26 окт, 20:22 #48 #1082436

>>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: козлы.

Показать весь текст
Ответы8244182446

26 окт, 20:28 #49 #1082441

>>1082436

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

Ответы82442

26 окт, 20:30 #50 #1082442

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

26 окт, 20:42 #51 #1082446

>>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=Евангелист майкрософт, коронуем в хает

Ответы82794

27 окт, 17:21 #52 #1082794

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

Ответы8346383476

28 окт, 23:10 #53 #1083463

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

28 окт, 23:20 #54 #1083476

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

Ответы83665

29 окт, 10:52 #55 #1083665

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

29 окт, 23:51 #56 #1084019

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

Ответы84020

29 окт, 23:52 #57 #1084020

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

Ответы84941

31 окт, 14:31 #58 #1084941

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

Тред утонул или удален.
Это копия, сохраненная 23 ноября 2017 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.

« /pr/В начало тредаВеб-версияНастройки/a//b//mu//s//vg/Все доски

Пользуетесь скринридером — пишите, что можно улучшить.
Host-Food.ru — надёжный хостинг от 12 руб/мес | Free DNS
Зеркала М.Двача: m2ch.hk, m2ch.lib, m2chfapiswfw2wcakptqp4o6ltgchvjuxfab7urxlduraomtlnhw5xad.onion