![](https://secure.gravatar.com/avatar/6fbc8a1ceb420881e418236caaca2643.jpg?s=120&d=mm&r=g)
Hi everyone, seeking to improve my ChucK setup's performance (and learning some more about the VM internals) I spent part of my weekend trying to get ChucK to compile as a 64-bit application. First I reapplied Steven Sinclair's patch posted some years ago on this list (fixing some other stuff along the way). Then I hacked together a fix for Chuck_Array usage. The patches are based on ChucK 1.3.0.2 and a Jack-support patch by me. I can elaborate on the Jack-patch as well as I think it's quite useful... Can rebase the patches on SVN trunk if necessary. I could also host my fork on Github if that helps. I was only testing with linux-jack and never experienced the realtime audio issues Steven initially described. Tested with some ChucK examples and the ChucK setup I'm working on. Most stuff appears to be working. The performance increase I achieved is significant! Some notes: * I don't like the way how integers must be machine-word-sized (yet alone because of frequent pointer-to-int casting). It'd better if the ChucK-internal datatypes are decoupled from the machine-word-size. When 64-bit support will be adopted people will run both 32-bit and 64-bit versions of ChucK. For the sake of ChucK script portability it would be nice if ChucK scripts ran with the same integer size on every machine. It should at least be possible to build a 32-bit ChucK using 64-bit ints or a 64-bit ChucK using 32-bit ints respectively. * The array patch is a hack really. I tried to fix the issue by turning Chuck_Array4 into a class for 1-word Chuck values, Chuck_Array8 for 2-word ChucK values, etc. This turned out to be a bad idea - because sometimes the array's actual C++ type matters and because sometimes a Chuck_Array e.g. for floats is used but the necessary Chuck_Array* type is machine-dependent (2-word floats vs. 1-word floats). Also, I find the Chuck_Array* implementation largely redundant and unnecessarily complex. I will try to revise Chuck_Array as a parameterized class that can be instantiated for every ChucK type. This should be much better. * Will also try to fix some array-related bugs in the process (bugs that also exist on 32-bit ChucK of course) Any thoughts, ideas, remarks? Please test the patches and send me ChucK test cases that cause trouble (but don't on 32-bit ChucK). I hope that these changes can go upstream soon after I got above issues resolved. Best regards, Robin