Hi Arne,
Arne Babenhauserheide writes:
> I don’t understand the implications of this, but I realized that I would
> love to have info about the sizes of different datastructures in Guile.
Sure.
> I recently started measuring how much memory is required for a record
> compared to a list, so I
Hi,
Mark H Weaver skribis:
> Ludovic Courtès writes:
>> Though an immediate, like a fixnum or an iflo, is still something
>> different from a tagged heap object like a pair, right? So I would
>> expect SCM_THOB_P to be a different test, not a drop-in replacement for
>> SCM_NIMP, is that
Ludovic Courtès writes:
> Though an immediate, like a fixnum or an iflo, is still something
> different from a tagged heap object like a pair, right?
I should clarify that in this new approach, a pair is *not* a tagged
heap object. Tagged heap objects are those which have a tag in their
first
Hi Ludovic,
Ludovic Courtès writes:
> Though an immediate, like a fixnum or an iflo, is still something
> different from a tagged heap object like a pair, right? So I would
> expect SCM_THOB_P to be a different test, not a drop-in replacement for
> SCM_NIMP, is that correct?
That's right.
Hello,
Mark H Weaver skribis:
> Ludovic Courtès writes:
[...]
>> IIUC, your plan is to have a different tagging on 32-bit platforms,
>> without fixflos, right? I’m curious to see how much complexity would
>> entail from that.
>
> Yes, although I'm avoiding the term "fixflos" because IEEE
I should mention that I'm very open to suggestions Andy might have about
any of this. The new approach I'm currently working on with tagged pair
pointers requires changes to both the VM and the compiler, and I'm not
confident that I've made the best choices there. I've made some
preliminary
Hi Ludovic,
Ludovic Courtès writes:
> As Dave Thompson wrote on IRC yesterday, this can make a significant
> difference for applications such as graphics and game engines.
Yes, it's especially important to be able to avoid heap allocation in
games, where GC pauses can be painful. However, any
> On 8 Jun 2019, at 11:08, Chris Vine wrote:
>
> On Sat, 08 Jun 2019 10:07:45 +0200
> Arne Babenhauserheide wrote:
> [snip]
>> Wow, I didn’t know that you could do that.
>>
>> However: "The details of that allocation are implementation-defined, and
>> it's undefined behavior to read from the
On Sat, 08 Jun 2019 11:46:10 +0200
Arne Babenhauserheide wrote:
> Chris Vine writes:
> > On Sat, 08 Jun 2019 10:07:45 +0200
> > Arne Babenhauserheide wrote:
> > [snip]
> >> Wow, I didn’t know that you could do that.
> >>
> >> However: "The details of that allocation are implementation-defined,
Chris Vine writes:
> On Sat, 08 Jun 2019 10:07:45 +0200
> Arne Babenhauserheide wrote:
> [snip]
>> Wow, I didn’t know that you could do that.
>>
>> However: "The details of that allocation are implementation-defined, and
>> it's undefined behavior to read from the member of the union that
On Sat, 08 Jun 2019 10:07:45 +0200
Arne Babenhauserheide wrote:
[snip]
> Wow, I didn’t know that you could do that.
>
> However: "The details of that allocation are implementation-defined, and
> it's undefined behavior to read from the member of the union that wasn't
> most recently written."
Mark H Weaver writes:
> Mark H Weaver writes:
>
>> Here's the format of fixrats on 64-bit systems:
…
> This allows for an elegant packing operation:
>
> if (SCM_I_INUMP (numerator) && SCM_I_INUMP (denominator))
> {
> union { double f; uint64_t u; } u;
> u.f = SCM_I_INUM
Mark H Weaver writes:
> Here's the format of fixrats on 64-bit systems:
>
> Srrx0111
> |\/\___/\__/
> | | | |
> | rank (6
Hi Mark,
Mark H Weaver skribis:
> I've found a way to efficiently support both immediate IEEE binary-64
> doubles up to ~1.158e77 (with larger ones transparently allocated on the
> heap), and also immediate exact rationals with up to 54 binary digits
> (~16 decimal digits), without restricting
On Thu, Jun 06, 2019 at 05:40:39AM -0400, Mark H Weaver wrote:
> I've found a way to efficiently support both immediate IEEE binary-64
> doubles up to ~1.158e77 (with larger ones transparently allocated on the
> heap), and also immediate exact rationals with up to 54 binary digits
> (~16 decimal
Mark H Weaver writes:
> I have a working draft implementation that roughly doubles the speed of
> a simple "substract 1.0 until negative" loop for inexact reals less than
> 2^256, compared with current 'master' (near 2.9.2). The same loop for
> exact rationals runs in ~70% of the time compared
Earlier I wrote:
> There's also a nice way to extract the denominator from a fixrat: mask
> out the sign bit, shift right 5 bits, and interpret it as an IEEE
> double. The denominator will be the integer part of the resulting
> value, with the numerator in the fraction bits. Simply cast this
17 matches
Mail list logo
