Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[Jörg F . Wittenberger]

Am 04.10.2016 um 16:19 schrieb felix.winkelm...@bevuta.com:
>> On Tue, Oct 4, 2016 at 4:00 AM,  wrote:
>>
 We could still get rid of the tagged pointer type.  After some more
>>>
>>
>>
 thought on the matter, I believe they're mostly worthless.
>>>
>>> "They" means tagged pointers? I agree.
>>>
>>
>> I continue to disagree.  Tagged pointers make it possible to have
>> dynamically type-safe or type-dispatched treatment of C objects referred to
>> by the pointer side.  Logically it is equivalent to encapsulate the raw
>> pointer in a record, but record dereference is much slower than pointer
>> dereference for whatever reason, so it adds substantial overhead.
> 
> "Substantial" may be a bit strong, though the overhead is indeed there.
> AFAIK, tagged pointers are seldom used. If indeed they were used instead
> of raw pointers everywhere in the FFI (say, by generally tagging each
> pointer of a known type), then the situation would be different, of course.
> 
> I don't feel strong enough to assess this. Any takers?

At least some eggs would break.  However, so far I found only iup among
those I'm using.

/Jörg


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[felix . winkelmann]

> On Tue, Oct 4, 2016 at 4:00 AM,  wrote:
> 
> > > We could still get rid of the tagged pointer type.  After some more
> >
> 
> 
> > > thought on the matter, I believe they're mostly worthless.
> >
> > "They" means tagged pointers? I agree.
> >
> 
> I continue to disagree.  Tagged pointers make it possible to have
> dynamically type-safe or type-dispatched treatment of C objects referred to
> by the pointer side.  Logically it is equivalent to encapsulate the raw
> pointer in a record, but record dereference is much slower than pointer
> dereference for whatever reason, so it adds substantial overhead.

"Substantial" may be a bit strong, though the overhead is indeed there.
AFAIK, tagged pointers are seldom used. If indeed they were used instead
of raw pointers everywhere in the FFI (say, by generally tagging each
pointer of a known type), then the situation would be different, of course.

I don't feel strong enough to assess this. Any takers?


felix


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[John Cowan]

On Tue, Oct 4, 2016 at 4:00 AM,  wrote:

> > We could still get rid of the tagged pointer type.  After some more
>


> > thought on the matter, I believe they're mostly worthless.
>
> "They" means tagged pointers? I agree.
>

I continue to disagree.  Tagged pointers make it possible to have
dynamically type-safe or type-dispatched treatment of C objects referred to
by the pointer side.  Logically it is equivalent to encapsulate the raw
pointer in a record, but record dereference is much slower than pointer
dereference for whatever reason, so it adds substantial overhead.

--
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[felix . winkelmann]

> > A somewhat disturbing patch, but it does indeed simplify the
> > code.
> 
> What's disturbing?  The huge amount of changes?

So many hardcoded numbers, easy to get things wrong.

> 
> > Having only one type bit lefft worries me a bit, though.
> 
> We could still get rid of the tagged pointer type.  After some more
> thought on the matter, I believe they're mostly worthless.

"They" means tagged pointers? I agree.


felix


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[Peter Bex]

On Mon, Oct 03, 2016 at 09:12:53PM +0200, felix.winkelm...@bevuta.com wrote:
> > On Mon, Aug 08, 2016 at 10:56:39PM +0200, Peter Bex wrote:
> > > The attached patches add a custom type for bignums (first patch) and
> > > custom types for ratnums/cplxnums (second patch).  This reduces the
> > > aforementioned C_s_a_i_times() pre-allocation from 40 to 29 words.
> >
> > Here's an updated version, because the original patch doesn't apply
> > anymore due to the C_BUCKET_TYPE removal.
> 
> Signed off and pushed.

Hurrah!  Thank you.

> A somewhat disturbing patch, but it does indeed simplify the
> code.

What's disturbing?  The huge amount of changes?

> Having only one type bit lefft worries me a bit, though.

We could still get rid of the tagged pointer type.  After some more
thought on the matter, I believe they're mostly worthless.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[felix . winkelmann]

> On Mon, Aug 08, 2016 at 10:56:39PM +0200, Peter Bex wrote:
> > The attached patches add a custom type for bignums (first patch) and
> > custom types for ratnums/cplxnums (second patch).  This reduces the
> > aforementioned C_s_a_i_times() pre-allocation from 40 to 29 words.
> 
> Here's an updated version, because the original patch doesn't apply
> anymore due to the C_BUCKET_TYPE removal.

Signed off and pushed. A somewhat disturbing patch, but it does indeed simplify 
the
code. Having only one type bit lefft worries me a bit, though.


felix


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[Peter Bex]

On Mon, Aug 08, 2016 at 10:56:39PM +0200, Peter Bex wrote:
> The attached patches add a custom type for bignums (first patch) and
> custom types for ratnums/cplxnums (second patch).  This reduces the
> aforementioned C_s_a_i_times() pre-allocation from 40 to 29 words.

Here's an updated version, because the original patch doesn't apply
anymore due to the C_BUCKET_TYPE removal.

Cheers,
Peter
From 2feef375870082542a17412e5e9da23dee0425ac Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 7 Aug 2016 21:32:59 +0200
Subject: [PATCH 1/2] Change bignum representation to use a custom type.

Instead of using a generic record type with a "bignum_type_tag" symbol
slot, we use a custom object containing only a pointer to the actual
bignum data.

This saves at least one slot when pre-allocating for a call to an
arithmetic operator.  In case of the generic operators, this can save up
to four slots (maximum size is allotted for a complex number consisting
of two ratnums, each containing two bignums; so four bignums in total).

Less allocation results in slower nursery growth, which in turn means
minor garbage collections will happen less frequently.

The change in object type also means we need to do one less check in
the bignum? predicate.
---
 c-backend.scm  |  4 ++--
 c-platform.scm | 22 -
 chicken.h  | 42 ++--
 library.scm| 24 +--
 runtime.c  | 22 +++--
 types.db   | 76 +-
 6 files changed, 96 insertions(+), 94 deletions(-)

diff --git a/c-backend.scm b/c-backend.scm
index 6e271e4..f58d3d4 100644
--- a/c-backend.scm
+++ b/c-backend.scm
@@ -671,9 +671,9 @@
 
 (define (literal-size lit)
   (cond ((immediate? lit) 0)
-	((big-fixnum? lit) 3)   ; immediate if fixnum, bignum see below
+	((big-fixnum? lit) 2)   ; immediate if fixnum, bignum see below
 	((string? lit) 0)		; statically allocated
-	((bignum? lit) 3)		; internal vector statically allocated
+	((bignum? lit) 2)		; internal vector statically allocated
 	((flonum? lit) words-per-flonum)
 	((symbol? lit) 7)   ; size of symbol, and possibly a bucket
 	((pair? lit) (+ 3 (literal-size (car lit)) (literal-size (cdr lit
diff --git a/c-platform.scm b/c-platform.scm
index 7e4528b..d929651 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -584,11 +584,11 @@
 
 (rewrite 'abs 14 'fixnum 1 "C_fixnum_abs" "C_fixnum_abs")
 
-(rewrite 'chicken.bitwise#bitwise-and 21 -1 "C_fixnum_and" "C_u_fixnum_and" "C_s_a_i_bitwise_and" 6)
-(rewrite 'chicken.bitwise#bitwise-xor 21 0 "C_fixnum_xor" "C_fixnum_xor" "C_s_a_i_bitwise_xor" 6)
-(rewrite 'chicken.bitwise#bitwise-ior 21 0 "C_fixnum_or" "C_u_fixnum_or" "C_s_a_i_bitwise_ior" 6)
+(rewrite 'chicken.bitwise#bitwise-and 21 -1 "C_fixnum_and" "C_u_fixnum_and" "C_s_a_i_bitwise_and" 5)
+(rewrite 'chicken.bitwise#bitwise-xor 21 0 "C_fixnum_xor" "C_fixnum_xor" "C_s_a_i_bitwise_xor" 5)
+(rewrite 'chicken.bitwise#bitwise-ior 21 0 "C_fixnum_or" "C_u_fixnum_or" "C_s_a_i_bitwise_ior" 5)
 
-(rewrite 'chicken.bitwise#bitwise-not 22 1 "C_s_a_i_bitwise_not" #t 6 "C_fixnum_not")
+(rewrite 'chicken.bitwise#bitwise-not 22 1 "C_s_a_i_bitwise_not" #t 5 "C_fixnum_not")
 
 (rewrite 'chicken.flonum#fp+ 16 2 "C_a_i_flonum_plus" #f words-per-flonum)
 (rewrite 'chicken.flonum#fp- 16 2 "C_a_i_flonum_difference" #f words-per-flonum)
@@ -674,12 +674,12 @@
 (rewrite 'lcm 18 1)
 (rewrite 'list 18 '())
 
-(rewrite '+ 16 2 "C_s_a_i_plus" #t 36)
-(rewrite '- 16 2 "C_s_a_i_minus" #t 36)
-(rewrite '* 16 2 "C_s_a_i_times" #t 40)
-(rewrite 'quotient 16 2 "C_s_a_i_quotient" #t 6)
-(rewrite 'remainder 16 2 "C_s_a_i_remainder" #t 6)
-(rewrite 'modulo 16 2 "C_s_a_i_modulo" #t 6)
+(rewrite '+ 16 2 "C_s_a_i_plus" #t 32)
+(rewrite '- 16 2 "C_s_a_i_minus" #t 32)
+(rewrite '* 16 2 "C_s_a_i_times" #t 36)
+(rewrite 'quotient 16 2 "C_s_a_i_quotient" #t 5)
+(rewrite 'remainder 16 2 "C_s_a_i_remainder" #t 5)
+(rewrite 'modulo 16 2 "C_s_a_i_modulo" #t 5)
 
 (rewrite '= 17 2 "C_i_nequalp")
 (rewrite '> 17 2 "C_i_greaterp")
@@ -829,7 +829,7 @@
 			 (make-node '##core#inline
 '("C_i_fixnum_arithmetic_shift") callargs)
 			 (make-node '##core#inline_allocate
-(list "C_s_a_i_arithmetic_shift" 6)
+(list "C_s_a_i_arithmetic_shift" 5)
 callargs) ) ) ) ) ) ) ) )
 
 (rewrite '##sys#byte 17 2 "C_subbyte")
diff --git a/chicken.h b/chicken.h
index fdad916..96a03ea 100644
--- a/chicken.h
+++ b/chicken.h
@@ -464,7 +464,7 @@ static inline int isinf_ld (long double x)
 # define C_PAIR_TYPE  (0x0300L)
 # define C_CLOSURE_TYPE   (0x0400L | C_SPECIALBLOCK_BIT)
 # define C_FLONUM_TYPE(0x0500L | C_BYTEBLOCK_BIT | C_8ALIGN_BIT)
-/*   unused   (0x0600L ...) */
+# define C_BIGNUM_TYPE(0x0600L) /* Just the wrapper */
 # define C_PORT_TYPE  

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[Peter Bex]

On Tue, Aug 09, 2016 at 10:31:54AM +0200, felix.winkelm...@bevuta.com wrote:
> > All in all, I think these changes are worthwhile but for the caveat
> > that it results in us having NO MORE reserved type tags left!  In
> > fact, the complete change is only possible because we dropped the
> > SWIG pointer type; before that we only had two reserved types left.
> > I don't see an easy way to reclaim type tags elsewhere; we don't have
> > that many.  Maybe (but only MAYBE) we could get rid of lambda info as
> > a separate core type.
> 
> Maybe we can phase out the "tagged pointer" type? Having one reserved tag
> left would be a good thing, IMHO.

I think we agree that one of the pointer types can go.  I would like to
re-focus on the patch(es) at hand.  We can discuss the pointer changes
further in a different thread, and/or at the summer meeting.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[Peter Bex]

On Tue, Aug 09, 2016 at 10:31:54AM +0200, felix.winkelm...@bevuta.com wrote:
> > All in all, I think these changes are worthwhile but for the caveat
> > that it results in us having NO MORE reserved type tags left!  In
> > fact, the complete change is only possible because we dropped the
> > SWIG pointer type; before that we only had two reserved types left.
> > I don't see an easy way to reclaim type tags elsewhere; we don't have
> > that many.  Maybe (but only MAYBE) we could get rid of lambda info as
> > a separate core type.
> 
> Maybe we can phase out the "tagged pointer" type? Having one reserved tag
> left would be a good thing, IMHO.

By the way, you didn't go into detail about my idea to remove lambda info
as a separate type.  Can you explain why (if?) this needs to be a
separate type?  As far as I can tell, it's just a glorified string that
lives in the procedure decoration area.  I guess it's because this would
cost us at least 3 more words per closure? (but only if lambda info is
enabled, of course)

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[felix . winkelmann]

> My main concern, after giving it some more thought, is that you can't
> easily make the FFI check the pointer type, unless you enforce that
> pointer tags are somehow either compile-time constants, or also stored
> in some global that's directly accessible to the FFI.  There should be
> a low-overhead and simple type check, which is also statically
> expressible, otherwise one might just as well define their own
> foreign type with conversion procedures, so, a record type with the
> pointer inside it like this [...]

You could use a simple global counter for tags and map this numeric tag to
something else (like symbols) through a global table. The real meaning
of the tag is only interesting in Scheme code (introspection, printing, error
messages), but not on the FFI-level. The one situation where this gets
complicated is when serializing, but then you could serialize the
full tag value, together with the pointer (whether serializiing pointers
is useful or not is another question, of course, but it may be needed
sometimes.)


felix


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[John Cowan]

Peter Bex scripsit:

> That's not their main usefulness.  The main usefulness is that you can
> treat them like any other _pointer_ type, yet they can be kept apart
> if you want to by checking the tag.

Quite so.  They are pointers, but the tag allows you to factor them
into Scheme-detectable types without losing their pointer nature.
In essence, they let you subtype pointers.

> My main concern, after giving it some more thought, is that you can't
> easily make the FFI check the pointer type, unless you enforce that
> pointer tags are somehow either compile-time constants, or also stored
> in some global that's directly accessible to the FFI.  

As someone who has used them in the past, I would be quite content to
require that tags be symbols.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Consider the matter of Analytic Philosophy.  Dennett and Bennett are well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett.
There is also one Dummett.  By their works shall ye know them.  However, just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the function
of this and other e-mail messages, therefore, to do what they can to create him.

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[Peter Bex]

On Tue, Aug 09, 2016 at 10:31:54AM +0200, felix.winkelm...@bevuta.com wrote:
> > All in all, I think these changes are worthwhile but for the caveat
> > that it results in us having NO MORE reserved type tags left!  In
> > fact, the complete change is only possible because we dropped the
> > SWIG pointer type; before that we only had two reserved types left.
> > I don't see an easy way to reclaim type tags elsewhere; we don't have
> > that many.  Maybe (but only MAYBE) we could get rid of lambda info as
> > a separate core type.
> 
> Maybe we can phase out the "tagged pointer" type? Having one reserved tag
> left would be a good thing, IMHO.

Yeah, tagged pointers don't have much added value, but that's mostly
because there's no way to force the type.  It would be more useful if
you could annotate foreign function declarations so that they only
accept pointers with a given tag.

Here's a radical idea: How about removing the plain "pointer" type?  It
can be implemented as a tagged pointer with a tag of whatever we like
(for example #f).  It does mean that each and every pointer needs another
word of storage, but most code doesn't rely on pointers very heavily
anyway.

I find it difficult to choose between these two kinds of pointers.
It feels a bit like a tagged pointer is just as easily represented by
a pointer in a record type of one field.  On the other hand, like I
mentioned above, it might be better to embrace the pointer's tag and
make the FFI able to rely on tag checking for extra safety.  If we
go this route, we would also need to add a tag to the pointer-vector,
though, I think...

Anyway, food for thought.  But I also don't really see why we absolutely
need to have a reserved tag, which does nothing.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[felix . winkelmann]

> All in all, I think these changes are worthwhile but for the caveat
> that it results in us having NO MORE reserved type tags left!  In
> fact, the complete change is only possible because we dropped the
> SWIG pointer type; before that we only had two reserved types left.
> I don't see an easy way to reclaim type tags elsewhere; we don't have
> that many.  Maybe (but only MAYBE) we could get rid of lambda info as
> a separate core type.

Maybe we can phase out the "tagged pointer" type? Having one reserved tag
left would be a good thing, IMHO.


felix


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers