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-users Digest, Vol 149, Issue 2
On Tue, Apr 7, 2015 at 7:00 AM, chicken-users-requ...@nongnu.org wrote: 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. This is even true when benchmarking code fragments written in different styles and run on the same implementation. The performance variation is so severe that I write my inner loops for numerics in C. For an n-dimensional array, the infamous innermost loop is 1-dimensional. The C code condenses down to a single for loop of maybe 10 lines in length. The speed problem has thus been easily converted into a Scheme-to-C interfacing problem. Using chicken, I find that interfacing Scheme and C is not really much of a problem at all. The rest of the program is then written in chicken scheme in an arbitrary style with no consideration of performance. The emphasis for the scheme code is readability/maintainability etc. Incidentally, this approach works perfectly on Android using the NDK and some custom make files. Even when editing the C code, I wrap it in chicken and dynamically load it over and over again as I refine the inner loop. No implementation is as fast as 10 lines of hand-optimized C. After using this technique, I feel that the debate over implementation performance seems rather silly, especially when discussing actual numerical algorithms. For recursion over arbitrary data structures, another optimization approach might be needed. In the old days, people would write inner loops in assembly. -Rafael ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken-users Digest, Vol 149, Issue 2
On Tue, Apr 07, 2015 at 09:33:49AM -0400, F. Rafael Leon wrote: Even when editing the C code, I wrap it in chicken and dynamically load it over and over again as I refine the inner loop. Hey, that sounds interesting! How do you do that? No implementation is as fast as 10 lines of hand-optimized C. C is good for performance, and it makes a lot of sense to write stuff in it when it needs to be really fast, but it shouldn't become a crutch like it is for PHP, Ruby and Python coders when faced with performance issues: If the Scheme code is slow when compiled, it makes sense to first investigate whether it's a bottleneck that can be solved in the compiler, or with a few hacks^Wwell-placed macros ;) 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?
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
[Chicken-users] Chicken Workflow for Editing C Code
On Tue, Apr 7, 2015 at 9:48 AM, Peter Bex pe...@more-magic.net wrote:
Even when editing the C code, I wrap it in chicken and dynamically
load it over and over again as I refine the inner loop.
Hey, that sounds interesting! How do you do that?
This is a whole different topic from the performance debate.
I do the following and It Works For Me:
I work from a chicken REPL. I run the chicken interpreter with the
linenoise egg:
http://wiki.call-cc.org/eggref/4/linenoise
An alternative is to use rlwrap, but the result is that I end up with
a csi prompt with readline support:
#;1
In theory, it would be even better to run csi in an emacs buffer, but
I never adapted to that habit.
From the prompt, I load a set of data into memory, and I put it in
srfi-4 vectors in the interpreter:
(define big-vector-a ... )
(define big-vector-b ... )
That is my starting state: a scheme prompt which represents a window
into a context holding some utility functions and lots of packed
binary data.
There are three more pieces to the puzzle:
Makefile - compiles and links things
innerloop.c - the file with the inner loop function with a for loop inside
example.scm - the wrapper for example.c
*** Makefile looks something like:
libexample.so: example.o
ld -shared -o example.so example.o $(LIBDIR) -lchicken
%.o: %.c
gcc -c -fPIC $^ $(INCDIR)
example.c: innerloop.c
chicken example.scm
*** innerloop.c looks like:
int innerfunc(unsigned char *dat){
for( ... ){
... }
}
*** and example.scm:
(declare (unit example))
(foreign-declare #include \innerloop.c\ )
(define innerwrap
(lambda (mybigvector)
((foreign-lambda
int
innerfunc u8vector)
mybigvector)))
*
and then from my prompt, I run:
#;1 (load-library 'example libexample.so)
#;2 (innerwrap big-vector-a)
Then, edit innerloop.c and type make again and then hit the up arrow
and the enter key:
#;3 (load-library 'example libexample.so)
#;4 (innerwrap big-vector-a)
I do this over and over again until the C code is fast.
-Rafael
___
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
