Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1932
| 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 <bc@freeuk.com> |
| 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> (permalink) |
| 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 |
Show key headers only | View raw
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
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Opcode handler dispatch in an interpreter: Implementing switch on OpCode. Robert Jacobson <rljacobson@gmail.com> - 2017-10-05 09:29 -0700
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. bartc <bc@freeuk.com> - 2017-10-05 21:14 +0100
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-10-06 02:56 +0200
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. George Neuner <gneuner2@comcast.net> - 2017-10-07 12:55 -0400
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. bartc <bc@freeuk.com> - 2017-10-07 19:05 +0100
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. George Neuner <gneuner2@comcast.net> - 2017-10-08 14:36 -0400
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. bartc <bc@freeuk.com> - 2017-10-08 22:49 +0100
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-10-11 18:13 -0400
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. bartc <bc@freeuk.com> - 2017-10-17 15:54 -0400
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. bartc <bc@freeuk.com> - 2017-10-11 18:12 -0400
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-10-11 18:12 -0400
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. George Neuner <gneuner2@comcast.net> - 2017-10-17 15:55 -0400
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-10-08 13:41 +0000
Re: Opcode handler dispatch in an interpreter: Implementing switch on OpCode. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-10-06 22:32 +0000
csiph-web