Is there any advantage to using pure data on a 64 bit machine (if it works)?
Or does the 64bit just mean more precise calculations?
64 bit simply means that programs are able to address larger blocks of memory. It may also mean more precise numbering if by default ints are 32 or 64 bits instead of 16, but I think thats a compiler thing, not a hardware thing. char=8bits int=16bits float=32 double=64 (I think)
There might in the future be something like write combining where two sets of 32 bit values are combined, as it takes just one cpu cycle to move 64 bits as opposed to two cycles for normal x86 machines. Thats what Im hopeing for. Id really like to be able to do some serious synthsis while doing hardcore realtime video processing using Gem.
I can do one or the other with my old laptop... Just not both. Too many dropouts.
-thewade
On Sep 6, 2004, at 7:38 PM, thewade wrote:
int=16bits
Integers are 32 bits on 32 bit machines. A short would be 16 bits.
Most machines bit depth is determined by the actual size of the
registers used for processing, and most of the time that's only for
integers. Common desktop CPUs have had 64 bit floating point units and
128 bit vector units for some time now.
There might in the future be something like write combining where two sets of 32 bit values are combined, as it takes just one cpu cycle to move 64 bits as opposed to two cycles for normal x86 machines.
By 'move' do you mean process calculations on the CPU? You would be describing SIMD and really bad MMX style SIMD at that. Modern CPUs have 128 bit wide vector units like Altivec and SSE which are fantastic if actually used.
If you mean 'move' as in load into the CPU from a memory location then that's already covered as most CPUs fetch at least 64 bits of data (8 bytes) or more at once. This has both good implications for streaming media like video and not so good implications for pure random access functions like databases.
Thats what Im hopeing for. Id really like to be able to do some serious synthsis while doing hardcore realtime video processing using Gem.
I can do one or the other with my old laptop... Just not both. Too many dropouts.
You need more processors pure and simple. It's just not a realistic expectation to have two completely separate time intensive and sensitive tasks running on the same physical CPU. Dual CPUs or better yet multiple machines solve your problem today.
cgc
hello list! i want to buy a new laptop ... which one do u recommend me for pd??
i was thinking about a pentium m procesor: dell latitude d400 pentium m 1.7 523 ram cache 1 giga?
is it ok?
now i have a pentium 4 , 2.6 and 512 ram, and i feel limited , i cant work very compex patches ..... the salesman told me pentium m is faster than pentium 4 but im not sure
many thanx
siggmus
You might look at a desknote. They don't have batteries, but usually you'll have power around if you're doing audio work. The upside is that they pack a lot more power for much less money. The one I have came without a hard drive, CPU, or RAM. The RAM is cheap because it takes regular fullsize desktop RAM, rather than specialized laptop RAM. Also the CPU is a desktop CPU which means its faster and cheaper. I've heard some of the newer ones sport dual optical drives, fancy video cards and huge LCDs. But they're also very heavy compared to a laptop. Various companies make desknotes, including ECS and Dell.
I bought my desknote 2.5 years ago for $1k US and it has a 1.75 GHz processor and can take up to 1 Gig of memory.
-i
siggmuss wrote:
hello list! i want to buy a new laptop ... which one do u recommend me for pd??
i was thinking about a pentium m procesor: dell latitude d400 pentium m 1.7 523 ram cache 1 giga?
is it ok?
now i have a pentium 4 , 2.6 and 512 ram, and i feel limited , i cant work very compex patches ..... the salesman told me pentium m is faster than pentium 4 but im not sure
many thanx
siggmus
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi siggmuss,
now i have a pentium 4 , 2.6 and 512 ram, and i feel limited , i cant work very compex patches ..... the salesman told me pentium m is faster than pentium 4 but im not sure
2.6 MHz should let yo do just about anything in PD. you might look into the possibility that your P4 processor is giving you trouble with denormal numbers. If you see any strange leaps in CPU usage, it is probably this denormal bug. It is common for P4 processors with all kinds of audio softs, so I would recommend either an Athlon [which I use with my "Polish laptop", a Shuttle X with Athlon XP processor] or a G4 or G5. These days, I only steer people away from Intel processors if they want to do audio. As others here have mentioned, these new Athlon 64 bits are looking interesting, however there is still not a lot of software which takes advantage of them.
best, d.
Chris,
If you're running a dual processor system, to what extent does it depend on the OS, or the Application, in terms of whether a significant performance enhancement is experienced?
Would PD be able to take advantage of the extra performance offered by two processors, on (for example) a dual AMD machine running Linux?
Jamie
-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at] On Behalf Of chris clepper Sent: 07 September 2004 02:11 To: thewade Cc: thelist Subject: Re: [PD] 64 bit PD
On Sep 6, 2004, at 7:38 PM, thewade wrote:
You need more processors pure and simple. It's just not a realistic expectation to have two completely separate time intensive and sensitive tasks running on the same physical CPU. Dual CPUs or better yet multiple machines solve your problem today.
cgc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
By 'move' do you mean process calculations on the CPU? You would be describing SIMD and really bad MMX style SIMD at that. Modern CPUs have 128 bit wide vector units like Altivec and SSE which are fantastic if actually used.
the main question is, what can the compiler actually do with the hardware ... i'm not familiar with the amd64 architecture, but i suppose it's similar to simd instructions ...
- to use them, the memory regions have to be aligned ... otherwise it would not take the optimum of one command move data from memory to registers
- it can only be used if algorithms _can_ be vectorized ... that's not a problem with simple multiplications, but complex algorithms like filters, or interpolation algorithms will not take advantage of that...
- and the compiler will have to know the instructions and _use_ them ... as for now i can say that any compiler i tried (gcc 3.2/3.3, icc) had problems generating the optimal sse instructions ... (this is possibly related to dsp block allocation as it's done in pd at the moment)
that's why i somehow doubt that 64bit processors will bring a huge speedup for dsp algorithms ...
cheers ... tim
On Tue, 7 Sep 2004, Tim Blechmann wrote:
By 'move' do you mean process calculations on the CPU? You would be describing SIMD and really bad MMX style SIMD at that. Modern CPUs have 128 bit wide vector units like Altivec and SSE which are fantastic if actually used.
the main question is, what can the compiler actually do with the hardware ... i'm not familiar with the amd64 architecture, but i suppose it's similar to simd instructions ...
I haven't read much about amd64, but I suppose the major contributions of a "64-bit architecture" are, on average, mainly that sizeof(any *)==8 and that all int64 operations are faster.
SSE/SSE2 (which also could be called MMX3/MMX4) support vector opcodes on registers that are float32[4] each, that is, 128-bit at once; that's available on P3 and K7, so you don't need a K8 for that.
- and the compiler will have to know the instructions and _use_ them ... as for now i can say that any compiler i tried (gcc 3.2/3.3, icc) had problems generating the optimal sse instructions ... (this is possibly related to dsp block allocation as it's done in pd at the moment)
I noticed that with GNU C Library, the malloc() function only guarantees 4-byte alignment, which is why GridFlow-0.8 now uses two pointers in the Grid data structure: one for the pointer that malloc() actually returned, and another that has guaranteed 8-byte alignment (i may also try 16-byte alignment in the future). This means all Grids have to be slightly overallocated but usually that's not a significant amount compared to the size of the Grid.
Mathieu Bouchard http://artengine.ca/matju
I noticed that with GNU C Library, the malloc() function only guarantees 4-byte alignment, which is why GridFlow-0.8 now uses two pointers in the Grid data structure: one for the pointer that malloc() actually returned, and another that has guaranteed 8-byte alignment (i may also try 16-byte alignment in the future). This means all Grids have to be slightly overallocated but usually that's not a significant amount compared to the size of the Grid.
thanks to thomas grill, it's the same with pd's dsp blocks ... anyway, this prevents the compiler from generating optimal code ... so that has to be done by hand ...
cheers ... tim
On Mon, 6 Sep 2004, thewade wrote:
Is there any advantage to using pure data on a 64 bit machine (if it works)?
Or does the 64bit just mean more precise calculations?64 bit simply means that programs are able to address larger blocks of memory. It may also mean more precise numbering if by default ints are 32 or 64 bits instead of 16, but I think thats a compiler thing, not a hardware thing. char=8bits int=16bits float=32 double=64 (I think)
Int is 32 bits, unless you compile for DOS or some kind of old architecture, eg Commodore-64 or DEC PDP-6 ...
You may try it with this very small C program: ------------------8<--------cut-here--------8<------------------ #include <stdio.h> #define z(T) printf("sizeof(%s)=%d\n",#T,sizeof(T)); int main(void){z(char)z(short)z(int)z(long)z(long long) z(float)z(double)z(long double)z(void*)z(wchar_t) return 0;} ------------------8<--------cut-here--------8<------------------
just remove any parts not supported by your compiler, if any.
There might in the future be something like write combining where two sets of 32 bit values are combined, as it takes just one cpu cycle to move 64 bits as opposed to two cycles for normal x86 machines.
This is supported by the P1 and all 586-type machines, and is pretty much _the_ definition of a 586-type machine. Guess why those CPUs had 64-bit busses back then. However they don't use SIMD for that kind of job, they use "superscalar execution", which is about executing two separate instructions at once.
Mathieu Bouchard http://artengine.ca/matju
-
chris clepper -
derek holzer -
Ian Smith-Heisters -
Jamie Bullock -
Mathieu Bouchard -
siggmuss -
thewade -
Tim Blechmann