develooper Front page | perl.perl5.porters | Postings from February 2001

Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)

Ilya Zakharevich
February 14, 2001 12:07
Re: IV preservation (was Re: [PATCH 5.7.0] compiling on OS/2)
Message ID:
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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About