[Caml-list] Faster byte code

[Caml-list] Faster byte code

[Andy Ray]

Hi,

Xavier; you mentioned during the state of ocaml 2015 talk that there
was a 30% faster bytecode runtime coming.  Is there any more
information on this?  I found this part of the talk difficult to
follow on youtube.

I am mainly interested if there will be a change in the bytecode
runtime, or if it is related to the compiler.

Regards,
Andy

Re: [Caml-list] Faster byte code

[Gabriel Scherer]

I believe the change that was described is the now-merged

  GPR#226: Compiling the run-time system at higher levels of C optimization
  https://github.com/ocaml/ocaml/pull/226

From the experiments reported by Xavier, I have the impression that
most gains are about the way the C compiler optimizes the bytecode
dispatch loop, so these would be specific to running bytecode-compiled
programs. Native programs should also benefit by linking to a
better-optimized runtime system, but no noticeable gains have been
observed on these so far -- probably because a lot of the runtime code
is memory-access-bound and harder to optimize.

Note that we don't have much performance numbers for now, so extra
data points are welcome: if you have a program spending a noticeable
time in specific parts of the runtime system, you might see a gain.

On Sun, Sep 20, 2015 at 12:06 AM, Andy Ray <andy.ray@ujamjar.com> wrote:
> Hi,
>
> Xavier; you mentioned during the state of ocaml 2015 talk that there
> was a 30% faster bytecode runtime coming.  Is there any more
> information on this?  I found this part of the talk difficult to
> follow on youtube.
>
> I am mainly interested if there will be a change in the bytecode
> runtime, or if it is related to the compiler.
>
> Regards,
> Andy
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Faster byte code

[Andy Ray]

Thank you for the explanation.  It is interesting that changing
optimisation levels is something that needs to be done so carefully.

Andy

On Sat, Sep 19, 2015 at 11:32 PM, Gabriel Scherer
<gabriel.scherer@gmail.com> wrote:
> I believe the change that was described is the now-merged
>
>   GPR#226: Compiling the run-time system at higher levels of C optimization
>   https://github.com/ocaml/ocaml/pull/226
>
> From the experiments reported by Xavier, I have the impression that
> most gains are about the way the C compiler optimizes the bytecode
> dispatch loop, so these would be specific to running bytecode-compiled
> programs. Native programs should also benefit by linking to a
> better-optimized runtime system, but no noticeable gains have been
> observed on these so far -- probably because a lot of the runtime code
> is memory-access-bound and harder to optimize.
>
> Note that we don't have much performance numbers for now, so extra
> data points are welcome: if you have a program spending a noticeable
> time in specific parts of the runtime system, you might see a gain.
>
> On Sun, Sep 20, 2015 at 12:06 AM, Andy Ray <andy.ray@ujamjar.com> wrote:
>> Hi,
>>
>> Xavier; you mentioned during the state of ocaml 2015 talk that there
>> was a 30% faster bytecode runtime coming.  Is there any more
>> information on this?  I found this part of the talk difficult to
>> follow on youtube.
>>
>> I am mainly interested if there will be a change in the bytecode
>> runtime, or if it is related to the compiler.
>>
>> Regards,
>> Andy
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Faster byte code

[Adrien Nader]

On Sun, Sep 20, 2015, Andy Ray wrote:
> Thank you for the explanation.  It is interesting that changing
> optimisation levels is something that needs to be done so carefully.
> 

GCC's -O2 optimization level (and -O3 even more) haven't always been as
safe and stable as they currently are. :) 

There are still some compilers easily producing funky outputs used in
production.

Also, I'm wondering whether this change reduces the compiler's own build
times.

-- 
Adrien Nader