LINUX.ORG.RU

Производительность C++

 ,


7

13

Как насчёт производительности у C++ по сравнению с C? Мои предположения на текущий момент:

1) Код, не использующий возможности C++ (то есть по сути plain C), скомпилированный C++ компилятором будет иметь абсолютно ту же производительность, что и код на С.

2) Исключения и dynamic_cast медленные. Если нам важна производительность, лучше их не использовать.

3) Класс без виртуальных методов, должен быть по производительности эквивалентен сишной структуре и функциям, обрабатывающим её. Не считая копирования. Нужно везде, где можно использовать передачу по указателю или ссылке (собственно, если в Си делать memmove при передаче структуры в качестве аргумента, то это вызовет примерно такой же оверхед, как дефолтный конструктор копирования С++. Верно?).

4) Класс с виртуальными методами полностью аналогичен пункту 3, но при вызове виртуальных методов добавляется небольшой оверхед. Сишный эквивалент obj->vtable->func(obj, ...). Если сравнивать с plain C кодом, реализующим ООП в той же манере (каждая структура-объект имеет поле, указывающее на структуру, содержащую адреса функций работы с ней), то оверхеда по сравнению с plain C не должно быть.

5) При использовании атрибута класса final (если компилятор поддерживает соответствующий стандарт) даже при наличии виртуальных методов в нём, их вызов будет превращаться в прямые вызовы функций вместо обращения к vtable, если переменная имеет соответствующий тип, а не указатель/ссылка на его предка (который не final).

6) Шаблоны могут привести к разбуханию кода. Впрочем, #define-ы и inline-функции в C++ могут устроить то же самое. Вопрос: будет ли использование шаблона с одинаковыми параметрами создавать 2 копии реализации или же всё-таки компилятор догадается сделать её лишь один раз. А если шаблон используется с одинаковыми параметрами в нескольких объектных файлах? Будет ли реализация расшариваться между ними или у каждого своя?

7) Что насчёт inline-методов класса? (те, которые описываются прямо в момент определения самого класса, внутри блока class). Может ли их реализация расшариваться между модулями или в каждом будет своя копия (допустим, метод слишком длинный, чтобы инлайнится в момент вызова)?

Я не претендую на правоту, какие-то утверждения могут быть ложными. Хотел бы узнать, как обстоят дела на самом деле. А также какие подводные камни я ещё не знаю. Разумеется, речь идёт о последних версиях gcc/clang с включённой оптимизацией не ниже -O2.

★★★★★

Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от eao197

Еще туча совсем мелких проектиков, которые используют разработки вроде Wt для Web-морд на разных умных устройствах.

Такое себе.

А если еще и WebAssembly взлетит,

вебасм - это днище. Ты реально думаешь, что эти упоротые сделают что-то вменяемое? Их же сожрут жс-хомячки с потрохами.

Сейчас жс жив(хотя уже мёртв д/кофе/тайпскрипт) только потому, что конкурентов ему нет. Т.е. пистонист/пхпист не может писать под браузёрку. Всё равно нужен жс"ер.

Нода в этом плане ещё более принижает не жс"еров, т.е. если раньше надо было держать ждангиста+жс"ер - сейчас можно держать одних жс"еров.

то для C++ место найдется не только на бэк-энде.

Основная проблема не в этом - нужен не вебасм, а api к броузеру не на жс. И при этом оно не должно быть той мочёй, что есть сейчас. В то, что это когда-нибудь случится - я не верю.

Сейчас есть емскриптен, но писать на С++ с ним не представляется возможным, ибо он предназначен для эмуляции не броузера в броузере. Т.е. чисто для конпеляции десктопных приложений/кода.

Судя по тому, что вебасм представляет из себя сейчас - такой он не нужен.

Как пишущий сайтик на С++ - заявляю - писать адская боль.

AnonCxx
()
Ответ на: комментарий от anonymous

Аледятел, тупица ты чмошная, WebAssembly на роль IR для JIT вообще не канает. По тем же самым причинам, почему не канает LLVM.

anonymous
()
Ответ на: комментарий от anonymous

Насколько я помню asmjs не jit, а сразу компилируется, не? Зачем вообще для «IR» нужен jit? Кода в броузерке 5копеек кода, оптимизировать не надо - это можно делать на уровне ллвм.

Там ir нужен только для то, чтобы поцаны не вставили syscall - собрал-запустил. Там эти 200кило кода соберутся быстрее, чем текущий jit.

При этом вебчик это такая штука, что там лишнего кода мало и от жита профита мало.

AnonCxx
()
Ответ на: комментарий от AnonCxx

Даже не знаю, как до тебя такую простую мысль донести, чтоб тебе понятно было. Скажем так, ты пытаешься разговаривать с ушлепком, который еще десять лет назад на ЛОРе был полным ушлепком, и с тех пор только сильнее деградировал. Охреневаю с твоего терпения.

Кстати, тылгуня тоже ничуть не лучше и тоже стремительно деградирует.

anonymous
()
Ответ на: комментарий от anonymous

Все, практически, весь юзерспейс там давно на дотнете. Кортаны всякие, edge — все на F#/C#.

Вот прям свежак: https://github.com/MicrosoftEdge/WebGL — кусок из Edge на GitHub-е, один сплошной F# и C# впридачу.

Ну и еще оттуда же: https://github.com/Microsoft/ChakraCore — движок JavaScript-а из того же Edge. Опять сплошной F# с C#. Правда, тут опять царь насрет целую простыню текста о «не том C++».

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Причём тут я? :-) И откуда в тебе столько злости? :-) Небось, и ладошки мокренькие у тебя, нервного :-) Не стоит оно того, ведь если ты не обоснуешь сейчас свой взбрык, и что ты лично мне сказать хотел, то всё что ты о себе оставить в моей памяти - плотные ладошки от нервного перенапряга :-) Лол :-) Теперь давай, пыхти и обосновывай :-)

anonymous
()
Ответ на: комментарий от anonymous

А как ты думаешь, примазываться к эксцентричным и харизматичным персонами - это признание собственной слабости или особенность мышления? :-)

anonymous
()
Ответ на: комментарий от anonymous

Если ты сам не видишь, насколько ты дебил, то тебе уже ничего не поможет.

Что такое tracing JIT понимаешь, тупица? А что такое basic block понимаешь? И какого размера basic block в SSA догадываешься?

Никому вообще в голову никогда не придет делать tracing JIT поверх LLVM, WebAssembly, C-- и тому подобного. Все эти IR годятся только для статической компиляции.

anonymous
()
Ответ на: комментарий от eao197

Правда, тут опять царь насрет целую простыню текста о «не том C++».

Ну там там да - типичный С/С++. Правда код совсем моча - ну это такое.

Боязнь шаблонов, боязнь С++, боязнь всего.

static uint32 Log2(uint32 value)
    {
        int i;

        for (i = 0; value >>= 1; i++);
        return i;
    }

M - math.

AnonCxx
()
Ответ на: комментарий от anonymous

Только дебил может предложить транслировать js в webassembly. Идиотизм примерно того же порядка, что транслировать smalltalk в llvm.

anonymous
()
Ответ на: комментарий от anonymous

Если ты сам не видишь, насколько ты дебил, то тебе уже ничего не поможет.

Дёшево, не напрягайся и протри ладони :-) Это пустое :-)

Что такое tracing JIT понимаешь, тупица? А что такое basic block понимаешь? И какого размера basic block в SSA догадываешься?

Какое отношение весь этот набор элементарных предложений с терминами, вырванными из разных контекстов, а потому, имеющих разное значение в разных случаях, имеет ко мне? :-) Лол :-)

Никому вообще в голову никогда не придет делать tracing JIT поверх LLVM, WebAssembly, C-- и тому подобного. Все эти IR годятся только для статической компиляции.

Не знаю, причём тут я вообще, но согласно этому треду, есть персоны, которым в голову пришло std::string использовать как класс для ошибки, а также персоны, которые такой стиль одобряют :-) А V8 таки компилит JavaScript в нативный код :-)

anonymous
()
Ответ на: комментарий от anonymous

Только дебил может предложить транслировать js в webassembly. Идиотизм примерно того же порядка, что транслировать smalltalk в llvm.

Ну так если ты умница и у тебя есть светлые предложения, ты обоснуй их, дай ссылку на свои труды и обоснования, хотя бы на бложик какой-нибудь свой, тогда твоё мнение по поводу JavaScript для WebAssebmly, или для мало кому нужного Smalltalk для LLVM и будет хоть как-то убедительно :-) Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

Никому вообще в голову никогда не придет делать tracing JIT поверх LLVM, WebAssembly, C-- и тому подобного. Все эти IR годятся только для статической компиляции.

Как минимум 3 раза приходила в голову мысль сделать JIT на для динамических языков на LLVM: Unladen Swallow, FTL JIT, Pyston. И, вроде, какой-то JIT для Ruby

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Аледятел, кроме тебя, дебила, никто и не предлагает жопаскрипт в webassembly транслировать.

И почему вообще такие IR не годятся - читай тут: http://qinsb.blogspot.co.uk/2011/03/unladen-swallow-retrospective.html

Архитектуру трассирующего жыта читай тут: http://jayconrod.com/posts/51/a-tour-of-v8-full-compiler

Особенно обрати внимание на аргументацию в «Why no bytecode?»

anonymous
()
Ответ на: комментарий от anonymous

Какое отношение весь этот набор элементарных предложений с терминами, вырванными из разных контекстов, а потому, имеющих разное значение в разных случаях, имеет ко мне?

Але, дебил, не отмазывайся теперь, это был ТЫ кто предлагал жопаскрипт в webassembly компилировать.

А V8 таки компилит JavaScript в нативный код

А вот это уже к твоему обсёру никакого отношения не имеет.

anonymous
()
Ответ на: комментарий от anonymous

Ни один не был трассирующим. Для жопаскрипта это обязательно.

Не был?

«The first execution of any function always starts in the interpreter tier. As soon as any statement in the function executes more than 100 times, or the function is called more than 6 times (whichever comes first), execution is diverted into code compiled by the Baseline JIT. This eliminates some of the interpreter’s overhead but lacks any serious compiler optimizations. Once any statement executes more than 1000 times in Baseline code, or the Baseline function is invoked more than 66 times, we divert execution again to the DFG JIT.»

Архитектуру трассирующего жыта читай тут: http://jayconrod.com/posts/51/a-tour-of-v8-full-compiler

«There is no interpretation and no bytecode. Compilation is done one function at a time (as opposed to trace-based compilation as used in TraceMonkey, the old FireFox VM).»

Где там трассировка? И почему ни в одной из 4-х статей нет заявления «мы написали tracing JIT»?

Какая трассировка без интерпретатора? https://morepypy.blogspot.com.by/2009/03/applying-tracing-jit-to-interpreter....

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Так ты еще и дислексик, дятел? Читать не умеешь?

V8 тут *backend* к WebAssembly, а вовсе не наоборот.

anonymous
()
Ответ на: комментарий от tailgunner

А некоторые на нервной почве смайлики сыплют.

Это на почве веселья :-)

И где там написано о компиляции JS в WebAssembly? Процитируй.

Так а кто предложил компилировать JavaScript в WebAssembly? :-) Тобой был задан вопрос о том, какой распространённый язык имеет компилятор в нативный код :-) Одним из корректных ответов был JavaScript и V8 соответственно :-) Также было сказано, что JavaScript является языком номер один в вебе :-) Зачем ты сейчас напрасно тратишь время? :-) Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

А некоторые на нервной почве смайлики сыплют.

Это на почве веселья :-)

Это у тебя нервное.

И где там написано о компиляции JS в WebAssembly? Процитируй.

Так а кто предложил компилировать JavaScript в WebAssembly? :-)

Ты. Причем не предложил, а сказал, что так и будет.

Зачем ты сейчас напрасно тратишь время?

Интересно же понять, как мыслит подросток.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от anonymous

V8 тут *backend* к WebAssembly, а вовсе не наоборот.

Да, но V8 таки умеет JavaScript в нативный код :-) Ты же с этим спорить не будешь? :-) Вот и молодец, гуляй чаще, это полезно для здоровья :-)

anonymous
()
Ответ на: комментарий от tailgunner

Ты. Причем не предложил, а сказал, что так и будет.

Конечно же было сказано, что JavaScript был и будет языком номер один в вебе, а не то, что ты пытаешься кому-то приписать :-) И вообще, тратить время на дискуссию с тем, кто трёт неудобные комментарии и банит по IP считаю ниже своего достоинства :-) Всего хорошего :-)

anonymous
()

Сишный эквивалент obj->vtable->func(obj, ...).

Компиляторы (gcc, clang) умеют их оптимизировать до прямого вызова, иногда.

Kuzy ★★★
()
Ответ на: комментарий от RazrFalcon

5) Разве final не компайлтайм проверка, что наследники не могут переопределять этот метод? В рантайме разницы с обычным virtual быть не должно.

Она, а еще компилятор точно знает, что если виртуальная функция вызвана для этого типа, то не нужно смотреть vtable.

Kuzy ★★★
()
Ответ на: комментарий от annulen

Да не нужен никакой final, девиртуализацию в этой ситуации только совсем тупой компилятор не сделает

Нужен. Например, если код в разных единицах трансляции, то точно нужен.

Kuzy ★★★
()
Последнее исправление: Kuzy (всего исправлений: 1)
Ответ на: комментарий от anonymous

А если таки нужен «C с классами»? Всё же в C++ и без исключений есть достаточно много полезного сахара. А писать простыни макросов на Си для реализации ООП своими силами - это и есть кушанье кактусов. Ибо вместо 10 строчек получается 100. Производительность труда программиста падает, вероятность появления багов растёт.

Вот, допустим, у тебя есть две сумки. Одна большая, другая маленькая. В маленькую нифига не влезают твои вещи, а большую влезает, но остаётся много свободного пространства. Какую сумку ты выберешь? Любой нормальный человек выберет большую сумку, а не будет тащить часть вещей в руках (именно это ты и предлагаешь). Язык должен уметь не меньше, чем нужно программисту. Если же он умеет больше, ничто не мешает не использовать ненужную часть.

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

KivApple ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Потому что в типичном use-case этой либы программе нафиг не нужно знать больше информации об ошибке. Ей тупо надо показать максимально информативное сообщение ПОЛЬЗОВАТЕЛЮ.

KivApple ★★★★★
() автор топика
Ответ на: комментарий от lovesan

Visual Studio 100 лет как на дотнете.

VisualStudio 100 лет как сборище COM-объектов. С появлением .NET-а и добавления поддержки .NET-а в VS часть этих COM-объектов реализована на .NET-е. Часть.

eao197 ★★★★★
()
Ответ на: комментарий от lovesan

Сказал как отрезал. И поэтому люди уже 20 лет пишут драйвера под Windows на C++. Okay.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

И вообще, тратить время на дискуссию с тем, кто трёт неудобные комментарии и банит по IP считаю ниже своего достоинства :-) Всего хорошего :-)

Бгг. Ну, скатертью.

tailgunner ★★★★★
()
Ответ на: комментарий от lovesan

Можно подумать кресты не являются настолько же устаревшим, и еще более ублюдочным говном.

Тебе лучше вообще не думать, а то такая хрень получается...

tailgunner ★★★★★
()

хм. странно. думал тему уже прибили к уям и всем выдали по значку за участие в баталии.

anonymous
()
Ответ на: комментарий от anonymous

Да кого ипет нативный код, утырок? Ты про webassembly тявкал, который никаким боком к JITам динамических языков не относится.

anonymous
()
Ответ на: комментарий от tailgunner

Да, v8 таки тупо profile-driven, а не трассирующий. Не хочу в сортах говна разбираться - что spiderminkey, что v8, один динамический кал. Все равно, SSA-based низкоуровневые IR не годятся ни для одного из этих типов JITов. Только для статической консервативной компиляции без какой либо динамики (как в mono).

anonymous
()
Ответ на: комментарий от eao197

Маня, ты это коллегам-крестовикам рассказывай.

Visual Studio - это WPF приложение с дремучих версий. Managed Application. Как еще тебе написать? А к версии 2015 там вообще все остатки крестов вычистили. И правильно.

https://www.quora.com/As-of-2015-how-much-of-Microsoft-Visual-Studio-is-writt...

Что до драйверов. Опять же, повторюсь, изначально вопрос был поставлен про ядро. Так вот - ядро на чистом Си. Драйвера - ну некоторые может пишут и на крестах, оттого эти драйвера падают и глючат. Но большинство - на Си. Потому что, во-первых, я, припоминая как писать под винду драйвера, не могу понять где там место плюсам вообще, зачем они там нужны то, а во-вторых, в драйверах, и особенно под винду, надо понимать где, как и что может долбануться, и контролировать каждое движение рук, чего естественно, C++, не позволяет.

lovesan ★★★
()
Ответ на: комментарий от lovesan

Маня,

За базаром следите.

Visual Studio - это WPF приложение с дремучих версий.

А для вас дремучие — это какие? Может 4.0? Или 97? Или 2002?

А к версии 2015 там вообще все остатки крестов вычистили. И правильно.

Ну молодцы, чо, за 13 лет справились.

Так вот - ядро на чистом Си.

Откуда дровишки?

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

Специфическая тема, специфическое место.

Я сомневаюсь, что вброс подобной темы на мейлрушечку, или вДурова привлечет больше соображающих людей, чем это можно сделать в соответствующей тематической ветке псевдоанонимного форума для отморозков.

К тому же внимание домохозяек и прочих школьников вбрасывателям как раз нинужно, а то еще думать головой начнут, прежде чем отправить СМС типа:«Зая, я убила мента! Прости...»

shkolnick-kun ★★★★★
()
Ответ на: комментарий от eao197

А есть области, в которых работает ну тысяча или пару тысяч человек во всем мире. Ну выйдет какая-то OpenSource либо для такой области. Желающих поюзать нахаляву найдется несколько десятков.

Да, может и несколько тысяч найтись.

И наверняка какие-то фич-реквесты пойдут.

Для этого делают открытый комьюнити эдишон, который можно использовать в качестве инкубатора, пока проект (или отдельная экспериментальная фича в нем) не обретет зрелость, и закрытый коммерческий вариант, который опережает его по фичам на несколько релизов/лет.

Но вот с контрибьторами дело будет хуже.

Да.

Посему стоимость владения не только не снизится, но может и возрастет.

Это будет зависеть от подхода к управлению проектом.

Откуда встанет вопрос: а нафига было открывать?

Если нет мозгов, то да.

В целом согласен с Вашим утверждением.

shkolnick-kun ★★★★★
()
Ответ на: комментарий от anonymous

Да кого ипет нативный код, утырок? Ты про webassembly тявкал, который никаким боком к JITам динамических языков не относится.

Но ведь вопрос был о том, какие широко распространённые языки программирования можно компилировать в нативный код :-) V8 может компилировать JavaScript в нативный код :-) Каков привет, таков ответ, как говорится :-) Ты столько уже пены выпустил, а понять элементарного вопроса так и не смог :-) Всего хорошего :-)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.