Здравствуйте, WolfHound, Вы писали:
WH>Про С просто не правда. Код на С++ всегда не медленней чем на С.
Это чушь. Повторюсь. Абстракции дешевые, но отнюдь не всегда бесплатные.
WH>Если конечно у программиста руки не кривые.
Вот эти разговоры про руки можно даже не начинать. Если нужно знать детали работы компилятора, то это уже не работа, а шаманство.
WH>Просто за счёт того, что шаблоны оптимизируются гораздо лучше, чем процедурный код. WH>Классический пример qsort vs std::sort.
Ну, вот в стиле С (не важно уж на С-компиляторе, или на С++) можно всегда написать конкретную реализацию для конкретных типов, которая всегда будет не медленнее то, что написана с использованием С++-ных фич.
Я намеренно написал "в стиле С", так как по сути кодогенераторы и оптимизаторы у С-ных и С++-ных компиляторов одинаковые.
WH>На ассемблере в теории можно, но на практике мало кто может обогнать современные компиляторы.
Он и без теории может. И обогнать может любой, кто займется этим вопросом и разберется в проблеме. Вопрос лишь в том стоит ли игра свечей. Ты же сам тут про не кривые руки пишешь. Для асма они они еще более прямыми должны быть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prezident.mira, Вы писали:
PM>Насчёт D никто не поговаривал "пока рановато заменять им C++". Вряд ли кем-то, кроме создателя, D всерьёз рассматривался как замена C++.
Еще как поговаривали. Можешь перечитать темы по Ди в данный форум, которые здесь 10 лет назад поднимались (и позже).
PM>Да, например GC, который нафиг не нужен в той области, где нужен C++.
На фиг не нужен твой треп. Не говори о том, что не умеешь использовать. GC позволяет значительно упростить написание кода в случаях когда идет работа со сложными графами разнотипных объектов.
PM>Много на чём проще писать код, чем на C++. Это не значит, что нечто, на чём проще писать код, чем на C++ является заменой C++.
Конечно не означает. Это вывернул смысл сказанного зачем-то. Никто этого не утверждал. D является заменой С++ просто по определению. Его для этого создавали. И вот на этой замене С++ код писать заметно удобнее и проще чем на С++. И именно по этому он лучше.
А вот эти ваши "смешно" — это необоснованный треп. Если тебе смешно, приведи обоснование. Посмеемся вместе.
VD>>Он уже лет 25 тонет. Все никак потонет.
PM>Напоминает эту сексистскую шутку, уж извините. «OCaml — ничем не хуже C++! Он так же продуктивен и полезен обществу! Вспомните, например, применяющие его компании: "Jane Street Capital", "Jane Street Capital", "Jane Street Capital" …»
То что миллионы мух сидят одном и том же продукте жизнедеятельности нифига не значит, что другие вещи чем-то хуже него.
Тебе как раз и показывают, что определяющим является не достоинства или недостатки языка, а психологические и социальные факторы. Не было за D и Ocaml тех кто смог бы раскрутить их и довести их качество до идеала, вот они и не взлетели.
А убогий и морально устаревший С++ живет и здравствует по сей день, в некоторых нишах. Хотя основная масса программистов с него свалила за последние 20 лет.
VD>>Ты сначала сам попробуй, а потом трепись. К слову я этим треть жизни занимаюсь.
PM>Треть жизни треплешься? И не надоело?
Трепишься здесь только ты. Знаний у тебя мало. Опыта еще меньше. Но ты без труда делаешь громкие заявления.
В отличие от тебя, я в метапрограммирование в общем, и в кодогерерации по DSL-ям не одну собаку съел. И говорю о проблеме со знанием дела.
Но даже не имея такого опыта не трудно понять, что вся разница между сгенерированным кодом и рукописным заключается в том, что первый пишется по шаблонам. Сколько потратишь времени на оптимизацию этих шаблонов, такое качество и получишь.
В любом случае производительность туда будет не сравнима.
PM>Вручную написанный C и сгенерированный C — это один и тот же C, никакой разницы. Надо же!
Ага. В итоге это просто текст, который компилируется тем же компилятором. Только в одном случае ты описываешь только логику, а повторяющийся шаблонный код выписываешь вручную, а во втором ты генерируешь его автоматом.
Более того. При должном усердии сгенерированный код может быть быстрее рукописного. В рукописном коде ты вынужден использовать разные абстракции и жертвовать производительностью ради качества кода. В сгенерированнм можно коде можно насрать на его качесво, так как читать его будет только компилятор и выбирать самые громоздкие, но и самые быстрые решения.
Таким образом мы и на не самом шустром .net-е выжимаем производительность достаточною реалтайной работы IDE.
PM>Ага. Вручную расставив аннотации типов. Тогда зачем вообще на Scheme писать?
Довольно без разницы на чем описывать DSL. Scheme для этого не лучший выбор, но тоже потянет. Никакие типы навешивать не нужно. Нужно просто грамотно описать модель. Вот возьмем к примеру BNF. В нем нет никаких явных типов. Но его можно доработать так, чтобы из него можно было выводить типы для всего чего нужно и генерировать очень эффективный типизированный код.
VD>>Ну, и не нужен везде идеальный код.
PM>Т.е. "зелён виноград". Всё-таки сознались, что производительность-то остаётся от Scheme, хоть оттранслируй его в C, хоть в LLVM, а как была проверка типов в рантайме, так и осталась.
Работая программистом нужно уметь правильно делать логические выводы. Из того, что не всегда нужен идеальный код, не проистекает, что "производительность-то остаётся от Scheme". Просто не всегда за производительностью стоит гнаться. Писать быстрый код априори сложнее и дороже. Это требует ресурсов. Иногда лучше выбрать менее быстрое, но обладающее другими полезными качествами решения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuzhny, Вы писали:
N>Интересно, а какой оверхед в плане производительности вносят те же шаблоны? Мне кажется, что ты на что-то другое отвечаешь.
Это не простой вопрос. В простейших случаях оверхэда нет. Но есть случае, когда он таки появляется. Ну, и не очень верно говорить о языке. Все упирается в реализации. Но язык, несомненно подталкивает к определенным решениям.
N>И? Слово современный не является синониму к слову новаторский. Мне всё кажется, что ты не со мной споришь, а с кем-то другим.
А какой смысл был в исходной фразе? Почему "в современном"? Я и 20 лет назад все тоже самое видел.
N>Ага. Пишу я, значит, работу с матрицами. Надо мне посчитать Y = A * X + B. И я на С++ так и записываю! N>Представляешь?
Представлю. А ты код, который для этого написать нужно, смотрел?
Прикинь на Немерле, на котором я пишу код, тоже можно матрицы складывать с помощью операторов. Но только еще при этом их можно через видеокарту, например, вычислить. И код для этого будет во много раз проще.
При этом пример этот с матрицами ничего не показывает. В реальности ты пишешь море болерплэйт-кода и следишь за правильностью управления памятью. Банальная лябда превращается в какой-то набор кракозбр.
Есть куча других языков, где при умеренной плате ты получаешь куда более комфортные условия.
N>И что в результате? А в результате у меня вызывается функция, которая одновременно умножает и складывает матрицы.
Пипец, удивил! Детский сад...
N>Теперь я могу ожидать от тебя подобного примера на другом языке?
Это детсадовская пенесоментрия. Надо говорить о том как на языке повседневный код пишется, а не о том есть ли в нем перегружаемые операторы и готовые библиотеки. Библиотек больше всего для Явы. Ей в этом кто хочешь сольет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
WH>>Про С просто не правда. Код на С++ всегда не медленней чем на С. VD>Это чушь. Повторюсь. Абстракции дешевые, но отнюдь не всегда бесплатные.
В случае с С++ они действительно бесплатные.
Проверено.
Горы денег, вложенные в оптимизаторы, даром не пропали.
WH>>Если конечно у программиста руки не кривые. VD>Вот эти разговоры про руки можно даже не начинать. Если нужно знать детали работы компилятора, то это уже не работа, а шаманство.
Я не про детали реализации компилятора говорю. А про использование виртуальных функций там, где они не нужны.
А если делать полиморфизм на шаблонах, но оно всегда не медленней чем С.
VD>Ну, вот в стиле С (не важно уж на С-компиляторе, или на С++) можно всегда написать конкретную реализацию для конкретных типов, которая всегда будет не медленнее то, что написана с использованием С++-ных фич.
Это не правда. В лучшем случае написав в десятки раз больше кода на С ты получишь ту же скорость работы.
Ты видимо просто не видел, как современные компиляторы превращают гору объектов и десятки вызовов в пару ассемблерных инструкций.
VD>Я намеренно написал "в стиле С", так как по сути кодогенераторы и оптимизаторы у С-ных и С++-ных компиляторов одинаковые.
На С++ ты писал больше 10 лет назад.
Между VC++6 и современными компиляторами огромная пропасть.
VD>Он и без теории может. И обогнать может любой, кто займется этим вопросом и разберется в проблеме. Вопрос лишь в том стоит ли игра свечей. Ты же сам тут про не кривые руки пишешь. Для асма они они еще более прямыми должны быть.
В том то и дело что не любой. И далеко не каждый раз. И времени придётся потратить уйму. И при малейшем изменении в коде придётся начинать по новой.
Короче, на С С++ обогнать просто нельзя. Совсем. Никак.
На асме можно, но очень сложно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Это не простой вопрос. В простейших случаях оверхэда нет. Но есть случае, когда он таки появляется.
Ты конечно же можешь это продемонстрировать.
Только не на VC++6, а не современном компиляторе.
N>>Ага. Пишу я, значит, работу с матрицами. Надо мне посчитать Y = A * X + B. И я на С++ так и записываю! N>>Представляешь? VD>Представлю. А ты код, который для этого написать нужно, смотрел?
Я такой писал. Нет там ничего особо страшного.
VD>Прикинь на Немерле, на котором я пишу код, тоже можно матрицы складывать с помощью операторов. Но только еще при этом их можно через видеокарту, например, вычислить. И код для этого будет во много раз проще.
Это не тот пример, на котором можно показать крутизну немерле по сравнению с С++.
Код на С++ будет сравним или даже проще.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
N>>Интересно, а какой оверхед в плане производительности вносят те же шаблоны? Мне кажется, что ты на что-то другое отвечаешь. VD>Это не простой вопрос. В простейших случаях оверхэда нет. Но есть случае, когда он таки появляется. Ну, и не очень верно говорить о языке. Все упирается в реализации. Но язык, несомненно подталкивает к определенным решениям.
Вообще нет.
VD>А какой смысл был в исходной фразе? Почему "в современном"? Я и 20 лет назад все тоже самое видел.
Не видел. Я читал твои статьи по С++ на РСДН. Там было много про СОМ объекты, windows-specific и т.д. Часто внутри были просто переводы кусков из MSDN. Это не тот С++, который сейчас.
N>>Ага. Пишу я, значит, работу с матрицами. Надо мне посчитать Y = A * X + B. И я на С++ так и записываю! N>>Представляешь? VD>Представлю. А ты код, который для этого написать нужно, смотрел?
Да, конечно. Я и ваш код на Немерле для OpenCL смотрел. Для менят на плюсах код понятней, а макросы на Немерле кажутся птичьим языком. Вот.
VD>Прикинь на Немерле, на котором я пишу код, тоже можно матрицы складывать с помощью операторов. Но только еще при этом их можно через видеокарту, например, вычислить. И код для этого будет во много раз проще. VD>При этом пример этот с матрицами ничего не показывает. В реальности ты пишешь море болерплэйт-кода и следишь за правильностью управления памятью. Банальная лябда превращается в какой-то набор кракозбр.
Гм. Про кракозябры я бы не говорил. Матрицы — это вполне показательный пример, который говорит, что на языке можно удобно описывать математику.
VD>Есть куча других языков, где при умеренной плате ты получаешь куда более комфортные условия.
Давай говорить это в разрезе темы, а она у нас звучит как "Область применения С++". Математика — это как раз область применения С++. Как раз на него почти всегда в продакшене переписывают код, который математики пишут на Матлабе или Питоне. Так вот современный С++ позволяет писать так же удобно, как и на этих специализированных языках. А код получается быстрее. Да, для этого нужны библиотеки, но и у Матлаба, и у Питона они также требуются. Получается, что С++ зачастую выгоднее.
Даже так: выгода Питона для математиков — это jupyter notebook. Это реально мощнейшая штука, посмотри. Уделывает всё. У какого языка есть такое же?
N>>И что в результате? А в результате у меня вызывается функция, которая одновременно умножает и складывает матрицы. VD>Пипец, удивил! Детский сад...
VD>https://www.osp.ru/os/2011/05/13009416/ VD>Это детсадовская пенесоментрия. Надо говорить о том как на языке повседневный код пишется, а не о том есть ли в нем перегружаемые операторы и готовые библиотеки. Библиотек больше всего для Явы. Ей в этом кто хочешь сольет.
Смотря для чего у неё библиотеки есть. Ты опять уходишь в какие-то общефилософские темы, а тут речь больше о конкретике. Математика, игры, видео и изображения, сетевое программирование, системное. Вот это области применения С++. Кто тут конкурент? С, D, Rust.
Про Немерле и программирование на GPU я отвечал выше. По факту оказывается, что программирование на том же OpenCL — это не столько написание кода для реализации алгоритма, сколько подгонка его под конкретные архитектуры GPU (или даже CPU, часто код на OpenCL под CPU компилируется более эффективно, чем на С++) или стандарты OpenCL. Это современные реалии этого мира: вендоры не полностью реализуют стандарты, добавляют свои расширения к ним, разные архитектуры требуют разного кода. Тут не так всё просто, как тебе кажется и простой удобной кодогенерацией не ограничиться. Твои статьи, например, показывают производительность на VLIW архитектуре от АМД. А GCN требует уже совсем других подходов и не всегда можно просто изменить размеры или выравнивая. С CUDA то же самое.
Я не вижу тут особой пользы от годогенерации, всё равно придётся сидеть в профайлере и писать код под разные архитектуры.
Здравствуйте, Nuzhny, Вы писали:
N>Про Немерле и программирование на GPU я отвечал выше. По факту оказывается, что программирование на том же OpenCL — это не столько написание кода для реализации алгоритма, сколько подгонка его под конкретные архитектуры GPU (или даже CPU, часто код на OpenCL под CPU компилируется более эффективно, чем на С++) или стандарты OpenCL. Это современные реалии этого мира: вендоры не полностью реализуют стандарты, добавляют свои расширения к ним, разные архитектуры требуют разного кода. Тут не так всё просто, как тебе кажется и простой удобной кодогенерацией не ограничиться. Твои статьи, например, показывают производительность на VLIW архитектуре от АМД. А GCN требует уже совсем других подходов и не всегда можно просто изменить размеры или выравнивая. С CUDA то же самое. N>Я не вижу тут особой пользы от годогенерации, всё равно придётся сидеть в профайлере и писать код под разные архитектуры.
Чтобы не быть голословным, вот список расширений от вендоров. Есть они у всех: захардкоженные быстрые функции, директивы компилятора, отхождения от стандартов и многое другое. Тут надо быть именно специалистом по OpenCL, чтобы писать на нём универсальный эффективный код.
Здравствуйте, dsorokin, Вы писали:
D>В контексте C# говорить на эту тему как-то смысла немного. Там Эдем (Eden), поколения объектов, все такое. Все автоматически из Эдема переезжает в более долговременную кучу (по крайней мере, в Java). А куча / стек — это вещи, важные для языков типа Си и Си++. Напомню, что Rust позиционируется как язык системного программирования
Только если тебе на производительность наплевать.
Несмотря на поколения лишний трафик памяти может весьма сильно замедлить код.
Хотя бы из-за того, что короткоживущие объекты начинают проваливаться в старшие поколения и со временем вызывают полную сборку мусора.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Nuzhny, Вы писали:
N>Даже так: выгода Питона для математиков — это jupyter notebook. Это реально мощнейшая штука, посмотри. Уделывает всё. У какого языка есть такое же?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, dsorokin, Вы писали:
D>>В контексте C# говорить на эту тему как-то смысла немного. Там Эдем (Eden), поколения объектов, все такое. Все автоматически из Эдема переезжает в более долговременную кучу (по крайней мере, в Java). А куча / стек — это вещи, важные для языков типа Си и Си++. Напомню, что Rust позиционируется как язык системного программирования WH>Только если тебе на производительность наплевать. WH>Несмотря на поколения лишний трафик памяти может весьма сильно замедлить код. WH>Хотя бы из-за того, что короткоживущие объекты начинают проваливаться в старшие поколения и со временем вызывают полную сборку мусора.
Здравствуйте, AlexGin, Вы писали:
AG>c) Задачи математического моделирования;
Если верить некоторым обзорам, то это как раз хороший пример того, как можно на Си++ писать медленный и неэффективный код. Те же инструменты могут хранить атрибуты транзакта (заявки) в мапе по строковому ключу. Ну, и здравствуй пупер-эффективный Си++!
Здравствуйте, dsorokin, Вы писали:
AG>>c) Задачи математического моделирования; D>Если верить некоторым обзорам, то это как раз хороший пример того, как можно на Си++ писать медленный и неэффективный код. Те же инструменты могут хранить атрибуты транзакта (заявки) в мапе по строковому ключу. Ну, и здравствуй пупер-эффективный Си++!
"некоторым обзорам" — каким обзорам?
"Те же инструменты" — какие инструменты?
"могут хранить атрибуты транзакта (заявки) в мапе по строковому ключу" — а могут и не хранить? Тогда надо выбрать именно эту опцию.
"Ну, и здравствуй пупер-эффективный Си++" — а какие инструменты быстрее и не на С++?
Всё таки в сообщения надо добавлять кроме воды полезной конкретики.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, dsorokin, Вы писали:
AG>>>c) Задачи математического моделирования; D>>Если верить некоторым обзорам, то это как раз хороший пример того, как можно на Си++ писать медленный и неэффективный код. Те же инструменты могут хранить атрибуты транзакта (заявки) в мапе по строковому ключу. Ну, и здравствуй пупер-эффективный Си++!
N>"некоторым обзорам" — каким обзорам? N>"Те же инструменты" — какие инструменты? N>"могут хранить атрибуты транзакта (заявки) в мапе по строковому ключу" — а могут и не хранить? Тогда надо выбрать именно эту опцию. N>"Ну, и здравствуй пупер-эффективный Си++" — а какие инструменты быстрее и не на С++?
N>Всё таки в сообщения надо добавлять кроме воды полезной конкретики.
Здравствуйте, dsorokin, Вы писали:
AG>>>>c) Задачи математического моделирования; D>>>Если верить некоторым обзорам, то это как раз хороший пример того, как можно на Си++ писать медленный и неэффективный код. Те же инструменты могут хранить атрибуты транзакта (заявки) в мапе по строковому ключу. Ну, и здравствуй пупер-эффективный Си++! N>>Всё таки в сообщения надо добавлять кроме воды полезной конкретики.
D>ns — для тех, кто в теме, кому я и отвечал
Это всё таки публичный форум. Скачал исходники ns, посмотрел. Ты говоришь про EventId? Там строк нет:
uint64_t m_ts; /**< The virtual time stamp. */
uint32_t m_context; /**< The context. */
uint32_t m_uid; /**< The unique id. */
Вот:
class ObjectPtrContainerValue : public AttributeValue
{
public:
/** Iterator type for traversing this container. */
typedef std::map<uint32_t, Ptr<Object> >::const_iterator Iterator;
Здравствуйте, VladD2, Вы писали:
VD>Это не полнота, а заблуждения. Указатели в Шарпе отнюдь не полноценны. Они сильно ограничены. Их можно использовать только в специальном режиме и только помеченной области. Ну, и главное, что они вообще не нужны для написания программ. Они используются только как средство оптимизации.
Это ж не проблема их поставить. Проблема, в том, что ты прав — это довольно ужасное (если используется повсеместно) средство оптимизации. А это мы и хотим переложить на компилятор.
VD>В 7-й версии создали безопасный указатель. Они тоже сильно ограничен. Но еще больше уменьшают потребность в указателях.
Это ты сейчас про что? Span-ов вроде пока нет, а return by ref, имхо, это вообще ни о чём.
VD>Так что сравнивать это не надо.
Ну и ладно. Не надо так не надо.
MA>> Не совсем ясно на что именно ты дал ссылку (что конкретно имел ввиду). Сорри. WH>На код, который уделывает С++ по производительности. WH>На остальное отвечать не буду, ибо ты отвечал на свои фантазии, которые не имеют отношения к тому на что я дал ссылку.
Извини, но ты даёшь ссылку на флэт-топик который неизвестно сколько листать до кода.
Если "уделывает" — значит что-то пошло не так, не? Вроде как очевидно должно быть что если программы делают тоже самое и так же — то и результат закономерен.
Есть куча банальнейших конструкций, которые JIT игнорирует вообще. Например цепочки из N if/else где else это return -1. 8 цепочек — получи 8 джампов в success case. Объем кода растёт неприлично. Намекать на предсказатель тоже не надо — размер кода роялит. Генератор, типа, нитры, афаик, не генерирует goto fail чем решаются все проблемы. Впрочем и не должен. Возьми сюда ещё и то что проверки на выход за границы неустраняются, даже если был предшествующий предикат для этого.
Поэтому, не надо. Я асм достаточно хорошо знаю, что бы видеть какая ерунда генерируется джитом. Его прощает часто только констрейны GC, но... сравнивать тут решительно нечего.
Было бы всё так хорошо — никакого бы .net native не было бы.
Здравствуйте, prezident.mira, Вы писали:
MA>>Тем не менее последние наблюдения меня вводят в некоторое уныние. MA>>1. Типы и Undefined Behavior MA>>Я не понимаю почему в стандарте наконец не определят бихейвор. PM>Это уже объяснялось много раз.
Да не ужели?
MA>>Короче, поинт в том — что UB не место в стандарте. А с размерами типов можно и определится наконец. PM>Смешно.
Смешно читать вопросы топовые на SO еженедельные про одно и тоже. А так же смешно читать ответы про 1s compliment computer, где каждый же пишет что их не видел. Ещё смешно что переполнение у беззнаковых это UB, а у знаковых внезапно нет.
