Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. Date: Wed, 11 Oct 2017 18:13:04 -0400 (EDT) Organization: Compilers Central Lines: 32 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <17-10-021@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> 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="50101"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, code Posted-Date: 11 Oct 2017 18:13:04 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1931 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