Re: Eu integers [was eternity]
CChris wrote:
>
> Jason Gade wrote:
> >
> > Matt explained it better... I forgot that it was actually so clever.
> >
> > I recently wiped my HD and am still restoring so I don't think that I have
> > the
> > source code handy right now, and I haven't looked at it in awhile.
> >
> >
> > --
> > A complex system that works is invariably found to have evolved from a
> > simple
> > system that works.
> > --John Gall's 15th law of Systemantics.
> >
> > "Premature optimization is the root of all evil in programming."
> > --C.A.R. Hoare
> >
> > j.
>
>
> Clever, really?
> Efficient, no doubt about it. This feature is probably one of the main causes
> of overall Euphoria's speed.
>
> However, this prevents any extension of the language with new types as
> frequently
> requested here (NIL, typed sequences, large integers, fractions, probably
> forgetting
> some). As mentioned several times on this list, adding such types now, keeping
> the current structure of the backend, would degrade its performance
> significantly.
>
> So, it is an efficient implementation which has put the language in kind of
> a dead end. Going 64 bit and allotting one more bit for types might alleviate
> the problem for a while. But we are not there yet.
>
> What I don't really understand is why the semantics of the integer type are
> the weird thing we know. Actualy, we could have an integer type that takes
> values
> from -2^53-1 to 2^53-1, and it should remain an internal, hidden detail that
> such numbers are stored in doubles when their magnitude reaches 2^30. This
> is what is being used for task ids by the way.
>
> CChris
Well, in keeping with the gawdaweful practice of using 32bits for one 7 or 8bit
ascii character, how about useing an entire 32bit memory location for the data
about the 32bits following it? At least then, a 2^32 integer would be the entire
2^32. And four 8bit ascii chars would take only two 32bit memory locations (and
fetches) instead of the current four locations and fetches. A 64bit value would
be one type fetch, the following pointer fetch, then the fetch of that location
and the following one. With 32bits of type, you could make huge floating point
numerals with outrageous significant digits, simply by specifying the number of
following 32bit fetches needed to fill that type, breaking the predetermined
"640k is enough for anyone" type of bottleneck forever (within some predetermined
reasonableness,, praps 255 32bit (8160 bits) or 64bit (16,320 bits) fetches per
integer is enough?).
This approach has another advantage: if you do it this way now, it's easily
ported to a future 64bit world, in one fetch you have the 32bit type
representation and a 32bit data field already done. I know nothing of *nix, but
chances are windoze will still limit each application to 2^32 bytes for pointers
anyhow. Eu can still have a type that includes the following 64bits as additional
data anyhow.
Any way i look at it, keeping the data with the type info has cascading
drawbacks, but like you said, it's fast in Eu.
Kat,
hasn't studied the current source code,
is shooting from the hip,
is applying flame retardant now.
|
Not Categorized, Please Help
|
|
