unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Guile benchmark
@ 2017-01-26  8:39 Rchar
  2017-01-26 21:56 ` Mike Gran
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Rchar @ 2017-01-26  8:39 UTC (permalink / raw)
  To: guile-user@gnu.org

Hello,
I wanted to compare Guile scheme to other scheme implementations and I found this:https://ecraven.github.io/r7rs-benchmarks/benchmark.html

Is Guile slow or fast, comparing to others?
Is Guile scheme slows down entire GuixSD (If Guile speeds up, GuixSD also speeds up)?
Recently I found scheme compared to C, is it even possible?

Please help answering these questions, and share your opinion.



Regards
rchar

sidhu1fveeouoe

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Guile benchmark
  2017-01-26  8:39 Guile benchmark Rchar
@ 2017-01-26 21:56 ` Mike Gran
  2017-01-26 22:11   ` Linas Vepstas
  2017-01-30 14:16 ` Ludovic Courtès
  2017-02-27 20:00 ` Andy Wingo
  2 siblings, 1 reply; 9+ messages in thread
From: Mike Gran @ 2017-01-26 21:56 UTC (permalink / raw)
  To: Rchar, guile-user@gnu.org





On Thursday, January 26, 2017 7:31 AM, Rchar <rchar@protonmail.com> wrote:


> Is Guile slow or fast, comparing to others?

Guile is about average compared to the others. But it depends
on the specific task. It is usually not the fastest or slowest.

> Recently I found scheme compared to C, is it even possible?


Not really.  A Guile program should be coded to take advantage
of Guile.   A C program should be coded to take advantage of C.
The programs should have a very different structure.

If you coded a Guile program to have the same structure and algorithms
as a C program, the C program would be faster.

Mike



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Guile benchmark
  2017-01-26 21:56 ` Mike Gran
@ 2017-01-26 22:11   ` Linas Vepstas
  0 siblings, 0 replies; 9+ messages in thread
From: Linas Vepstas @ 2017-01-26 22:11 UTC (permalink / raw)
  To: Mike Gran; +Cc: Rchar, guile-user@gnu.org

On Thu, Jan 26, 2017 at 3:56 PM, Mike Gran <spk121@yahoo.com> wrote:

>
> On Thursday, January 26, 2017 7:31 AM, Rchar <rchar@protonmail.com> wrote:
>
>
>> Is Guile slow or fast, comparing to others?
>
> Guile is about average compared to the others. But it depends
> on the specific task. It is usually not the fastest or slowest.

FWIW, I have C++ code that has bindings both to guile and to python,
via cython.  The guile bindings were faster than python, which then
caused the cython maintainer to enter a nuclear arms race, to improve
performance, doing things like caching values in various places to improve
performance.  But then, one can do the same in guile, and it becomes a
game of who can be more clever in optimizing.

I do have one complaint: guile has a fairly hefty overhead in entering
and exiting: I forget now, and the measurements were done on a
circa-2011 PC, but I was getting something like 7K guile enter-exits
per second, which limits the speed at which you can cross the C/guile
boundary.   You can avoid this cost by entering guile and then caching,
but this requires some C-coding cleverness that naive users won't do.
(I'm currently getting maybe 500K/sec or 1M/sec guile-C crossings, but
only if I do this caching trick).

--linas



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Guile benchmark
  2017-01-26  8:39 Guile benchmark Rchar
  2017-01-26 21:56 ` Mike Gran
@ 2017-01-30 14:16 ` Ludovic Courtès
  2017-02-27 20:00 ` Andy Wingo
  2 siblings, 0 replies; 9+ messages in thread
From: Ludovic Courtès @ 2017-01-30 14:16 UTC (permalink / raw)
  To: guile-user

Hi,

Rchar <rchar@protonmail.com> skribis:

> Is Guile scheme slows down entire GuixSD (If Guile speeds up, GuixSD also speeds up)?

GuixSD is a GNU/Linux distro and even if some components are written in
Guile (such as the Shepherd and some low-level helpers), most of it is
written in C.

Guile’s speed has an influence on the speed of ‘guix’ commands though.

Ludo’.




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Guile benchmark
  2017-01-26  8:39 Guile benchmark Rchar
  2017-01-26 21:56 ` Mike Gran
  2017-01-30 14:16 ` Ludovic Courtès
@ 2017-02-27 20:00 ` Andy Wingo
  2017-02-27 23:35   ` Chris Vine
  2 siblings, 1 reply; 9+ messages in thread
From: Andy Wingo @ 2017-02-27 20:00 UTC (permalink / raw)
  To: Rchar; +Cc: guile-user@gnu.org

Hi,

On Thu 26 Jan 2017 09:39, Rchar <rchar@protonmail.com> writes:

> I wanted to compare Guile scheme to other scheme implementations and I found this:https://ecraven.github.io/r7rs-benchmarks/benchmark.html
>
> Is Guile slow or fast, comparing to others?

Besides what Mike said, there are two kinds of Schemes in that
benchmark: the ones that compile to native machine code (ahead of time,
either with their own compilers or by emitting C, or just-in-time), and
the ones that run some kind of bytecode interpreter.

Schemes that compile to native code go faster.  Guile compiles to
bytecode right now, so it's generally (though not always!) slower than
the native-compiling schemes.  But compared to the bytecode-interpreter
schemes it's pretty fast.

One day we'll have a native compiler and we can start playing benchmark
games with the big kids :)

Andy



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Guile benchmark
  2017-02-27 20:00 ` Andy Wingo
@ 2017-02-27 23:35   ` Chris Vine
  2017-02-28 10:28     ` Arne Babenhauserheide
  0 siblings, 1 reply; 9+ messages in thread
From: Chris Vine @ 2017-02-27 23:35 UTC (permalink / raw)
  To: guile-user

On Mon, 27 Feb 2017 21:00:54 +0100
Andy Wingo <wingo@pobox.com> wrote:
> Hi,
> 
> On Thu 26 Jan 2017 09:39, Rchar <rchar@protonmail.com> writes:
> 
> > I wanted to compare Guile scheme to other scheme implementations
> > and I found
> > this:https://ecraven.github.io/r7rs-benchmarks/benchmark.html
> >
> > Is Guile slow or fast, comparing to others?  
> 
> Besides what Mike said, there are two kinds of Schemes in that
> benchmark: the ones that compile to native machine code (ahead of
> time, either with their own compilers or by emitting C, or
> just-in-time), and the ones that run some kind of bytecode
> interpreter.
> 
> Schemes that compile to native code go faster.  Guile compiles to
> bytecode right now, so it's generally (though not always!) slower than
> the native-compiling schemes.  But compared to the
> bytecode-interpreter schemes it's pretty fast.
> 
> One day we'll have a native compiler and we can start playing
> benchmark games with the big kids :)

On reading this, out of interest I wrote a very simple program solving
primes, using the basic 'seive odd divisors to square root' algorithm.
I tested guile-2.0, guile-2.2, chicken and chez scheme on it.

guile-2.0 was a little slower than chicken with chicken compiled to C,
but guile-2.2 on that test took about 75% of the time of chicken, and
about 50% of the time of guile-2.0.  chez scheme was fastest of all,
taking about 50% of the time of chicken.  OK, chicken may not be the
fastest of "compile to C" schemes.

Having said that, all of them were considerably slower than the same
code written in native C++, probably because the compiler optimizes
better (it was about 5 times faster than chez scheme).  The performance
of clang and gcc was pretty much the same.

Solving primes is probably not particularly representative and I didn't
spend any more time with other benchmarks, so take it as you will. The
performance of guile-2.2 at run time was encouraging however.

Chris



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Guile benchmark
  2017-02-27 23:35   ` Chris Vine
@ 2017-02-28 10:28     ` Arne Babenhauserheide
  2017-02-28 12:55       ` Chris Vine
  0 siblings, 1 reply; 9+ messages in thread
From: Arne Babenhauserheide @ 2017-02-28 10:28 UTC (permalink / raw)
  To: Chris Vine; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]


Chris Vine <chris@cvine.freeserve.co.uk> writes:

> On Mon, 27 Feb 2017 21:00:54 +0100
> Andy Wingo <wingo@pobox.com> wrote:
>> Hi,
>> 
>> On Thu 26 Jan 2017 09:39, Rchar <rchar@protonmail.com> writes:
>> > https://ecraven.github.io/r7rs-benchmarks/benchmark.html
>> > Is Guile slow or fast, comparing to others?  
>> 
>> Schemes that compile to native code go faster.  Guile compiles to
>> bytecode right now, so it's generally (though not always!) slower than
>> the native-compiling schemes.  But compared to the
>> bytecode-interpreter schemes it's pretty fast.
>
> On reading this, out of interest I wrote a very simple program solving
> primes, using the basic 'seive odd divisors to square root' algorithm.
> I tested guile-2.0, guile-2.2, chicken and chez scheme on it.
>
> guile-2.0 was a little slower than chicken with chicken compiled to C,
> but guile-2.2 on that test took about 75% of the time of chicken, and
> about 50% of the time of guile-2.0.  chez scheme was fastest of all,
> taking about 50% of the time of chicken.  OK, chicken may not be the
> fastest of "compile to C" schemes.

Do I read this correctly that Chez took only about 30% less time than
Guile 2.2?

Could you try stalin, too? (Chez wins 28 comparisons, Stalin 14, so that
would be an obvious target)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Guile benchmark
  2017-02-28 10:28     ` Arne Babenhauserheide
@ 2017-02-28 12:55       ` Chris Vine
  2017-03-01  0:24         ` Arne Babenhauserheide
  0 siblings, 1 reply; 9+ messages in thread
From: Chris Vine @ 2017-02-28 12:55 UTC (permalink / raw)
  To: Arne Babenhauserheide; +Cc: guile-user

On Tue, 28 Feb 2017 11:28:32 +0100
Arne Babenhauserheide <arne_bab@web.de> wrote:
> Chris Vine <chris@cvine.freeserve.co.uk> writes:
> 
> > On Mon, 27 Feb 2017 21:00:54 +0100
> > Andy Wingo <wingo@pobox.com> wrote:  
> >> Hi,
> >> 
> >> On Thu 26 Jan 2017 09:39, Rchar <rchar@protonmail.com> writes:  
> >> > https://ecraven.github.io/r7rs-benchmarks/benchmark.html
> >> > Is Guile slow or fast, comparing to others?    
> >> 
> >> Schemes that compile to native code go faster.  Guile compiles to
> >> bytecode right now, so it's generally (though not always!) slower
> >> than the native-compiling schemes.  But compared to the
> >> bytecode-interpreter schemes it's pretty fast.  
> >
> > On reading this, out of interest I wrote a very simple program
> > solving primes, using the basic 'seive odd divisors to square root'
> > algorithm. I tested guile-2.0, guile-2.2, chicken and chez scheme
> > on it.
> >
> > guile-2.0 was a little slower than chicken with chicken compiled to
> > C, but guile-2.2 on that test took about 75% of the time of
> > chicken, and about 50% of the time of guile-2.0.  chez scheme was
> > fastest of all, taking about 50% of the time of chicken.  OK,
> > chicken may not be the fastest of "compile to C" schemes.  
> 
> Do I read this correctly that Chez took only about 30% less time than
> Guile 2.2?
> 
> Could you try stalin, too? (Chez wins 28 comparisons, Stalin 14, so
> that would be an obvious target)

I feared that my enumeration might confuse.

No, on my Haswell laptop running 64-bit linux, solving the 40,000th
prime (479909) is 1.26 times faster in chez scheme than in guile-2.1.7,
on the simple algorithm. (0.509 seconds versus 0.624 seconds, on a
i7-4712HQ CPU @ 2.30GHz.)  This is only the time taken in the body of
the calculation.  Start-up times and printing times and so forth are
ignored.

I have just tried out the same code on an older Sandybridge desktop
@3.30 GHz running 32-bit linux which I can access remotely, and that had
chez scheme 1.7 times faster than guile-2.1.7 so it looks to be
somewhat CPU and/or cache and/or pointer-width sensitive. Anyway, it is
just one benchmark.

I think I am about schemed out so installing Stalin is probably not an
option.  Like you, I am told it is fast.  Guile's selling point IMO is
its libraries and its FFI.  Guile 2.2 certainly seems adequately fast
at run time.  Possibly compile times may be an issue, I don't know.

Chris



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Guile benchmark
  2017-02-28 12:55       ` Chris Vine
@ 2017-03-01  0:24         ` Arne Babenhauserheide
  0 siblings, 0 replies; 9+ messages in thread
From: Arne Babenhauserheide @ 2017-03-01  0:24 UTC (permalink / raw)
  To: Chris Vine; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]


Chris Vine <chris@cvine.freeserve.co.uk> writes:
> No, on my Haswell laptop running 64-bit linux, solving the 40,000th
> prime (479909) is 1.26 times faster in chez scheme than in guile-2.1.7,
> on the simple algorithm. (0.509 seconds versus 0.624 seconds, on a
> i7-4712HQ CPU @ 2.30GHz.)  This is only the time taken in the body of
> the calculation.  Start-up times and printing times and so forth are
> ignored.

Ah, ok. Thank you!

> I have just tried out the same code on an older Sandybridge desktop
> @3.30 GHz running 32-bit linux which I can access remotely, and that had
> chez scheme 1.7 times faster than guile-2.1.7 so it looks to be
> somewhat CPU and/or cache and/or pointer-width sensitive. Anyway, it is
> just one benchmark.
>
> I think I am about schemed out so installing Stalin is probably not an
> option.  Like you, I am told it is fast.  Guile's selling point IMO is
> its libraries and its FFI.  Guile 2.2 certainly seems adequately fast
> at run time.  Possibly compile times may be an issue, I don't know.

Factor 10 between C++ and pure Scheme is pretty awesome. Implementing
algorithms in pure Python carries a penalty of easily factor 100 (though
delegating anything expensive to builtin operators is fast).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-03-01  0:24 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-26  8:39 Guile benchmark Rchar
2017-01-26 21:56 ` Mike Gran
2017-01-26 22:11   ` Linas Vepstas
2017-01-30 14:16 ` Ludovic Courtès
2017-02-27 20:00 ` Andy Wingo
2017-02-27 23:35   ` Chris Vine
2017-02-28 10:28     ` Arne Babenhauserheide
2017-02-28 12:55       ` Chris Vine
2017-03-01  0:24         ` Arne Babenhauserheide

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).