Re: Phix language
- Posted by petelomax Nov 29, 2011
- 2083 views
I sometimes dream about alternative implementations of sequences. We could obsolete bitwise operations and use sequences with logical operations instead. Just as we have atoms which could be implemented as 30-bit ints or double floating points in a structure, sequences could also be either the struct s1 we have now and a special one such that each member was only one bit. I mean with no syntax changes. You implemented 8-bit members in sequences. Did you do it without changing the syntax or did you have this as a hidden implementation detail? How did that change affect performance?
Shawn Pringle
It's not entirely straightforward.
Both OpenEu and Phix have 31 bit integers in the range #C0000000 to #3FFFFFFF, ie beginning 0b00 or 0b11. I think they both use #40000000 to indicate <no value> and other values are shifted memory addresses. OpenEu shifts 3 bits, requiring data to be quad-word aligned, and uses one bit to distinguish a float from a dword-sequence (cmiiw). Phix shifts 2 bits, only requiring data to be dword-aligned, and uses a type byte in the data header, potentially 255 datatypes, currently using 3: #12 float, #80 dword-sequence, #82 8-bit string.
Performance-wise, some programs are up to four times faster in Phix, but several indexing operations are (unavoidably) around 30% slower, because of an additional low-level test.
A program like Edita is noticeably faster but a fair number of benchmarks are slower. Swings and roundabouts I suppose but if pushed I'd have to say adding 8-bit strings to OpenEu would probably not be a good idea, especially so with the extent of the changes it would require. Likewise adding say #81 to Phix for a bit array could potentially increase that 30% overhead to 60% on general subscript ops.
So to answer your question it is a hidden implementation detail, with gains and losses.
Regards, Pete
