Hi,
On Tue, 7 Apr 2015 11:32:39 +0200 Peter Bex 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 suite. Also, the "(u
>> 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,
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 go
On 08/04/15 22:27, Peter Bex wrote:
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
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 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 n
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 k
On 07/04/15 22:59, Christian Kellermann wrote:
* Felix Winkelmann [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.
comp.lang.lisp/scheme is in ruins for most th
Hi Dan,
On Tue, 07 Apr 2015 09:34:12 -0700 Dan Leslie 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
> why I raised t
Felix Winkelmann 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 in the Lisp and Scheme
Peter Bex 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
___
Chicken-use
Felix Winkelmann writes:
> 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
On Tue, 7 Apr 2015 14:43:42 +0200 Peter Bex 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 wrote:
>>
>> > If anyone wants to add it to the chicken-benchmark repo, I would
>> > recommend removing the writing of
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 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 bo
Hi,
On Tue, 7 Apr 2015 11:32:39 +0200 Peter Bex 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 suite. Also, the "(u
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.)
> Nowadays anyone who knows how to use a stop watch (or the modern
> equivalent time(1)) on some code (sometimes the first they write in a
> new language) tends to publish the results as a generalized benchmark.
> People have argued like this for ages, it's the all preserving google
> cache that sh
> 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 k
> Or maybe there's some small mistake in our implementation that causes
> it to retain too much data. I'm not sure of course, just theorizing,
> because even though it generates a lot of garbage, my gut says it
> shouldn't need this many major collections. But my gut has been wrong
> often enough
* Felix Winkelmann [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.
After reading the
* Felix Winkelmann [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 programming style can make a va
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
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 cause
>> 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
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
From: Dan Leslie
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 outperform Chicken, an
26 matches
Mail list logo
