Compilers, interpreters, JIT and bytecode
Evaluate translation processes by mechanics, error detection, translation time, execution performance, portability and application context.
Translation choice depends on when work is performed
- explain the mechanics of compilation and interpretation;
- evaluate differences in error detection, translation time, execution, portability and applicability;
- explain bytecode interpreters and just-in-time compilation;
- reach justified choices for rapid development/testing, performance-critical applications and cross-platform development.
Rapid Recall Deck
Attempt each card first. If a term is new, flip and study it, then answer it again without looking. Mark only secure recall as “Know it”.
When translation happens changes the trade-off
Compiled path
source code ↓ compiler target / machine code ↓ execute processor
Explain where translation occurs relative to repeated execution.
The compiler translates the source before normal execution. Once suitable target/native code has been produced, repeated runs can execute that result without interpreting every source statement again.
Interpreted path
source code ↓ interpreter/runtime translate + execute during run ↓ processor actions
Explain why this can help rapid testing but add runtime work.
The programmer can often run changed source immediately through the interpreter, supporting rapid edit-test cycles. However, translation/dispatch work occurs while the program runs, which can reduce execution speed compared with already translated native code.
A complete evaluation uses several dimensions
Compare compiler and interpreter
Compilers perform substantial translation before execution and can identify many translation errors during that stage; generated native code can run quickly but may target a particular architecture/OS. Interpreters execute through a runtime and commonly reveal errors as execution reaches them; they reduce or remove a separate compile step and can aid rapid testing, but add runtime translation/dispatch overhead. Portability depends on whether source or intermediate code can be run by a compatible runtime on each platform.
Intermediate code separates portability from final execution
Bytecode
A source program is translated once into platform-neutral bytecode. Different computers each provide a compatible virtual machine. Explain the portability benefit.
The same bytecode representation can be distributed to multiple platforms. Each platform supplies a runtime/virtual machine that interprets or compiles the bytecode for its own hardware, so the original source need not be translated directly into one platform-specific native executable for every machine.
JIT
Explain why a runtime might JIT-compile frequently executed code instead of interpreting it forever.
JIT compilation pays a translation cost during runtime but can convert frequently executed sections into optimized native code. Later repetitions can then execute faster, combining portable intermediate code with improved runtime performance.
Make the judgement from the dominant requirement
Rapid development
A small team changes code dozens of times per hour and values immediate feedback more than maximum runtime speed.
Likely fit: interpreted/managed workflow because fast edit-run cycles matter.
Performance-critical
A compute-heavy simulation executes the same hot routines billions of times.
Likely fit: ahead-of-time compilation or an effective JIT can reduce repeated translation overhead and optimize execution.
Cross-platform
The same application must run across many systems with compatible runtimes.
Likely fit: portable bytecode/intermediate representation plus platform runtimes can reduce platform-specific rebuilding.
Hybrid systems combine benefits and costs
Evaluate a hybrid runtime
A language compiles source to bytecode, starts by interpreting that bytecode, then JIT-compiles frequently executed sections.
The bytecode supports portability across compatible runtimes. Interpretation can start execution without compiling every path to native code first, but interpreted sections incur runtime overhead. JIT compilation spends extra runtime CPU/memory to translate frequently used sections, after which those hot paths can run faster. The hybrid approach is attractive when both portability and long-running performance matter, but it adds runtime complexity and possible startup/warm-up cost.
The specimen expects cause → execution-speed consequence
Paper 1-style mini-set
1. Explain why compiled code can execute faster than interpreted source code.
2. Explain how bytecode can improve cross-platform portability.
3. Evaluate interpretation for rapid development and testing.
- Compilation performs translation before execution, so the running native/target code does not repeatedly translate/dispatch each source instruction; compilers may also optimize the generated code.
- One intermediate bytecode can run on multiple systems that provide compatible runtimes, which translate/execute it for each platform.
- Interpretation supports quick edit-run feedback and reports encountered errors during execution without a full ahead-of-time compile step, but runtime translation reduces execution performance. It is therefore well suited when development speed dominates final execution speed.
Finish the learning cycle
IA — main task
Continue Criterion D wrap-up and prepare the documentation/video/source-code appendix according to your current IA timeline.
Paper 1 — short practice
Create a four-column comparison for compiler, interpreter, bytecode interpreter and JIT: translation timing, execution behaviour, portability and best-fit scenario.