Re: [Chicken-users] two minor tweaks to runtime.c
On Sep 29 2011, Alan Post wrote: On Thu, Sep 29, 2011 at 12:09:19PM +0900, Alex Shinn wrote: On Thu, Sep 29, 2011 at 11:40 AM, Alan Post alanp...@sunflowerriver.org wrote: Will you show me this data for the current implementation? The first implementation doesn't need to justify itself, just be working. *nods* True. However I consider standard engineering practice, which does remove *complexity* from code and moreover offers the compiler much better chances to schedule independent code (where we had a conditional dependency before) worth a try without overkill. And frankly: I'm trying to get an application working. Improving chicken just happens along the way. In fact I feel kind of sorry that there is such a thread arose from a simple change. I don't not have benchmarks for a reason: they would cost me too much time to do right. Personally I don't believe too much in benchmarks anyway. I believe in fast execution and source code review. How should the community ever be able to improve over the current state of affairs, if each suggestion is upfront required to come with a benchmark, which is than probably first taken apart to show how flawed it is? Given how small the difference to the code is: wouldn't it be reasonable to just give it a try? I for one forgot to measure the time of first recompilation of chicken with those changes already in the compiler. But I was surprised. Or let me take the threading problem I solved ages ago. I did NOT want to get into that business. All I wanted was to have my prog run on chicken as it did on rscheme. Benchmarks said chicken is faster at that time. What a lie a benchmark can be! It was crawling slow. Tracked that down to the timeout queue. Fixed the complexity issue. Problem solved. Hm. So how would I device a benchmark case for that one? And why? It's obviously faster. Not with one or two threads. But those don't suffer either. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote: I don't not have benchmarks for a reason: they would cost me too much time to do right. Personally I don't believe too much in benchmarks anyway. I believe in fast execution and source code review. Ah, but how can you measure fast execution without a benchmark? How should the community ever be able to improve over the current state of affairs, if each suggestion is upfront required to come with a benchmark, which is than probably first taken apart to show how flawed it is? If the benchmark is flawed, it should be fixed. I am getting the impression you have encountered some terrible benchmarks! Given how small the difference to the code is: wouldn't it be reasonable to just give it a try? Yes. But trying out some code involves reviewing it, then testing it - both for correctness and, in this case, for a performance improvement; and (the evil case...) for not worsening performance elsewhere. Which needs a test suite and some benchmarks! Or let me take the threading problem I solved ages ago. I did NOT want to get into that business. All I wanted was to have my prog run on chicken as it did on rscheme. Benchmarks said chicken is faster at that time. What a lie a benchmark can be! It was crawling slow. Tracked that down to the timeout queue. Fixed the complexity issue. Problem solved. Hm. So how would I device a benchmark case for that one? If the supposed performance improvement can't be benchmarked, then it's pointless, as nobody will actually benefit from it. Any case where somebody can benefit from a performance improvement can be turned into a benchmark that consists of running the code that is sped up, and timing it. Benchmarks are like unit tests; they are snippets of code that perform some operation but, rather than testing correct responses, their emphasis is on testing resource usage. We could work on a system by iteratively hacking it then measuring performance by hand, but in doing so, we will only measure the kinds of performance we personally care about, and may well do things that reduce performance in other areas of the system. Decent benchmarks can be put into the test suite, so future performance tinkerers can see the consequences of their changes for previous uses. And just like unit tests, performance benchmarks should be chosen carefully for what they test. Unit tests are often easier to write, as they have clearly-defined (sometimes in specifications, sometimes in common sense) goals. Performance benchmarks are trickier. A system that aggressively caches everything read might perform very well on read latency and throughput, but terribly on memory consumption and latency of noticing changes to source data. So the best benchmarks are derived directly from applications, and include representative mixes of operations to test overall performance as well as low-level per-operation benchmarks! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EXlAACgkQRgz/WHNxCGq02ACcDTZBt8R4f3PU8Zu7vl63TjIP ShAAnjUl0K8Z3uCwpJMuVSb9bZ5uilcZ =mZsg -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Sep 29 2011, Alaric Snell-Pym wrote: On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote: I don't not have benchmarks for a reason: they would cost me too much time to do right. Personally I don't believe too much in benchmarks anyway. I believe in fast execution and source code review. Ah, but how can you measure fast execution without a benchmark? Well, at the end of the day I run some complex applications. For instance I use httperf. I don't touch chicken, if I did not find a reason to do so. It complicates my work. Or let me take the threading problem I solved ages ago. I did NOT want to get into that business. All I wanted was to have my prog run on chicken as it did on rscheme. Benchmarks said chicken is faster at that time. What a lie a benchmark can be! It was crawling slow. Tracked that down to the timeout queue. Fixed the complexity issue. Problem solved. Hm. So how would I device a benchmark case for that one? If the supposed performance improvement can't be benchmarked, then it's pointless, Hey, I wrote crawling slow! That's worse than just a benchmark. If the same program needs seconds instead of a fraction, then I don't bother. I tracked the problem down, fixed a single thing and found a huge speed up. As expected. Case was closed for me: goal reached. At that time there was no point in perfomance measurements. Later I wrote that httperf run into my Makefile. At that time I recall for a fairly complex page 8-12 replies per second. Same page now around 24 per second. No single reason for that. Just accumulated, incremental steps. the system. Decent benchmarks can be put into the test suite, so future Sure. But since I'm working on a different front, I just don't have the capacity to invest into advertising here. If something works better for me than the current state of affairs, then I notify the list. Code review is due upon integration anyway. And those who do have benchmarks already are welcome to post their results. Reviews are welcome to challenge the code. derived directly from applications, and include representative mixes of operations to test overall performance as well as low-level per-operation benchmarks! OK, see above. My benchmark (httperf) fits perfectly. Except it is flawed: the code has evolved in that time too. (In fact it has grown: sqlite/pthread interaction was not included in the beginning.) So we are back at the capacity issue again: I have only so much live time. I'm not ready to spent it maintaining benchmarks in the hope that those will eventually convince someone to benefit from the work I did. You are free to convince yourself. Best Regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 01:44 PM, Jörg F. Wittenberger wrote: On Sep 29 2011, Alaric Snell-Pym wrote: On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote: I don't not have benchmarks for a reason: they would cost me too much time to do right. Personally I don't believe too much in benchmarks anyway. I believe in fast execution and source code review. Ah, but how can you measure fast execution without a benchmark? Well, at the end of the day I run some complex applications. For instance I use httperf. Then that, my good man, is your benchmark :-) Yes, it's complex to run a chicken-based app and then run httperf against that to get real-world performance figures. Ideally you'd be able to distill the essence of that a little into a simpler test that nonetheless had almost the same performance characteristics. And maybe make mistakes in the process - but that's the art of performance estimation. If the supposed performance improvement can't be benchmarked, then it's pointless, Hey, I wrote crawling slow! That's worse than just a benchmark. If the same program needs seconds instead of a fraction, then I don't bother. I tracked the problem down, fixed a single thing and found a huge speed up. As expected. Case was closed for me: goal reached. If you had some operation you could measure before and after to see that speed up, then that's a benchmark too! At that time there was no point in perfomance measurements. If you found a huge speed up, you were measuring performance, by definition :-) If something works better for me than the current state of affairs, then I notify the list. Code review is due upon integration anyway. And those who do have benchmarks already are welcome to post their results. Reviews are welcome to challenge the code. For sure. I, for one, think it's great that you're contributing performance patches. But they do need to be checked with actual benchmarks. It looks like you *have* been doing that, but claiming you haven't, due to a disagreement about the definition of benchmark ;-) Case in point: In the project I work on for a living, I have been working on a series of performance improvements lately. In profiling, I found that a critical system thread spent a large fraction of its time in a function that was trivially optimisable; it was doing an inter-process call back into the same process (don't ask why...), which was then queued amongst other incoming requests before being handled, and the handler then simply checked the existence of a certain file, and sent the results back... so I changed the function to check for the existence of the file itself, without the IPC back into the same process. Result? Performance roughly HALVED. This was a surprise, but not a great shock, as the performance of complex threaded software is famous for being unexpected. We didn't have time to properly investigate, but I believe the problem is that causing this operation to run faster causes the thread to spend more of its time doing other things (rather than blocking on the IPC), and is therefore holding certain locks for a greater percentage of the time, blocking out other, more useful, things that could be happening. But without a benchmark, I'd have thought that this change couldn't possibly have any other effect than to improve performance :-) So we are back at the capacity issue again: I have only so much live time. I'm not ready to spent it maintaining benchmarks in the hope that those will eventually convince someone to benefit from the work I did. You are free to convince yourself. That's fine; it's just that you were complaining you didn't want to do benchmarks, which I now think was purely a communications mistake. Your httperf results are benchmarks, too, if a little informal, but infinitely better than just making changes that through inspection should improve performance, which was my fear :-) /Jörg ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EbhMACgkQRgz/WHNxCGoElgCgjWYuWJyhf/IxKng+UF5hqxGf OMsAn1O1Ly/kRojxwSCj2isdeGORF0lI =qCaS -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
Alaric Snell-Pym scripsit: If the supposed performance improvement can't be benchmarked, then it's pointless, as nobody will actually benefit from it. Any case where somebody can benefit from a performance improvement can be turned into a benchmark that consists of running the code that is sped up, and timing it. Benchmarks are like unit tests; they are snippets of code that perform some operation but, rather than testing correct responses, their emphasis is on testing resource usage. Your clarification down-thread that a benchmark can be of any size makes this comparison rather otiose. Nobody is going to have a benchmark suite that includes tests like these: With patch #1234, application 'foo' runs in an acceptable 18 hours rather than an intolerable 25 hours. (Obviously the improvement has to be nonlinear.) With patch #2345, vectors larger than 2^40 elements show O(1) reference behavior rather than not. With patch #3456, systems running more than 25 million green threads are able to make forward progress rather than thrashing. And yet, tested in the necessary environment, these patches may be sound and even necessary. -- [W]hen I wrote it I was more than a little John Cowan febrile with foodpoisoning from an antique carrot co...@ccil.org that I foolishly ate out of an illjudged faith http://ccil.org/~cowan in the benignancy of vegetables. --And Rosta ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 04:51 PM, John Cowan wrote: Alaric Snell-Pym scripsit: If the supposed performance improvement can't be benchmarked, then it's pointless, as nobody will actually benefit from it. Any case where somebody can benefit from a performance improvement can be turned into a benchmark that consists of running the code that is sped up, and timing it. Benchmarks are like unit tests; they are snippets of code that perform some operation but, rather than testing correct responses, their emphasis is on testing resource usage. Your clarification down-thread that a benchmark can be of any size makes this comparison rather otiose. Nobody is going to have a benchmark suite that includes tests like these: With patch #1234, application 'foo' runs in an acceptable 18 hours rather than an intolerable 25 hours. (Obviously the improvement has to be nonlinear.) Actually, where I work we do! The full test suite takes all weekend - on a cluster of fairly beefy hardware, running different bits in parallel. But there's a hierarchy of tests and benchmarks. The correctness tests we run on our laptops before committing code to the trunk take fifteen minutes, and we run benchmarks in the five-minute range for quickly checking the results of changes. The full suite runs only once a week... ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EmFQACgkQRgz/WHNxCGp2IwCfcofES+0R2BLmTBZ18wStt5Yf /zUAn3Z0NYBhWzWrDodOF6+gPi3441k5 =DVDu -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Wed, Sep 28, 2011 at 4:29 AM, Alan Post alanp...@sunflowerriver.org wrote: I don't have enough data to say that it matters in this case, but in principle it surely does. In theory, theory and practice are the same. In practice, they're different. The problem here specifically is the lack of data. Why even bother with a change like this without benchmark results to prove it's worth it (preferably tested across all the variety of platforms Chicken compiles on, with wildly differing branch prediction features)? The proper way to optimize is: 1) DON'T! Just write an application. If it's too slow for your purposes, then move on to 2) Profile. Find out where all the time is being spent. There's no point in optimizing something if it's not a significant factor in you performance. 3) Of the code sections you've determined the most time is being spent in, choose the one with the best estimated speedup-to-effort ratio. You should have an intuition that the code in question can be improved, either algorithmically (potential huge speedup) or by tuning (smaller speedup, usually uglier code, but may be less effort). Making this choice is something of an art, but is completely impossible without 2. 4) Write benchmarks that isolate what you want to optimize. Measure how fast the current solution is, if possible compared to alternative implementations or equivalent tasks in other languages. 5) If you don't already have a test suite, write one now that verifies the code used in the benchmark. It's too easy to write an optimized version of something that performs better initially, but worse once you fix the bugs in it. 6) Try one or more optimizations, and measure them compared to the result in 4 once they've passed the tests in 5. Iterate as often as you have time/ideas. 7) Of the best results in 6, determine if the speedup they introduce is worth the complexity they introduce. Keep in mind the maintenance cost will persist long term, and be shared by other people who want to work on the code. 8) Document what you tried regardless so people don't waste the same effort again! Include a one-line comment in the code itself with a link to more info if needed, e.g. ;; The following is a little ugly, but performs best in ;; practice - see benchmarks/widget-hack.scm. 9) Send a patch to the list with the benchmarks and tests as proof that the optimization is worth it. If you've come this far, the maintainers will almost certainly accept it. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
Will you show me this data for the current implementation? -Alan On Thu, Sep 29, 2011 at 10:30:00AM +0900, Alex Shinn wrote: On Wed, Sep 28, 2011 at 4:29 AM, Alan Post alanp...@sunflowerriver.org wrote: I don't have enough data to say that it matters in this case, but in principle it surely does. In theory, theory and practice are the same. In practice, they're different. The problem here specifically is the lack of data. Why even bother with a change like this without benchmark results to prove it's worth it (preferably tested across all the variety of platforms Chicken compiles on, with wildly differing branch prediction features)? The proper way to optimize is: 1) DON'T! Just write an application. If it's too slow for your purposes, then move on to 2) Profile. Find out where all the time is being spent. There's no point in optimizing something if it's not a significant factor in you performance. 3) Of the code sections you've determined the most time is being spent in, choose the one with the best estimated speedup-to-effort ratio. You should have an intuition that the code in question can be improved, either algorithmically (potential huge speedup) or by tuning (smaller speedup, usually uglier code, but may be less effort). Making this choice is something of an art, but is completely impossible without 2. 4) Write benchmarks that isolate what you want to optimize. Measure how fast the current solution is, if possible compared to alternative implementations or equivalent tasks in other languages. 5) If you don't already have a test suite, write one now that verifies the code used in the benchmark. It's too easy to write an optimized version of something that performs better initially, but worse once you fix the bugs in it. 6) Try one or more optimizations, and measure them compared to the result in 4 once they've passed the tests in 5. Iterate as often as you have time/ideas. 7) Of the best results in 6, determine if the speedup they introduce is worth the complexity they introduce. Keep in mind the maintenance cost will persist long term, and be shared by other people who want to work on the code. 8) Document what you tried regardless so people don't waste the same effort again! Include a one-line comment in the code itself with a link to more info if needed, e.g. ;; The following is a little ugly, but performs best in ;; practice - see benchmarks/widget-hack.scm. 9) Send a patch to the list with the benchmarks and tests as proof that the optimization is worth it. If you've come this far, the maintainers will almost certainly accept it. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Thu, Sep 29, 2011 at 12:09:19PM +0900, Alex Shinn wrote: On Thu, Sep 29, 2011 at 11:40 AM, Alan Post alanp...@sunflowerriver.org wrote: Will you show me this data for the current implementation? The first implementation doesn't need to justify itself, just be working. *nods* How did irregex, which by account is slower, replace the existing regex code? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Thu, Sep 29, 2011 at 12:25 PM, Alan Post alanp...@sunflowerriver.org wrote: How did irregex, which by account is slower, replace the existing regex code? I didn't make the call, but as I understand that was motivated by portability concerns, simplifying the Chicken distribution, and avoiding the frequently occurring memory bugs in PCRE. So speed wasn't a concern, but there is a class of regexps for which irregex is exponentially faster than PCRE. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Thu, Sep 29, 2011 at 12:33:41PM +0900, Alex Shinn wrote: On Thu, Sep 29, 2011 at 12:25 PM, Alan Post alanp...@sunflowerriver.org wrote: How did irregex, which by account is slower, replace the existing regex code? I didn't make the call, but as I understand that was motivated by portability concerns, simplifying the Chicken distribution, and avoiding the frequently occurring memory bugs in PCRE. So speed wasn't a concern, but there is a class of regexps for which irregex is exponentially faster than PCRE. -- Alex Thank you Alex. I understand, between all of this, that the bar is raised on smaller changes (and it probably ought to be, it's easier to bike shed a smaller change) but that usefully disruptive changes can be larger and require a lower burden of proof for inclusion. For the dubious purpose of pedantic completeness, This conversation does not include any proof of your second paragraph: that these exponentially faster regexps come up in practice: there's no citation of data or test cases to back up such an assertion. I did, for the first time this week, use a feature of irregex that was more than straightforward translation of a regex into irregex syntax. It was a light-bulb moment for me, as I was previously using irregex as a drop-in replacement and not appreciating it, for what I suspect are all the reason you're motivated to participate in this conversation. . -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On 28/09/11 11:33 PM, Alex Shinn wrote: On Thu, Sep 29, 2011 at 12:25 PM, Alan Postalanp...@sunflowerriver.org wrote: How did irregex, which by account is slower, replace the existing regex code? I didn't make the call, but as I understand that was motivated by portability concerns, simplifying the Chicken distribution, and avoiding the frequently occurring memory bugs in PCRE. So speed wasn't a concern, but there is a class of regexps for which irregex is exponentially faster than PCRE. And if I am not mistaken this rationale is nicely given by Russ Cox: http://swtch.com/~rsc/regexp/regexp1.html --Toby ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Tue, Sep 27, 2011 at 03:22:06PM +0200, Jörg F. Wittenberger wrote: While I've been looking at the code I wondered if the C compiler will fur sure pull that one test out of the for-loop. Maybe it's better no have it there at the first place. IMHO the code is not more confusing to read this way and should run better in case the C compiler is not smart enough. I'm firmly opposed to any such change that makes the code much less readable for very little gain. Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Sep 27 2011, Peter Bex wrote: On Tue, Sep 27, 2011 at 03:22:06PM +0200, Jörg F. Wittenberger wrote: While I've been looking at the code I wondered if the C compiler will fur sure pull that one test out of the for-loop. Maybe it's better no have it there at the first place. IMHO the code is not more confusing to read this way and should run better in case the C compiler is not smart enough. I'm firmly opposed to any such change that makes the code much less readable for very little gain. Please excuse me objecting. IMHO the code is not less readable the rewritten way. In fact - and so far it's a matter of taste - I would find it less confusing. (Let alone that it's fewer instructions.) However I'm quite old school. If I can tell the compiler something and not rely on the compilers cleverness, I'll do so. (And NOT do so iff I want to create a test case for the compiler.) In the case at hand I applied something which would have been typical educational example in the late 70th: pull conditionals out of frequently executed code if you can. Is there anybody on the list who has a test case at hand, which would exercise cons/list operations or initialisation code? (Mine would be suspicious in this case.) Looking at alternativ compilers (besides gcc) would be very nice. The chance, which - depending on taste, would make the code either more comprehensible or less - could have an actual effect. That would be the final argument in my case. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Tue, Sep 27, 2011 at 09:21:15PM +0200, Jörg F. Wittenberger wrote: On Sep 27 2011, Peter Bex wrote: On Tue, Sep 27, 2011 at 03:22:06PM +0200, Jörg F. Wittenberger wrote: While I've been looking at the code I wondered if the C compiler will fur sure pull that one test out of the for-loop. Maybe it's better no have it there at the first place. IMHO the code is not more confusing to read this way and should run better in case the C compiler is not smart enough. I'm firmly opposed to any such change that makes the code much less readable for very little gain. Please excuse me objecting. IMHO the code is not less readable the rewritten way. In fact - and so far it's a matter of taste - I would find it less confusing. (Let alone that it's fewer instructions.) However I'm quite old school. If I can tell the compiler something and not rely on the compilers cleverness, I'll do so. (And NOT do so iff I want to create a test case for the compiler.) In the case at hand I applied something which would have been typical educational example in the late 70th: pull conditionals out of frequently executed code if you can. Is there anybody on the list who has a test case at hand, which would exercise cons/list operations or initialisation code? (Mine would be suspicious in this case.) Looking at alternativ compilers (besides gcc) would be very nice. The chance, which - depending on taste, would make the code either more comprehensible or less - could have an actual effect. That would be the final argument in my case. FWIW I agree with Jörg'sreasoning. I've spend a fair bit of my C programming time removing conditional code from loops. It has been a few years since I tested, but when I was actively writing C code, removing opportunities for the branch predictor to fail measurably sped up code. I don't have enough data to say that it matters in this case, but in principle it surely does. Jörg's code is obvious to me in the manner of ah, that's removing a conditional from inside the for loop. BTW, I've loved reading the comments and patches suddenly flying around the mailing list. I'm learning a lot about Chicken and am particularly interested to see which parts of the system apparently receive attention and which aren't being changed. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
