Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode.

Am 08.10.2017 um 23:49 schrieb bartc:


> But I thought I'd do one quick experiment on one specific program in the
> interpreted language (a very poor benchmark but just trying to see if
> the runtime can be improved):
>
> B B i:=0
>
> B B while i<100 million do
> B B B B ++i
> B B end


Many years ago the AIX compiler came with a similar benchmark, with
computations inside the loop. It demonstrated that the code took a few
seconds on the AIX system, 8 minutes on another workstation, and on the
HP-UX machine I killed the process after one hour. It turned out that
the AIX compiler optimized out the useless computations, and the HP-UX
compiler included clumsy debug features into the code, all that by
default compiler settings. After adding an output statement to the code,
after the loop, it took 8 minutes even on the AIX system, and all
machines were equally fast with explicit settings of the compiler
switches :-]


Loop optimization and CSE are researched and well known since ages, and
cheating in benchmarks also is common practice. With interpreted code or
JIT compilers the impact is not easily predictable, when in contrast to
statically (once) compiled code such optimizations would have to be
applied with every invocation of the program. According hints in the
bytecode may help here - doesn't .NET already allow to include such meta
information in the code, for use by the JIT compiler?


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.