Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 suite. Also, the (use extras) can be removed. Finally, the displaying could be killed as well. Thanks, Peter. I've finally added it to the chicken-benchmarks repo. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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, dot,
squared-length, normal} functions? It seems clear to me that there's
plenty of room for optimization in them, but I wonder if you're being a
bit hasty to dismiss the naive implementation so readily. IMHO, use of
`map` to transform lists is sort of idiomatically lisp.
Using map to transform lists is indeed, but using lists to store
fixed-size collections that are expected to be heavily used is
probably not, I'd say. On the other hand, this benchmark appears to be
intentionally inefficient to stress the GC by allocating a lot.
That is to say, in this case there are alternatives for numerical
computation, but transforming a list in a similar manner ought to be
commonplace in lispy programmes. If it is this sort of behaviour that
drives the GC into agony then I expect that there are many Chicken
programmes that may benefit from any form of optimization that could be
had from `map`.
That's right, of course. Nobody would complain if we tried to catch
this special case. But every additional optimization complicates the
optimizer (which is already pretty hairy) and increases the
possibility of bugs. Still, (map op ...) must allocate, unless one
can infer some lifetime information about the argument (or result)
lists.
CHICKEN may pay an extra penalty by producing relatively bad code
for certain loops, like those introduced by an already existing optimization
of map. So, for example:
(define (foo x y)
(map + x y))
(foo (read) (read))
gets translated and optimized to:
csc -debug 7 x.scm -O5
[optimized]
(lambda (k205)
(let ((k207 (##core#lambda
(t33)
(let ((k209 (##core#lambda
(t34)
(let ((k260 (##core#lambda
(t36)
(let ((k262 (##core#lambda (t37)
(k205 (##core#undefined)
(let ((k264 (##core#lambda (r265)
(r265 k262
(##sys#implicit-exit-handler
k264))
(let ((k268 (##core#lambda
(a267)
(let ((k271 (##core#lambda
(a270)
(let ((x1 a267))
(let ((g919 '()))
(let ((g1020
#f))
(let
((map-loop524 (##core#undefined)))
(let ((t218
(set! map-loop524
(lambda (k220 g1725 g1826)
(let ((r255 (##core#inline C_i_pairp g1725)))
(let ((r225 (##core#cond
r255
(##core#inline C_i_pairp g1826)
#f)))
(if r225
(let ((a248 (##core#inline C_slot g1725 0)))
(let ((a251 (##core#inline C_slot g1826 0)))
(let ((a245 (##core#inline_allocate
(C_a_i_plus 4)
a248
a251)))
(let ((g628 (##core#inline_allocate
(C_a_i_cons 3)
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 nasty... Dunno about the others but I, for one, have taken to murdering cute puppies for fun and profit. -arc. ;-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 an ordes of magnitude speed up and an order of magnitude fewer GCs. Here's a snippet from my commit message: - (account 'read 1:3) query generation (each call returns 1 account object) (time (for-each (lambda x (account 'read 1:3)) (iota 6500))) Original: 5.296s CPU time, 0.492s GC time (major), 3334265 mutations, 86/28886 GCs (major/minor) 5.357s CPU time, 0.48s GC time (major), 3334265 mutations, 84/2 GCs (major/minor) 5.332s CPU time, 0.508s GC time (major), 3334265 mutations, 89/28883 GCs (major/minor) 5.284s CPU time, 0.46s GC time (major), 3334265 mutations, 83/28889 GCs (major/minor) 5.397s CPU time, 0.501s GC time (major), 3334283 mutations, 83/28889 GCs (major/minor) With pre-generated query in read-account: 0.304s CPU time, 0.004s GC time (major), 220077 mutations, 1/656 GCs (major/minor) 0.296s CPU time, 220077 mutations, 0/657 GCs (major/minor) 0.304s CPU time, 220077 mutations, 0/657 GCs (major/minor) 0.296s CPU time, 220077 mutations, 0/657 GCs (major/minor) 0.3s CPU time, 220077 mutations, 0/657 GCs (major/minor) - Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0290 DA75 E982 7D99 A51F E46A 387A 7695 7EBA 75FF signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 kind of problematic, due largely to a small handful of problematic personalities (one at least is engaging in the same behaviour as he did in c.l.s years ago: anyone remember gavino?). If those people disappeared, it would suddenly become a largely pleasant place. Unfortunately open access, low barriers to entry, and no moderation it's simply too easy for difficult people to ruin life for everyone, (including of course brining out the worse in people who would otherwise be better), forever. [people in #scheme] all seemed like thoroughly nice people, and it's hard to believe the intervening years have turned them all nasty... Gavino, that blight of humanity, has been appearing on c.l.s, even once on this mailing list, and keeps popping up on IRC under different nicknames. I actively monitor #chicken to keep him out, but when I left #scheme a few years ago, that was mostly due to the fact that there are no active moderators, or at least Gavino is not kept out. This spoils the atmosphere enough for me that I don't go in there at all anymore. I also remember various other trolls mostly being allowed free reign in #scheme. Only when it got completely out of hand, sometimes Riastradh would step in to kick them, but he wasn't very active back then anymore, either. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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. comp.lang.lisp/scheme is in ruins for most things. But I would not say that the 6-7 (regular) abusive posters there define the community. Driven by countless snobbish books and articles the (passive/)agressive tone towards others seems to be *part* of the culture. But I think this is somewhat changeing albeit slowly. This fine community and its open attitude is one example but I have found guile people and others equally attitude free (with exceptions on all sides of course, but most of the active projects strive for a friendly atmosphere). After all who wants to spend their free time around abusive assholes? 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 kind of problematic, due largely to a small handful of problematic personalities (one at least is engaging in the same behaviour as he did in c.l.s years ago: anyone remember gavino?). If those people disappeared, it would suddenly become a largely pleasant place. Unfortunately open access, low barriers to entry, and no moderation it's simply too easy for difficult people to ruin life for everyone, (including of course brining out the worse in people who would otherwise be better), forever. My impression of the online Scheme community some years ago (largely in the form of #scheme on freenode) was extremely positive: people were helpful and good-natured and fun almost always. The regulars were, to my knowledge and recollection, not for the most part especially influential schemers (although John and Alex had some presence), but 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 nasty... (and the Chicken list is also quite fine) -arc. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 know (and I don't care anymore.) I believe it's older than that. There was a steady drumbeat of Lisp is too slow to be usable practically from the 1950s onward, and you can still find it in certain ignorant quarters. As a result, the Lisp/Scheme community acts like the traumatized victim of a bully. There are certain other language communities that do the same things or the same reasons. Speaking of #scheme some years ago: as soon as I saw Felix's complaint about the obsession on performance, I recalled you expressing this exact point, posed in the form of a riddle as to what made one group of languages different from the other :-) (which was a bit tricksy, come to think of it... one doesn't normally think of a property of the community being a property of the language...) These days, though, aren't the complaints more along the lines of 'it's old', 'I hate parentheses' (read: 'I refuse to learn anything without a C-like syntax') and 'what's the point? it has no commercial value.'? -arc. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 don't seem to have a problem with this program. 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. 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 vast difference in performance. Somehow there seems to be a large number of trolls that use some ridiculuous piece of code, run it with a handful of implementations (of course using suboptimal optimization options, since they really don't know what they're doing) and then generalize their results without the slightest bit of sense. 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 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.) 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. felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 outperform Chicken, and Racket does so resoundingly. To be frank, it looks rather troubling for Chicken. I had a go at looking at what Chicken was spending its time on and it appeared that it becomes mired in a tar pit of garbage collection tagging. Can someone else with a little more understanding shed some light on this? https://groups.google.com/d/msg/comp.lang.scheme/x1YafU5t0B0/M0mzhrl7LxYJ 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. Interesting that Gauche is so fast, it may be that its GC is in this case indeed faster than Chicken's, or that a case like (map + ...) is special-cased and handled more efficiently. felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 looks rather troubling for Chicken. I had a go at looking at what Chicken was spending its time on and it appeared that it becomes mired in a tar pit of garbage collection tagging. Can someone else with a little more understanding shed some light on this? https://groups.google.com/d/msg/comp.lang.scheme/x1YafU5t0B0/M0mzhrl7LxYJ 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 don't seem to have a problem with this program. However, I think the program's author has an attitude problem. Also, the FUD this Larceny benchmark is spreading is getting on my nerves: The Larceny benchmarks use the r7rs egg, which implies the use of the numbers egg for all arithmetic, which means a complete slowdown in anything related to numerics. If you were to strip out the r7rs stuff it will be a lot faster because it can use inlining for all numeric operations. 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. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 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 ;) Anyway, if anyone wants to have a crack at it, I've removed the eggs from the benchmark so that it's a bit easier to run and analyze. Find it attached. 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 (use extras) can be removed. Finally, the displaying could be killed as well. 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 vast difference in performance. 100% true. However, this seems like a somewhat pathological case of the functional programming approach. As such, it's a good benchmark for this type of programming, even if it happens to be a shitty way to write a raytracer ;) 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.) Could you elaborate on that? Does Larceny's compilation time degrade on large programs like Stalin does, so you would have to wait for weeks for your program to compile, or are you referring to the lack of community/infrastructure? 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.) 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. That's very sad, because Scheme is such a nice language. Besides, CHICKEN has a nice community so who cares about the trolls? Anyway, I'm happy we got a useful new benchmark out of this, and something to aim for in improving our fantastic compiler. Cheers, Peter ;; Ray tracer for Chicken Scheme. ;; Creates graphic file junk-trash.ppm. ;; Converted from the original in C at ;; https://wiki.cs.auckland.ac.nz/enggen131/index.php/User:Dols008 ;; ;; This program conses a lot, triggering a huge number of ;; garbage collections, thus it serves as a good GC benchmark. ;; ;; Compile with ;; csc -optimize-level 3 ray-trace.scm (use extras) (define-constant Width 400) (define-constant Height Width) (print Width x Height ) (define Start-Time (current-seconds)) (define (square x) (* x x)) (define (add list1 list2) (map + list1 list2)) (define (sub list1 list2) (map - list1 list2)) (define (scale seq n) (map (cut * n) seq)) (define (mul list1 list2) (map * list1 list2)) (define (dot list1 list2) (apply + (mul list1 list2))) (define (squared-length alist) (dot alist alist)) (define (normal alist) (let ((len (sqrt (squared-length alist (map (cut / len) alist))) (define-record Ray pos dir) (define-record Light pos color) (define-record Sphere pos radius color shine reflect) (define (ray-hit-sphere sphere ray) (let* ((diff (sub (Sphere-pos sphere) (Ray-pos ray))) (proj (dot diff (Ray-dir ray))) (closest (add (Ray-pos ray) (scale (Ray-dir ray) proj))) (tangent (sub closest (Sphere-pos sphere))) (sq-tangent-length (squared-length tangent)) (sq-radius (square (Sphere-radius sphere (if ( sq-tangent-length sq-radius) 0 (- proj (sqrt (- sq-radius sq-tangent-length)) (define (calc-lighting pos norm ray sphere light) (let* ((rel (normal (sub (Light-pos light) pos))) (diffuse (max (dot rel norm) 0)) (diff-col (scale (Light-color light) diffuse)) (eye (sub (Ray-pos ray) pos)) (half (normal (add eye rel))) (specular (dot half norm)) (specular (expt (max specular 0) 64)) (spec-col (scale (Light-color light) specular))) (add (mul (Sphere-color sphere) diff-col) (scale spec-col (Sphere-shine sphere) (define NUM_SPHERES 7) (define NUM_LIGHTS 3) (define spheres (make-vector NUM_SPHERES )) (define lights (make-vector NUM_LIGHTS )) (define (build-scene) (do ((i 0 (add1 i))) ((= i 5)) (let* ((theta (* 0.4 (- i 2))) (pos (list (* 3 (sin theta)) (* -3 (cos
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 running it on Gauche and it doesn't seem to be faster on my 64-bit box at work, so it looks like this person is full of it (or maybe used a newer version, I am on Debian after all...). I still haven't managed to port it to Racket. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
* 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. After reading the posts in this thread I wondered how I would have done it. And to be honest, while my code may not be as bad as this *cough* one thing that always puzzles me is a way to tell *why* a given program is slow. 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. How about collecting ideas like this and find a way to test these against real code at the next meetup? While this might not fend of trolls, this would help the more dedicated people improve their code for CHICKEN. Just some thoughts of cause, no real code to show (yet?)... All the best, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
* 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 programming style can make a vast difference in performance. Somehow there seems to be a large number of trolls that use some ridiculuous piece of code, run it with a handful of implementations (of course using suboptimal optimization options, since they really don't know what they're doing) and then generalize their results without the slightest bit of sense. 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 shows them all in your face at once if you ask for it. For my personal reading habit I will quickly decide not to read an article/post if it contains benchmark or performance on a topic I am truly interested in. Unless I still do of course :) 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 things. But I would not say that the 6-7 (regular) abusive posters there define the community. Driven by countless snobbish books and articles the (passive/)agressive tone towards others seems to be *part* of the culture. But I think this is somewhat changeing albeit slowly. This fine community and its open attitude is one example but I have found guile people and others equally attitude free (with exceptions on all sides of course, but most of the active projects strive for a friendly atmosphere). After all who wants to spend their free time around abusive assholes? So don't despair as a compiler once said, it's a nice day outside and there's always enough bad code left to be laughed at (or deleted) tomorrow. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 keeps track of the amount of memory allocated inline in each CPS procedure, this would have to also take non-inline allocation into account). The problem is that CPS heavily transforms the source code, but it would be a start. felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 believe it's older than that. There was a steady drumbeat of Lisp is too slow to be usable practically from the 1950s onward, and you can still find it in certain ignorant quarters. As a result, the Lisp/Scheme community acts like the traumatized victim of a bully. There are certain other language communities that do the same things or the same reasons. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux, de rapport nyait pas. --Jacques Lacan, L'Etourdit ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 where the bottleneck is, and writing a file isn't very nice in a benchmark suite. Also, the (use extras) can be removed. Finally, the displaying could be killed as well. Some days ago I ported a ray tracer from the Larceny suite to chicken-benchmarks: https://github.com/mario-goulart/chicken-benchmarks/blob/master/progs/ray.scm 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. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 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 (use extras) can be removed. Finally, the displaying could be killed as well. Some days ago I ported a ray tracer from the Larceny suite to chicken-benchmarks: https://github.com/mario-goulart/chicken-benchmarks/blob/master/progs/ray.scm 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. I also ported gcbench: https://github.com/mario-goulart/chicken-benchmarks/blob/master/progs/gcbench.scm Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 why I raised this question to the list was to satisfy my curiousity, as writing performant Chicken code is still somewhat of a hazy endeavour to me. Felix wrote a nice tutorial about programming for performance in CHICKEN: http://wiki.call-cc.org/programming-for-performance Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
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 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 agree, Larceny isn't exactly a viable option for development, for reasons which are evident when one attempts to begin using it. There's just a whole lot missing from the package, the community, the documentation et al which other Schemes like Chicken provide. 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 this question to the list was to satisfy my curiousity, as writing performant Chicken code is still somewhat of a hazy endeavour to me. It saddens me that you aren't writing so much Scheme/Lisp any more. I wish that this wasn't the case; you've done such great work. -Dan -- -Dan Leslie ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
