Нуборазмышления по поводу интерпретируемых Java\python\c# и компилируемых с++\с итп?

Question

[yourisus]

Интерпретируемый язык - проходит 2 стадии вместо одной ( интерпретация в байт код и компиляция), компилируемый язык - 1 стадия( компиляция).
Интерпретатор(пример jvm) все равно ведь компилирует байт-код и получает тоже, что и если бы мы писали на си.
То есть если написать код, который будет просто складывать два числа и выводить результат на java и на си.
Алгоритм компиляции такой:
prog.java -> prog.bytejava -> prog_byte.asmbl
prog.c -> --------------------- -> prog.asmbl
Значит ли это, что если запустить prog_byte.asmbl и prog.asmbl время их выполнения будет одинаковым?
Ведь 90+% в игре это текстуры, а значит это должна делать видеокарта, а не процессор.
То значит откомпилированная игра на Java, может не уступать по производительности игре написанной на с++?

Answer 1

[Saboteur]

С чего вы взяли, что в игре 90% это текстуры?
Что значить "делать текстуры"? Видеокарта наштампует вам текстур, а что с ними делать? Кто будет вычислять что выводить, в каком порядке, почему?
Как именно java связывается в видеокартой? Она же не может слать в нее напрямую, как минимум ваша программа должна общаться с драйвером видеокарты.
А до драйвера видеокарты можно использовать графический фреймворк, иначе вам нужно изучть оптику, 3д моделирование, геометрию на таком уровне, что начать писать игру вы начнете лет через 10-15.
А для C++ под винду есть готовый DirectX, который сделает за вас 90% работы. А под java нет DirectX...

В общем, вы не совсем то пытаетесь посчитать.

Answer 2

[Даниил Колесниченко]

Интерпретируемый язык - проходит 2 стадии вместо одной ( интерпретация в байт код и компиляция), компилируемый язык - 1 стадия( компиляция).

Ох. Во-первых, не бывает интерпретируемых или компилируемых языков. Для любого языка можно написать реализацию как в виде интерпретатора, так и в виде компилятора. Во-вторых, не бывает «интерпретации в байт-код», интерпретация вообще не может быть «во что-то». Интерпретация — это непосредственно исполнение кода программы другой программой.

На деле реализации ЯП можно поделить примерно следующим образом:

• Трансляторы
  • Трансляторы в низкоуровневые языки (компиляторы)
    • Ahead-of-Time компиляторы (компилируют один раз, заранее)
      
    • Just-in-Time компиляторы (компилируют прямо во время выполнения программы, «на лету»)
      
  • Трансляторы в высокоуровневые языки
    
• Интерпретаторы
  

Так, например, GCC — статический компилятор, OpenJDK — транслятор в байт-код + JIT-компилятор байт-кода, CPython — транслятор в байт-код + интерпретатор байт-кода.

Для языков со статической типизацией и ручным управлением памятью (C, C++, Rust etc) наиболее эффективными оказываются статические (AOT) компиляторы. Для динамических же языков со сборщиком мусора зачастую эффективнее оказывается компиляция «на лету» (just-in-time), поскольку это позволяет компилятору использовать статистику запусков для сложных оптимизаций. «Настоящие» интерпретаторы (т. е. не являющиеся на самом деле JIT-компиляторами) обычно оказываются медленнее компиляторов.

То значит откомпилированная игра на Java, может не уступать по производительности игре написанной на с++?

Может, если реализация на C++ низкого качества. В общем случае код на Java будет медленнее аналогичного на C++, из-за сборщика мусора и type erasure.

Answer 3

[Дмитрий Ковальский]

Перед тем как искать повышение производительности в компиляторе - необходимо убедиться что сам ваш код уже использует максимально эффективные решения. И вот когда уже все у вас в алгоритмах и методах хранения данных ИДЕАЛЬНО - вот тогда начинаем задумываться о компиляции проекта. JIT-компилятор на C# например тормозит вас только на первом запуске проекта(когда собственно происходит компиляция в ассемблер). Затем все тормоза уже вызваны скоростью работы CLR(JVM в случае Java) и самих библиотек.

Answer 4

[theurs]

байт код это по сути ассемблер для другого процессора, не х86-64, для его выполнения нужна особая виртуализация или интерпретация