Re: Eu integers [was eternity]
Kat wrote:
>
> 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.
Although I'd switch to 2-byte storing for a chat, which gives access to all
Unicode UTF-16 encoded chars. This suggests that some types would need only 1
location and fetch (high word = type info, low word=data), an others would
require two, because the data itself needs 32 bits (it could point to an
arbitrarily long large integer for instance).
> 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.
>
Windows-x64 has provisions for 64 bit pointers, but 32 bit integers, so that the
plain fetch won't really work. Unless you use the XMM registers to transfer 128
bits at a time.
> 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.
CChris
|
Not Categorized, Please Help
|
|
