[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Write procedure is not backwards compatible
John Cowan <cowan@x> 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@x | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.