Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #1932

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

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


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