Re: How to package SuperCollider (or, whats the deal with multiarch)
Anthony DeRobertis <anthony@derobert.net> writes:
> Mario Lang wrote:
>
>> 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...
>
> M68K comes to mind, I think that might do 80bit FP faster than it does
> 64-bit (because the FPU does 80-bit). I'd have to pull out my M68K books...
Doesn't matter anyway, since M68K is in no way going
to be fast enough to run serious SuperCollider programs, so.
SC was written (and is still primarily used) on Macs
under OSX.
>> 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...
>
> The assignment operator ought to be fairly well optimized. Actually,
> memcpy might be, too. Remember, memcpy is a part of the C standard
> library; the compiler is perfectly free to implement it any way it
> choses --- it need not be a function call. I think GCC might actually do
> this.
Yes, thanks for the nice demonstration, so memcpy
is not really the problem, however, changing the amount of bits
used for a single slot is going to be... QUoting the author,
going to more than 64bit would be a loss of performance, going
to less than 64bit would be a loss of precision, and using
a struct with a separate tag field would increase memory
usage by at least factor two, due to alignment...
I can very well see why he does not want to make one of
these changes just to make his code run on an arch
it already runs on (through 32bit compatibility).
So I guess the final answer is either we figure out
a preprocessor based patch which makes the necessary
adjustments for 64bit archs, and leaves the code basically
the same for 32bit archs, or we don't package SC for 64-bit archs.
--
CYa,
Mario
Reply to: