Benchmark results for dependency graph calculation by gsc (i586, x86-64, and x32)
Hello Gambit users. I would like to share some interesting benchmark results that compare i586, x86-64 and x32 ABI. The experiments were done with the released version 4.9.3 of Gambit, gcc 8.3.0, a Ryzen 7 1800X and a quite large Scheme code file as input to the -dg option of Gambit, which calculates a dependency graph like this: gsc -:l60 -c -dg largescheme.scm The binary gsc was built for all three architectures. The runtimes for the gsc call above are reported as averages over 5 runs. arch. runtime (s) size RSS (MB) x32 67.90 2200 x86-64 71.90 + 6 % 4360 +98 % i586 80.31 +18 % 2200 + 0 % I have reported similar numbers for other Scheme implementations and other benchmarked programs. For some of them, the runtime difference are more drastic (20 - 30 %) in favor of x32. For garbage-intensive programs, the results (like the ones listed above) can be summarized as follows: 1. x86-64 increases memory demands by a factor of 2. 2. i586 loses significantly in speed because it cannot used all features and registers of a 64bit CPU. 3. x32 can be faster than x86-64 for Scheme programs as described above, probably because GC has to look at only half of the memory (compared to x86-64). Ciao Sven
That’s interesting and it matches what I have experienced too. Manuel Serrano told me about x32 and I think that is what he suggests when compiling bigloo. It certainly gives favorable benchmark results! Would you mind sharing the configure options you have used to build Gambit for x32? Of course one important drawback is that you are limited to 32 bit references and headers, so only 4G RAM can be accessed (at best) and objects are limited to 16M bytes in size (so forget about reading large files into a string or computing pi to 100 million digits!). Marc
On Sep 9, 2019, at 10:25 AM, Sven Hartrumpf <hartrumpf@gmx.net> wrote:
Hello Gambit users.
I would like to share some interesting benchmark results that compare i586, x86-64 and x32 ABI. The experiments were done with the released version 4.9.3 of Gambit, gcc 8.3.0, a Ryzen 7 1800X and a quite large Scheme code file as input to the -dg option of Gambit, which calculates a dependency graph like this:
gsc -:l60 -c -dg largescheme.scm
The binary gsc was built for all three architectures. The runtimes for the gsc call above are reported as averages over 5 runs.
arch. runtime (s) size RSS (MB) x32 67.90 2200 x86-64 71.90 + 6 % 4360 +98 % i586 80.31 +18 % 2200 + 0 %
I have reported similar numbers for other Scheme implementations and other benchmarked programs. For some of them, the runtime difference are more drastic (20 - 30 %) in favor of x32.
For garbage-intensive programs, the results (like the ones listed above) can be summarized as follows:
1. x86-64 increases memory demands by a factor of 2.
2. i586 loses significantly in speed because it cannot used all features and registers of a 64bit CPU.
3. x32 can be faster than x86-64 for Scheme programs as described above, probably because GC has to look at only half of the memory (compared to x86-64).
Ciao Sven
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
Hi Marc. Marc wrote, 2019-09-09 10:42:
That’s interesting and it matches what I have experienced too. Manuel Serrano told me about x32 and I think that is what he suggests when compiling bigloo. It certainly gives favorable benchmark results!
Would you mind sharing the configure options you have used to build Gambit for x32?
A simple way to build Gambit for x32 is adding -mx32 -Wa,-x32 to your C flags, e.g. ./configure CFLAGS="-mx32 -Wa,-x32 ..." --prefix=/usr/local/gambit-x32 --enable-gcc-opts --enable-multiple-versions --enable-single-host You will need a Linux distribution that supports the x32 ABI.
Of course one important drawback is that you are limited to 32 bit references and headers, so only 4G RAM can be accessed (at best) and objects are limited to 16M bytes in size (so forget about reading large files into a string or computing pi to 100 million digits!).
Thanks. I forgot to mention these limitations. Sven
On Mon, Sep 9, 2019 at 10:55 AM Sven Hartrumpf <hartrumpf@gmx.net> wrote:
Of course one important drawback is that you are limited to 32 bit
references and headers, so only 4G RAM can be accessed (at best) and objects are limited to 16M bytes in size (so forget about reading large files into a string or computing pi to 100 million digits!).
Thanks. I forgot to mention these limitations.
In addition: x32 exists only on Linux AFAIK and Linus wants to deprecate it. No known commercial Linux distro supports it. The issue of deprecation was raised last December, and I imagine it will continue to be raised. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org In my last lifetime, I believed in reincarnation; in this lifetime, I don't. --Thiagi
John wrote, 2019-09-09 13:15:
On Mon, Sep 9, 2019 at 10:55 AM Sven Hartrumpf <hartrumpf@gmx.net> wrote:
Of course one important drawback is that you are limited to 32 bit references and headers, so only 4G RAM can be accessed (at best) and objects are limited to 16M bytes in size (so forget about reading large files into a string or computing pi to 100 million digits!).
Thanks. I forgot to mention these limitations.
In addition: x32 exists only on Linux AFAIK and Linus wants to deprecate it.
The proposal came from Andy Lutomirski, and Linus has a justifiable interest to remove parts from Linux if possible. But they were (are) open to hear arguments for x32; Linus wrote: "I'm not opposed to trying to sunset the support, but let's see who complains." see https://lkml.org/lkml/2018/12/10/1151
No known commercial Linux distro supports it.
Does Ubuntu count as non-commercial? :-)
The issue of deprecation was raised last December, and I imagine it will continue to be raised.
They were asking for arguments for x32, and the feedback was not loud enough, I fear. Many programming language people could have provided arguments, but not many knew about this discussion. Scheme implementations typically have significant benefits from x32. So, my wish would be not to be pessimistic, but to exploit x32 advantages more aggressively in the world of Scheme and other languages, so that the next round of the deprecation discussion will have more argumemts for x32 ... I think that x32 is an opportunity for Scheme (and others). Ciao Sven
On Tue, Sep 10, 2019 at 4:12 AM Sven Hartrumpf <hartrumpf@gmx.net> wrote:
The proposal came from Andy Lutomirski, and Linus has a justifiable interest to remove parts from Linux if possible. But they were (are) open to hear arguments for x32; Linus wrote:
"I'm not opposed to trying to sunset the support, but let's see who complains." see https://lkml.org/lkml/2018/12/10/1151
You obviously know more about it than I do, but I've now read the thread and the linked thread from the beginning of x32. Looks like Linus was never really happy with it. Does Ubuntu count as non-commercial? :-)
Pretty much. You can only get a support contract if you have at least 50 seats, says Dr. Google. That means that individuals and startups (unless they put everyone in the office on Linux) have to treat it as non-commercial. Lots of them use it anyway, of course. (I'm distinguishing here between providing x32 and supporting it.) Red Hat OTOH will take anybody's money.
So, my wish would be not to be pessimistic, but to exploit x32 advantages more aggressively in the world of Scheme and other languages, so that the next round of the deprecation discussion will have more argumemts for x32 ... I think that x32 is an opportunity for Scheme (and others).
We need to think carefully about whether we care more about speed or space (the latter effect is larger in Lisp than in most languages). We also need to think about classes of implementations. For this purpose I think there are three: Native compilers, which need to have their code modified to support x32. These are Chez, MIT, and Vicare. (Larceny is out of the picture here because its compiler can't generate x86_64 instructions at all.) Compilers to C. These are Bigloo, Chicken, Cyclone, Gambit, Hotdog (port of Scheme48), Larceny, MIT, Owl Lisp, Rhizome/pi, RScheme, Scheme->C, SCM, Stalin. This depends on the degree of x32 support not so much in the C compiler as in the C library. glibc has full support, musl has issues, newlib, ulibc, etc. I don't know about. (Cygwin, which I use a lot, has newlib, but of course the Windows kernel doesn't do x32 anyway.) Bytecode compilers with JIT. These are Racket and Guile 3.x. Everything else. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org "Any legal document draws most of its meaning from context. A telegram that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in 5-bit Baudot code plus appropriate headers) is as good a legal document as any, even sans digital signature." --me
On Tue, Sep 10, 2019 at 10:12:30AM +0200, Sven Hartrumpf wrote:
John wrote, 2019-09-09 13:15:
On Mon, Sep 9, 2019 at 10:55 AM Sven Hartrumpf <hartrumpf@gmx.net> wrote:
Of course one important drawback is that you are limited to 32 bit references and headers, so only 4G RAM can be accessed (at best) and objects are limited to 16M bytes in size (so forget about reading large files into a string or computing pi to 100 million digits!).
Thanks. I forgot to mention these limitations.
In addition: x32 exists only on Linux AFAIK and Linus wants to deprecate it.
The proposal came from Andy Lutomirski, and Linus has a justifiable interest to remove parts from Linux if possible. But they were (are) open to hear arguments for x32; Linus wrote:
"I'm not opposed to trying to sunset the support, but let's see who complains." see https://lkml.org/lkml/2018/12/10/1151
Just what *is* x32? -- hendrik
Hendrik Boom wrote, 2019-09-10 11:08:
Just what *is* x32?
It is an ABI like i386 and x86-64, see https://en.wikipedia.org/wiki/X32_ABI
participants (5)
-
Hendrik Boom -
John Cowan -
Lassi Kortela -
Marc Feeley -
Sven Hartrumpf