Path: csiph.com!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: bartc Newsgroups: comp.compilers Subject: Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. Date: Tue, 17 Oct 2017 15:54:57 -0400 (EDT) Organization: virginmedia.com Lines: 61 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <17-10-025@comp.compilers> References: <17-10-001@comp.compilers> <17-10-004@comp.compilers> <17-10-009@comp.compilers> <17-10-011@comp.compilers> <17-10-014@comp.compilers> <17-10-017@comp.compilers> <17-10-021@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="27127"; mail-complaints-to="abuse@iecc.com" Keywords: code, performance Posted-Date: 17 Oct 2017 15:54:57 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Content-Language: en-GB Xref: csiph.com comp.compilers:1932 On 11/10/2017 23:13, Hans-Peter Diettrich wrote: > 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 BB i:=0 >> >> B B BB while i<100 million do >> B B B B BB ++i >> B B BB 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 :-] That's always been a problem with comparing the performance of a compiler's code with that of something like gcc -O3. I ended up measuring how long my code took to do a task, with how long gcc took to /not/ do it! Now I don't pay much attention to micro-benchmarks, and especially not to gcc-O3. But I will use the later to measure runtime of a real application, which is a fairer test. > 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? Actually there was a similar effect testing the PyPy version of the Python interpreter. This is a very complicated JIT system (I think few people know exactly how it works). With simple integer benchmarks, it might typically have been double the speed of my own accelerated interpreter (the one with the ASM overlay, but still executing a byte-code at a time, while PyPy probably executed some dedicated native code). But if there was a loop involved, then increasing the count by 10 usually made mine run ten times as long, but the PyPy was only slightly slower! Then comparisons were rendered pointless. PyPy is good at optimising loops. In real applications, PyPy /can/ be very good, if there are many loops with high iteration counts! -- bartc