#c #performance #compilation #unreal-engine4 #unreal-blueprint
Вопрос:
например
Существует визуальный язык сценариев (язык компиляции), который построен на c , я имею в виду чертежи в UE-4. но это считается более медленным, чем c , но почему ?? поскольку чертежи снова преобразуются в c , и это делается во время компиляции, поэтому никакой разницы в производительности не должно быть во время выполнения ?
Комментарии:
1. C — это язык высокого уровня и язык низкого уровня, и он также устраняет разрыв между ними. Никто не называет это медленным. Однако языки сценариев — они, как правило, медленные, если их запускает переводчик. Если язык сценариев генерирует C , то вопрос в том, сопоставимо ли качество этого C с тем, что может быть написано вручную. Другими словами, когда вы вручную записываете шаги в C , вы можете увидеть возможности оптимизации и избежать ненужной работы. Если это здесь неприменимо, то действительно инструмент создания сценариев будет выдавать результаты так же быстро, как C .
2. Теоретически скомпилированный код работает быстрее, чем интерпретируемый код. На самом деле это смешанный пакет. Вы можете написать очень плохой, медленно формируемый скомпилированный код и очень быстро интерпретируемый код. Мой совет, закодируйте его, измерьте его производительность, а затем решите, нужно ли вам больше или это приемлемо.
3. (Стоит отметить, что между C и сборкой существует аналогичная взаимосвязь. C не может быть быстрее, чем тщательно написанная сборка, но ни у кого нет времени тщательно писать огромные программы в сборке, поэтому в среднем C почти всегда быстрее. Аналогично, C имеет тенденцию — в практическом смысле — позволять вам писать более быстрые программы, чем C, в основном потому, что вы можете быстро выполнять задачи, не связанные с критической производительностью, а затем сосредоточиться на критической производительности и использовать, например, шаблоны для создания «пользовательских» экземпляров функций, что заняло бы много времени в C)
4. С точки зрения схемы — она может быть явно скомпилирована на C . Однако это относительно новая функция, и ее не так часто обсуждают. Это довольно прилично, но не идеально, нативизированный код поставляется с метрической тонной котельной плиты и сохраняет множество вещей, таких как чрезмерно интенсивное использование отражения и неэффективный поиск. Кроме того, вы теряете контроль, который дает C при выделении памяти, многопоточности, встроенной сборке, организации согласованности горячих данных/кэша и т. Д.. Невозможно количественно оценить, насколько плох нативизированный штраф blueprint, кроме как сказать, что он находится где-то между интерпретируемым bp и собственным C
5. Спасибо всем, теперь я понимаю, что речь идет о контроле, который получает программист, который при правильном использовании может привести к лучшей оптимизации, а не к автоматическому переводу кода из компилятора (то есть переводу с высокого уровня на промежуточный язык), но я хотел знать, когда интерпретаторы предпочтительнее компиляторов ? , и всякий раз, когда мы загружаем программное обеспечение, компилируется ли код во время установки, если нет, то когда ?
Ответ №1:
Поскольку компьютеры могут понимать только машинный код, который является низкоуровневым, а языки высокого уровня более похожи на человеческий язык, это далеко от понимания компьютера. Для компиляции и изменения исходного кода на машинный требуется время. Поэтому он более медленный, чем язык низкого уровня.
Комментарии:
1. Это просто неправильно. Время компиляции совершенно не связано с производительностью — Rust, язык довольно высокого уровня, достигает скорости, которая конкурирует с C, языком существенно более низкого уровня, но все же в целом языком высокого уровня. Время компиляции != производительность != высокий уровень медленнее, чем низкий уровень.
2. Я думаю, вы проводите различие между скомпилированными и интерпретируемыми во время выполнения языками? Однако вопрос оп на самом деле был не об этом (они говорят о дополнительном шаге компиляции в c ). Объяснение также невероятно непрофессионально.