Mario Lang wrote:
lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:On Tue, Dec 13, 2005 at 01:53:04PM +0100, Mario Lang wrote:SuperCollider is for some reason I am going to explain below a bit strange when it comes to porting it to AMD64: SC consists of two separate programs, the synthesis server (connects to JACK), and the language client which executes SCLang code. Both processes communicate with each other via UDP (OSC). For reasons of design and speed vs. space tradeoffs, the language *has* to be compiled as a 32bit binary. The 64bit build fails at runtime due to pointer size overflows. (if anyone wants to know more about it, the main reason for this is that SCLang uses a kind of slot-mechanism to hold direct and indirect values all in a 64bit double, therefore a 64bit pointer + tag does not fit).
Does it have to be a pointer, or could this code be rewritten to use an array index instead? You may then take care to keep the array smaller than 4GB, and only need 32-bit offsets. Even on a 64-bit platform.
Briliant. I just love when programers write non portable code for the sake of performance. :)
I've looked at it, and it is doable. However, I think it would require some preprocessor magic, since currently, copying slots is done by assignment, which is definitely faster than a memcpy of a struct... But I agree, a proper patch which is acceptable by upstream would be favourable. Only to a purist I am afraid, the userbase seems quite happy with the current situation. And upstream is not going to accept a solution which reduces performance for a 32bit address space version.
Then there is the possibility of #ifdef, that lets you keep the 32-bit code unchanged and do it differently in the 64-bit case. Perhaps this is necessary, seeing how the optimization is nice but 32-bit specific. Helge Hafting