[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: loss of abstraction

This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.

Marcin 'Qrczak' Kowalczyk wrote:
>>I would be interested to hear why you might want to associate source
>>location with other types of object.
> For example to report that it obviously has a wrong type, in an
> implementation which tries to infer some types statically.
> E.g. (apply f 5).

I would associate this error with location of the call to apply.

>>(b) You can distinguish small integers by having interned small
>>integers be unboxed[**] and uninterned small integers be boxed.
> This complicates the implementation. It's silly to introduce
> non-canonical representation of integers just for this reason.

I think you are exagerating. If you support boxed bignums, then this approach does not significantly complicate the implementation.

>>[**] Boxed small integers are not necessarily a serious performance
>>problem if you use a cache of very small integers.
> It's still some performance hit:
> - The cache is much smaller than the range of unboxed numbers
> - Reading the value has to dereference a pointer and use processor
>   cache
> - There is no single representation used in various places where
>   values are known to fit in a machine word, e.g. vector indices

I benchmarked my Scheme with first boxed numbers with a cache and then with unboxed numbers. I found there was no significant difference. Of course, it depends on how often you hit the cache. I was using tak, which can stay completely in the cache.


Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México