Re: How to package SuperCollider (or, whats the deal with multiarch)
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).
>
> Briliant. I just love when programers write non portable code for the
> sake of performance. :)
Well, I've been there, felt like that, but I sort of understand
the original decision. realtime audio synthesis is really very demanding
on the CPU, so it is very understandable why the author wanted to get
the best possible performance for his interpreter language.
> What if some future architecture has the ability to run your code
> way faster but can't run it because of the clunky code you decided
> to write.
In this specific case, that is a very hypothetical thesis... I cant really
imagine an arch which does say 80bit or 128bit floating point math
faster than 64bit... OTOH, I dont really know what I am talking about here,
I am not a hardware person.
> This has been done many times before and every single time it
> eventually became a big problem.
>
> I wonder how hard it would be to change it to using a struct of a 32 and
> a 64bit value instead.
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.
>> OTOH, the synthesis server builds in 64bit mode, and works nicely. It
>> actually has to be built 64bit, since it links to JACK, which
>> is most probably a 64bit version on an debian amd64 box...
>>
>> Now, I can build and install this stuff by hand, simply build the
>> server on the system as usual, and build the language client in a sid-ia32
>> chroot, do the ld.so.conf magic and symlink sclang. That works
>> nicely.
>> However, I am kind of wondering how to solve this properly
>> when it comes to packaging supercollider?
>> I am not up-to-date with how multiarch is exactly ment to work
>> these days, would it fit this kind of application?
>> If so, whats the proper way to do it, and can this already be done
>> with the infrastructure currently in amd64 sid?
>
> Well best case, the code gets cleaned up to be 64bit clean.
>
> Worst case you don't package it for 64bit machines.
>
> Or you can perhaps make the package so that it only builds the "client"
> on 32bit systems, and builds the server packages on all systems.
These three cases I already worked out, I was looking for case 4 :-),
or some ambitioned porter willing to take a look at it and help...
--
CYa,
Mario
Reply to: