/ Will my AMD64 laptop run PD and other sound apps (using mingo's RT
/>>/ patched kernels) faster in native 64-bit linux or faster as a />>/ conventional 32-bit linux? />
amd64 has a number of general-purpose registers that are not available in 32-bit mode, which means code compiled for 64bit will be faster regardless of whether it was specially optimized for 64bit, or uses >4gb of ram..the charts i saw at anandtech put it at around 10-25%..
If that is the case (and I believe it is) will some PD code guru PLEASE get arrays to behave correctly in 64-bit PD? I don't see this problem ever going away, will it? At least without a code fix?
I dont know enough about code to find out myself, but dont arrays have callbacks? Wouldnt it be a simple as changing the typedef for the elements of an array, and any programm accessing $0-array would use this callback? When externals are compiled they could look at pd.h to see the size of data arrays return, and deal with them appropriately... I know the worst ammount - a little bit. Sorry...
Its just sad that I cant use my 64-bit machine in 64-bit mode.
Thanks! -thewade
On Tue, 23 Aug 2005, thewade wrote:
If that is the case (and I believe it is) will some PD code guru PLEASE get arrays to behave correctly in 64-bit PD? I don't see this problem ever going away, will it? At least without a code fix?
From the last pd-dev meeting on IRC.freenode.net #dataflow :
gige> one related topic is the 64 bit problem with arrays, or is this
already fixed
matju> gige: it's related and afaik not fixed
msp> fixed...? I don't know what to do about it at all.
msp> ... Oh you mean the bugs. I thought you meant the deeper problem...
gige> i think its not really bugs, its deeper
matju> msp: the bugs ARE the deeper problem too
matju> msp: unless we're talking about other bugs ?
msp> I don't know how to fix the bugs until I get a 64 bit machine (RSN).
msp> Deeper problem is, do we really want "array" and "table" to be 64
bit?
matju> msp: you need to distinguish between float arrays and word arrays.
matju> msp: ... which is part of the same problem as for pd video.
msp> Correct. At the moment, they are word arrays. Perhaps float should
be an option on the same level as RGBA 8-bit, etc.
msp> There will be complaints for years, of course, if I don't somehow
figure out how to make it coherent and extensible.
msp> ... and of course, the "correct" way is to make Pd itself polymorphic
WRT data type.
matju> msp: just add a type tag just like GridFlow does with its grids
matju> msp: GridFlow's got types: uint8 int16 int32 int64 float32 float64
msp> Yep. The threshold I'm afraid to cross is letting the data types
work outside the "table/array" object.
matju> msp: what do you mean "outside"?
msp> For instance, having to rewrite "+" to handle n data types.
msp> That might preferably wait for whatever succeeds Pd.
msp> (Of course you can make that argument for _any_ proposed extension :)
matju> msp: your problem with Athlon64 is that sizeof(t_word) !=
sizeof(t_float) because sizeof(void*)==8. well you have exactly the same
problem on Itanium, Alpha, MIPS64, UltraSparc, and almost all other 64-bit
archs
And then it drifted towards discussion of polymorphism.
But then it had drifted from discussion of Miller's own video system (I mean separate from GEM, PDP, GridFlow, FrameStein and Mapod)
I dont know enough about code to find out myself, but dont arrays have callbacks?
I don't think I know the thing that you call a callback.
Wouldnt it be a simple as changing the typedef for the elements of an array,
No, because there are other kinds of arrays that don't use floats, but instead use symbols and pointers, which are 64-bit on an AMD64, while regular floats are 32-bit. (There are 64-bit floats, but Pd doesn't use them). And then there is a lot of code that supposes an array is made from t_words, and a t_word is an "union" of float,symbol,pointer, so its size is the size of the greatest possibility.
Its just sad that I cant use my 64-bit machine in 64-bit mode.
You're not the only one to be sad. Fortunately, I have a solution for you! Just give me an Athlon64 desktop computer and I will fix the problem. :-)
My address is:
Mathieu Bouchard 8257, Saint-Denis Montréal, QC Canada H2P 2G7
Alternately, you can send me a large enough donation. The exchange rate is currently 1.19742 CAD/USD.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
Mathieu Bouchard -
thewade