Hi,
On Tue, 7 Apr 2015 11:32:39 +0200 Peter Bex pe...@more-magic.net wrote:
If anyone wants to add it to the chicken-benchmark repo, I would
recommend removing the writing of the output file, as that's really
not where the bottleneck is, and writing a file isn't very nice in a
benchmark
This is a terribly written program. It uses 3-element lists as vectors
(including higher-order vector arithmetic using map) and allocates
like hell. The compiler can not do much with this code, and it
produces CPS calls everywhere.
I take it you are referring to the {add, sub, scale, mul,
On 08/04/15 09:26, arc wrote:
I
did interact with (or at least see some interaction with) people like
Marc Feely, Anton van Straaten, Felix (pretty sure?), Alaric, et. al.
They all seemed like thoroughly nice people, and it's hard to believe
the intervening years have turned them all
Hi,
The difference is, this one is much better code, which doesn't exercise
the garbage collector, so it isn't much use as a GC benchmark.
Code involving SSQL would be good for a GC benchmark. I recently
reworked the query generation in Knodium to be up-front rather than at
access-time and got
On Wed, Apr 08, 2015 at 08:26:43PM +1200, arc wrote:
I would also caution against generalising from Usenet to some wider
community. I haven't visited comp.lang.scheme in years, but I am on
my second go at trying to make sense of Forth, so I've been lurking
in comp.lang.forth, and it's also
On 07/04/15 22:59, Christian Kellermann wrote:
* Felix Winkelmann felix.winkelm...@bevuta.com [150407 10:41]:
That is (among a few other reasons) why I don't do much Scheme or Lisp
programming anymore - thinking about the community, reading all this
bullshit makes me sick.
On 08/04/15 00:18, John Cowan wrote:
Felix Winkelmann scripsit:
That there are so many implementors in the Lisp and Scheme community
probably makes this irrational emphasis on (execution-time)
performance so apparent in these groups. Or it's the remains of the
trauma of the AI-Winter, I don't
This is a terribly written program. It uses 3-element lists as vectors
(including higher-order vector arithmetic using map) and allocates
like hell. The compiler can not do much with this code, and it
produces CPS calls everywhere.
It's still rather interesting that Racket and even Gauche
From: Dan Leslie d...@ironoxide.ca
Subject: [Chicken-hackers] Any thoughts on performance woes?
Date: Mon, 06 Apr 2015 22:28:49 -0700
A discussion has been raised on comp.lang.scheme regarding a simple
raytracer and the performance it poses in various schemes. In this,
Gauche an Racket
On Tue, Apr 07, 2015 at 09:43:55AM +0200, Felix Winkelmann wrote:
A discussion has been raised on comp.lang.scheme regarding a simple
raytracer and the performance it poses in various schemes. In this,
Gauche an Racket outperform Chicken, and Racket does so
resoundingly. To be frank, it
On Tue, Apr 07, 2015 at 10:41:32AM +0200, Felix Winkelmann wrote:
Indeed, I was not trying to make it look otherwise. Apparently Flatt
and Kawei did an excellent job in optimizing their implementations, no
doubt about that.
Or maybe there's some small mistake in our implementation that causes
On Tue, Apr 07, 2015 at 11:32:39AM +0200, Peter Bex wrote:
On Tue, Apr 07, 2015 at 10:41:32AM +0200, Felix Winkelmann wrote:
Indeed, I was not trying to make it look otherwise. Apparently Flatt
and Kawei did an excellent job in optimizing their implementations, no
doubt about that.
I tried
* Felix Winkelmann felix.winkelm...@bevuta.com [150407 09:44]:
This is a terribly written program. It uses 3-element lists as vectors
(including higher-order vector arithmetic using map) and allocates
like hell. The compiler can not do much with this code, and it
produces CPS calls everywhere.
* Felix Winkelmann felix.winkelm...@bevuta.com [150407 10:41]:
But I'm sick and tired of people throwing badly written code into the
net and making gross assumptions about implementation performance. The
possible options, the search-space available is massive and a little
difference in
I just had this crazy idea of new tooling that would help the curious
programmer to find the line of code that triggers a lot of allocation,
or find the line of code that causes a lot of GCs.
One could extend the profiling machinery to also trace and count
allocations (the compiler already
Felix Winkelmann scripsit:
That there are so many implementors in the Lisp and Scheme community
probably makes this irrational emphasis on (execution-time)
performance so apparent in these groups. Or it's the remains of the
trauma of the AI-Winter, I don't know (and I don't care anymore.)
I
On Tue, Apr 07, 2015 at 12:35:38PM +, Mario Domenech Goulart wrote:
Hi,
On Tue, 7 Apr 2015 11:32:39 +0200 Peter Bex pe...@more-magic.net wrote:
If anyone wants to add it to the chicken-benchmark repo, I would
recommend removing the writing of the output file, as that's really
not
On Tue, 7 Apr 2015 14:43:42 +0200 Peter Bex pe...@more-magic.net wrote:
On Tue, Apr 07, 2015 at 12:35:38PM +, Mario Domenech Goulart wrote:
On Tue, 7 Apr 2015 11:32:39 +0200 Peter Bex pe...@more-magic.net wrote:
If anyone wants to add it to the chicken-benchmark repo, I would
Hi Dan,
On Tue, 07 Apr 2015 09:34:12 -0700 Dan Leslie d...@ironoxide.ca wrote:
Perhaps it's because of the industries in which I've worked (gaming,
embedded systems and enterprise SaaS), but I've not really experienced
development where performance wasn't a top or near-top priority. Part of
Peter Bex pe...@more-magic.net writes:
I have a solution in the works for the particular problem of slow
numbers. This is in a CHICKEN 5 branch I've been working on, which
I will announce in a week or so.
Colour me excited. :)
-Dan
--
-Dan Leslie
Felix Winkelmann felix.winkelm...@bevuta.com writes:
I'm a compiler-writer, my job is to be paranoid about performance.
But otherwise raw speed is in most cases secondary (try to run large
real-world programs on Larceny or Stalin and you know what I mean.)
That there are so many implementors
21 matches
Mail list logo