Re: How to package SuperCollider (or, whats the deal with multiarch)
[EMAIL PROTECTED] (Lennart Sorensen) writes: On Wed, Dec 14, 2005 at 11:17:30AM +0100, Mario Lang wrote: 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. Some defines that are set differently on different archs might work. I haven't looked at the code long enough to find where this whole thing is defined in the source code. source/headers/lang/PyrSlot.h Once I find it I might consider trying something silly with it. -- Have fun, Mario pgponhXjCXpqj.pgp Description: PGP signature
Re: How to package SuperCollider (or, whats the deal with multiarch)
Anthony DeRobertis [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to package SuperCollider (or, whats the deal with multiarch)
Hi. 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). 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? -- CYa, Mario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to package SuperCollider (or, whats the deal with multiarch)
[EMAIL PROTECTED] (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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Skype?
[EMAIL PROTECTED] (Lennart Sorensen) writes: On Tue, Jul 05, 2005 at 07:24:30AM -0500, John Goerzen wrote: I know this is a bit OT, but can somebody explain to me the allure of Skype when there is a huge SIP community, with soft phones, hard phones, and even the asterisk PBX in Linux? Asterisk PBX is for running real phone systems (not VoIP) over T1/E1 (24/32 voice channels) and analog phone lines. This is just plain wrong. I use Asterisk at home, and all my asterisk installation does is take incoming SIP calls, forward them to my SIP hardware phone, and vice versa. No real telco hardware involved. SO saying it is *not* for VoIP is just wrong. -- CYa, Mario pgpmVBOG2rb3N.pgp Description: PGP signature
Bug#274240: Drop AMD64 from arch list
Package: supercollider Severity: wishlist I just tried supercollider on our company AMD64 box running the unofficial Debian pure64 port. The package is available, but sclang immediately segfaults (after some basic startup msgs). I now found this: http://www.create.ucsb.edu/pipermail/sc-users/2004-September/012951.html which clearly indicates that SC does *not* work on amd64 machines in 64-bit mode, even though the compile works without problems. To avoid confusing amd64 users, it would probably be a good idea to prevent building of supercollider on amd64 somehow. (And if some guru knows an easy solution for the problem described in above link, its proably worth trying to patch sc for Debian-amd64. At least I wanted to replace my personal workstation at home with a AMD64 box soon, but since I do use supercollider a lot, that plan is now no longer very good.) -- Regards, Mario Lang Graz University of Technology mailto:[EMAIL PROTECTED] Department Computing http://www.ZID.TUGraz.at/lang/ Phone: +43 (0) 316 / 873 - 6897
exim4 segfaults when delivering to a smarthost?
Hi. I am seeing the following error in /var/log/exim4/mainlog on our dual Opteron 246 machine for every mail I am trying to send: 2004-08-12 14:51:49 1BvF3c-0001T5-Vd == [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost defer (-1): smtp transport process returned non-zero status 0x000b: terminated by signal 11 dmesg reports: exim4[5649]: segfault at 0010 rip 00457c5b rsp 007fbfffa740 error 4 Has anyone seen this before and knows a solution perhaps? (If it weren't for popcon, I wouldn't even have notice this :-) -- CYa, Mario pgp4w8hGEfhW0.pgp Description: PGP signature
