Front page | perl.perl5.porters |
Postings from February 2001
On Fri, Jan 05, 2001 at 03:50:07PM +0000, Nicholas Clark wrote: > On Sun, Dec 31, 2000 at 12:19:24AM -0500, Ilya Zakharevich wrote: > > This patch does not fix new bugs introduced by IV-preservation > > madness. Also, the second chunk may cause problems for other > > Why is it mad? I don't remember reading anything here from you saying why > you thought it was a bad idea or a bad implementation Sorry that it took me so long. Here are chunks of my discussion with Jarkko (with minor corrections): ================================================================== I checked one line of the code only - one where the segfault is happening on OS/2 (this segfault might be attributed to video drivers, so might be not Perl fault). This one line indicates that when NV is used in the IV/Uv context, the converted value is not cached. This line alone makes the approach deserving rejection. ================================================================== The *only* case when this adds some new functionality is on the platforms with 64-bit floats and 64-bit integers. These platforms are a tiny minority, and have a possiblity to use long floats intead. So the patch is not *required*. ================================================================== The only non-functionality advantage this approach adds is the memory footprint one. Again, when compensated by unavoidable slowdowns due to switching off caching, this should be negligeable. [And do not try to push "make test" like benchmarking at me. On contemporary hardware the most (significant part of the?) time spent in "make test" is inside the sleep() calls! Remember this slogan: "Buy Soviet watches, the quickiest-running watches in the world!"?] ================================================================== Many benchmarks failed to discover any measurable speed advantage of `use integer'. Thus this approach will also not have a speed advantage even in the cases when effects of no-caching do not enter the picture. ================================================================== The handling of floating point operations is not to be put into hands of unwashed masses. I would not like anyone with less trust than what Kagan has to touch such topics (definitely not me!). Witness all the goofs in FP operation of processors - even when designed by people who understand all the hairy issues of FP operations. This patch wants to replace some operations done by the FPU by operations in software. First of all, moving operations from hardware to software is at least a questionable practice. Second, the possibilities of bugs introduced by uneducated patching are limitless (I do not know, maybe Nicholas has the FPU-design qualification? Even in this case, expect very hard-to-find bugs). ================================================================== This patch greatly blows up the size of the C code to support arithmetic operations in Perl. My estimates would be 1000x times harder maintainance of these opcodes. Though only a small part of the total Perl core, such a significant change cannot be unnoticed. ================================================================== These were my feelings when I saw this announcement on the digest (plus what I get by trying to find a bug in 10min). I had no doubt that given so many reasonable people on p5p (including those who work in the processor design!) this patch would be rejected. Had I known, I would try to find time to voice my opinion earlier. ================================================================== On the scale of disasters in the Perl design, IMO this is less than the qu// horror, but on par with forcing h2xs to produce a backwards-incompatible code, v3.4.5 thingies, or using REx-opcodes which switch their unicode-face at runtime. Hope this helps, Ilya