John Cowan <cowan@mercury.ccil.org> wrote: > Aaron W. Hsu scripsit: > > > > Less tendentiously, write/small-fast. > > > > Have we done any benchmarks to see how fast this really is in practice? > > It seems like we are assuming it is faster, but I do not remember seeing > > anything indicating that it was really significantly faster than > > WRITE/SAFE. IMO, the lack of safety of WRITE/SMALL-FAST is hard to justify. [...] > Alternatively, you can traverse the whole graph using the length algorithm > before you start to print anything, but that necessarily costs time. My question was not whether it costs time at all, but whether that cost is actually significant. I am sure that you could come up with some arbitrary micro-benchmarks that would allow you to measure this cost, but what I really want to know is whether this cost is a measurable, significant part of any unwanted lack in performance in non-trivial, practical code where people care about the speed of the program execution. I strongly suspect, but have no proof, that the cost of having a safe write procedure is dwarfed by most other costs, and will not contribute significantly to the running time of the vast majority of programs, if it contributes significantly to any at all. If this suspicion is true, then there is no reason to have a standard, unsafe write procedure. The dangers that it necessarily entails cannot be justified, either in terms of the cost of putting in the standard itself, or the cost in maintainence compared to just using the safe variant. Like I said, in the worst case, this is a flag you switch on and off for compilers. I see no justification for putting it in the standard. I see justification for the other two variants, and I think that keeping the unsafe version and the shared version, but leaving the safe variant out of the standard is strange. It's like saying that we should have fx+ but not +, to me. > Lastly, write/small-fast is perfectly safe if you know you don't construct > cycles, and lots of programs do know that (if they don't use set-car! or > set-cdr!, for example). Again, it strikes me as the wrong choice to have an unsafe variant sitting around for no demonstrable benefit, leaving out the safe one. This is a performance hack that need not be in the standard. -- Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us Programming is just another word for the lost art of thinking. _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
