Здравствуйте, prezident.mira, Вы писали:
S>>Когда нужен тонкий ручной тюнинг, то это делается на C++ так же, как и на C. PM>Доё Справедливости ради, в стандартном C есть restrict, а в C++ — нет. (Впрочем, все нужные компиляторы понимают __restrict)
Здравствуйте, VladD2, Вы писали:
N>>Да, стоит. Внутри того же OpenCV, который невольно стал примером тематической библиотеки на С++, тоже есть expression templates для матриц. Я могу написать читабельное выражение для любого математика типа: Y = A * X + B. И правая часть выполнится ОДНОЙ (!!!) специализированной функцией. Вот это и есть применение С++, которое улучшает понимание кода, делает его проще без ущерба для скорости. VD>Это возможно не только на С++.
Никто не спорит. Но это также свидетельствует, что С++ достаточно современен и предоставляет БЕСПЛАТНЫЕ в плане производительности абстракции высокого уровня. Об это и говорим.
Здравствуйте, Nuzhny, Вы писали:
N>Никто не спорит. Но это также свидетельствует, что С++ достаточно современен и предоставляет БЕСПЛАТНЫЕ в плане производительности абстракции высокого уровня. Об это и говорим.
1. Они отнюдь не бесплатные. Если нужно выжать последние копейки, то в стиле С или на ассемблере всегда можно сделать быстрее. Просто результат таких оптимизации не стоит свечей. Но этот же аргумент верен в 90% применений и к други языкам, чьи компиляторы порождают менее оптимизированный код.
2. О современности это не свидетельствует. МП чуть меньше лет чем языкам программирования вообще. Первым был Лисп около 60 лет назад.
3. Платить приходится не только скоростью выполнения кода, но и простотой, скоростью и удобством разработки. В этом плане С++ не сливает разве что голому С и Паскалю виртовского разлива.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В тех же игрушках нормой стало писать на С++ недра движков, а сами игры описывать на кондовейших скриптах (в которых о производительности даже смешно говорить).
Уже миллион лет назад скрипты на lua — это фактически luajit, который быстрый. Помню, ещё в первом Сталкере (много лет назад) это было. Так что не надо тут о производительности скриптов. Она нормальная.
Здравствуйте, VladD2, Вы писали:
VD>1. Они отнюдь не бесплатные. Если нужно выжать последние копейки, то в стиле С или на ассемблере всегда можно сделать быстрее. Просто результат таких оптимизации не стоит свечей. Но этот же аргумент верен в 90% применений и к други языкам, чьи компиляторы порождают менее оптимизированный код.
Интересно, а какой оверхед в плане производительности вносят те же шаблоны? Мне кажется, что ты на что-то другое отвечаешь.
VD>2. О современности это не свидетельствует. МП чуть меньше лет чем языкам программирования вообще. Первым был Лисп около 60 лет назад.
И? Слово современный не является синониму к слову новаторский. Мне всё кажется, что ты не со мной споришь, а с кем-то другим.
VD>3. Платить приходится не только скоростью выполнения кода, но и простотой, скоростью и удобством разработки. В этом плане С++ не сливает разве что голому С и Паскалю виртовского разлива.
Ага. Пишу я, значит, работу с матрицами. Надо мне посчитать Y = A * X + B. И я на С++ так и записываю! Представляешь? И что в результате? А в результате у меня вызывается функция, которая одновременно умножает и складывает матрицы. Причём, тип элементов матрицы может быть любым. Если библиотека собрана с использованием Eigen, то будет вызвана её реализация. Если библиотека была собрана с использованием IPP, то будет вызвана эта реализация. Если был выбран OpenCL, то выражение будет посчитано на видеокарте. А мне, прикладному программисту, можно написать просто Y = A * X + B. Всё! Где тут проблема в простоте, скорости или удобстве разработки?Где она: "Ау!"
Теперь я могу ожидать от тебя подобного примера на другом языке?
Здравствуйте, Dair, Вы писали:
D>В идеале, я бы хотел язык с двумя парадигмами распределения памяти — ручной и GC, чтобы разработчик мог выбирать, что ему надо (примерно это решено в Objective-C с его ARC, хотя механизм другой чем GC — работает ровно как на Java/C#, когда не думаешь про выделение памяти). D>Я бы хотел язык, для которого есть компилятор в нативный код (x86/x64/arm/arm64/...), но есть и, например, компилятор в JVM или CLR — это дало бы гибкость.
Здравствуйте, prezident.mira, Вы писали:
PM>Без впитанного HKT — не нужен.
НКТ — это Не Кошерный Товарищ?
PM>не нужен.
Вы сюда с ЛОРа пришли? Очень бросается в глаза.
Здравствуйте, Nuzhny, Вы писали:
N>Уже миллион лет назад скрипты на lua — это фактически luajit, который быстрый. Помню, ещё в первом Сталкере (много лет назад) это было. Так что не надо тут о производительности скриптов. Она нормальная.
Код на JS исполняемый посредством JS-jit, работает гораздо быстрее, чем код lua на lua-jit. У Lua есть ровно одно преимущество — его интерпретатор (а не jit-компилятор) является чемпионом по малому потреблению памяти. Именно поэтому lua любят например в телефонии, где нужно в сотне тредов исполнять скрипты (а нормального jit туда не завезли, потому что сам отрасль телефонии больная на голову).
Здравствуйте, Слава, Вы писали:
D>>Я бы хотел язык, для которого есть компилятор в нативный код (x86/x64/arm/arm64/...), но есть и, например, компилятор в JVM или CLR — это дало бы гибкость.
С>Есть же Dlang.
Верю.
А вот есть dlang-arm64-ios? А как с ObjC UIKit из dlang работать? Есть jni-dlang?
Здравствуйте, Слава, Вы писали:
С>Код на JS исполняемый посредством JS-jit, работает гораздо быстрее, чем код lua на lua-jit.
Это хорошо, что большие корпорации смогли обогнать одного разработчика, работающего за донаты. Но! Тот факт, что JS-jit быстрее, чем lua-jit не говорит, что lua-jit медленный.
С>У Lua есть ровно одно преимущество — его интерпретатор (а не jit-компилятор) является чемпионом по малому потреблению памяти. Именно поэтому lua любят например в телефонии, где нужно в сотне тредов исполнять скрипты (а нормального jit туда не завезли, потому что сам отрасль телефонии больная на голову).
Согласен. Но в играх я чаще видел в поставке luajit. Видимо, для них память не сильно критична.
Здравствуйте, VladD2, Вы писали:
VD>1. Они отнюдь не бесплатные. Если нужно выжать последние копейки, то в стиле С или на ассемблере всегда можно сделать быстрее.
Про С просто не правда. Код на С++ всегда не медленней чем на С. Если конечно у программиста руки не кривые.
Просто за счёт того, что шаблоны оптимизируются гораздо лучше, чем процедурный код.
Классический пример qsort vs std::sort.
На ассемблере в теории можно, но на практике мало кто может обогнать современные компиляторы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Nuzhny, Вы писали:
N>Теперь я могу ожидать от тебя подобного примера на другом языке?
На немерле и любом языке с подобными макросами такое без проблем делается.
Причем макросы гораздо круче шаблонов.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
N>>Теперь я могу ожидать от тебя подобного примера на другом языке? WH>На немерле и любом языке с подобными макросами такое без проблем делается. WH>Причем макросы гораздо круче шаблонов.
Здравствуйте, Nuzhny, Вы писали:
N>Хорошо, хорошо. Но примеров же не будет, да?
Про матрицы не будет. Ибо для того чтобы они были их должен кто-то написать.
Но для понимания того что это возможно посмотри на http://www.nemerleweb.com/tutorial
Эта штука берёт код на немерле и превращает его в реактивный код на JS.
MA> Не совсем ясно на что именно ты дал ссылку (что конкретно имел ввиду). Сорри.
На код, который уделывает С++ по производительности.
На остальное отвечать не буду, ибо ты отвечал на свои фантазии, которые не имеют отношения к тому на что я дал ссылку.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Про web ничего не скажу, потому что не разбираюсь. А про NUDA можно. Как показывает практика, на том же OpenCL надо писать индивидуальный код чуть ли не на каждую архитектуру. В общем: AMD VLIW — один код, GCN — другой, для NVidia — третий, под Интел — четвёртый. Это самый минимум, в действительности надо больше градаций делать, чтобы получить максимум производительности. Кто-то заявляет, что поддерживает стандарт OpenCL 1.2, но на практике оказывается, что некоторые функции из стандарта не работают, возвращают ОК, но ничего при этом не делают. И это нормально в этой области. OpenCL на мобильных платформах ещё в более плачевном состоянии. А ещё у каждого вендора есть свои расширения, многие из них прописаны в стандарте, но не все.
Так что мне не особо верится в возможность качественной кодогенерации OpenCL кода. Всё таки приведённая тобой статья довольно старая, современные реалии сложнее.
Надо ли говорить, что в той же OpenCV над OpenCL и CUDA кодом работали штатные сотрудники из Интела, АМД и Нвидиа. Ибо всё сложно, у инсайдеров получается писать намного более производительный код из-за наличия внутренней подробной документации. А некоторые вещи вообще не задокументированы.
Поэтому что на С++, что на Немерле всё равно придётся писать не обобщённый, а узкоспециализированный код. Тут никакого выигрыша не будет.
А он нужен именно на уровне выше, уровне прикладного программиста, который использует язык, библиотеку и может писать на близком к себе языке. В моём контексте — это язык более близкий к математикам. Можно ориентироваться на Матлаб, который является де-факто стандартом для них. Вот клиентский код на OpenCV на С++ может быть не намного сложнее матлабовского и питоновского.
Я как-то взял небольшую функцию non maximum suppression на Питоне (от человека который продаёт свои лекции о компьютерном зрении на Питоне) и переписал её на С++. Получилось короче и эффективнее даже в плане алгоритмов, не говоря уже об итоговой производительности. С++ + OpenCV оказалось выразительнее, чем Питон + numpy + OpenCV (официальный биндинг к Питону). Вот это и есть простота и эффективность.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, prezident.mira, Вы писали:
VD>>>1. Rust. PM>>Это верно,
VD>Мне нравится учительский тон.
Рад стараться.
PM>>но пока рановато.
VD>Ты всю жизнь прождешь и будешь поговаривать "пока рановато". Я это уже на том же D наблюдал.
Насчёт D никто не поговаривал "пока рановато заменять им C++". Вряд ли кем-то, кроме создателя, D всерьёз рассматривался как замена C++.
VD>>>2. D. PM>>Это смешно.
VD> D обладает всем, что есть в С++ и многим, что в нем нет.
Да, например GC, который нафиг не нужен в той области, где нужен C++.
VD> А главное, что на нем куда проще писать код.
Много на чём проще писать код, чем на C++. Это не значит, что нечто, на чём проще писать код, чем на C++ является заменой C++.
VD>>>3. Ocamle. PM>>Тредов тонет, скорее кидайте ему спасательный круг!
VD>Он уже лет 25 тонет. Все никак потонет.
Напоминает эту сексистскую шутку, уж извините. «OCaml — ничем не хуже C++! Он так же продуктивен и полезен обществу! Вспомните, например, применяющие его компании: "Jane Street Capital", "Jane Street Capital", "Jane Street Capital" …»
VD>>>4. Создание DSL-ей генерирующих тот же С/С++. PM>>Можно и из Scheme сгенерировать C. Только производительность у этого кода будет не как у вручную написанного C, а как у питона.
VD>Ты сначала сам попробуй, а потом трепись. К слову я этим треть жизни занимаюсь.
Треть жизни треплешься? И не надоело?
VD> Разницы между вручную написанным кодом и сгенерированным не наблюдаю.
Вручную написанный C и сгенерированный C — это один и тот же C, никакой разницы. Надо же!
VD> Его всегда можно сделать аналогичным.
Ага. Вручную расставив аннотации типов. Тогда зачем вообще на Scheme писать?
VD>Ну, и не нужен везде идеальный код.
Т.е. "зелён виноград". Всё-таки сознались, что производительность-то остаётся от Scheme, хоть оттранслируй его в C, хоть в LLVM, а как была проверка типов в рантайме, так и осталась.
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, VladD2, Вы писали:
MA>В свете последнего опыта с C++ я почти всегда стараюсь его критиковать. Меня конечно понять сложно т.к. не обладаю талантом выражать мысли максимально понятно.
MA>Тем не менее последние наблюдения меня вводят в некоторое уныние.
MA>1. Типы и Undefined Behavior
MA>Я не понимаю почему в стандарте наконец не определят бихейвор.
Это уже объяснялось много раз.
MA>Короче, поинт в том — что UB не место в стандарте. А с размерами типов можно и определится наконец.
Здравствуйте, Mystic Artifact, Вы писали:
MA>В рамках ликбеза: а как становится понятно, что необходимо переехать в кучу?
В контексте C# говорить на эту тему как-то смысла немного. Там Эдем (Eden), поколения объектов, все такое. Все автоматически из Эдема переезжает в более долговременную кучу (по крайней мере, в Java). А куча / стек — это вещи, важные для языков типа Си и Си++. Напомню, что Rust позиционируется как язык системного программирования
