[PD] 64 bits of a/v pleasure?

thewade pdman at aproximation.org
Thu Dec 25 01:31:22 CET 2003

> > hello,
> > Sorry if this has been asked before.
> > Are there plans to write an optomized version of PD for the new 64 bit
> > desktops/laptops? (G5/AMD 64 FX)
> What\'s the reason to go 64 bit with Pd?  Do you need more than 4GB per
> process?  Otherwise the 64 bit version of Pd would most likely be a bit slower
> than the 32 bit due to the additional overhead of 64 bit pointers (it\'s minor
> but still there).

HyperTransport: A high-speed bus without detours

Unlike all Intel CPUs, which communicate with the Northbridge via a regular parallel FSB, AMD\'s Hammer relies on a HyperTransport interface. The serial interface with a variable bitrate allows the SledgeHammer to attain a data transfer rate of 3.2 GB/s - in both directions simultaneously. This results in a total bandwidth of 6.4 GB/s. By comparison, the Pentium 4 with 533 MHz FSB allows a maximum data throughput of 3.97 GB/s - but not in both directions simultaneously. The bandwidth of the serial interface is designed to be flexible. AMD gives the server version of the Hammer three HyperTransport ports. The entire data traffic of the Hammer processor runs through the HyperTransport interface and the integrated memory controller. In order to let the neighboring CPU gain direct access to its system memory, the Hammer uses the XBAR switch. For commands and addresses, the XBAR switch has further 64-bit buses available.

I thought that the processor could move more per cycle, like the difference between the 486 sx and dx.

> Also, neither the PPC 970 or AMD FX are available for laptops and probably
> won\'t be for quite some time.

I hear summer 04 for the G5 laptop, and there already is a AMD64 laptop (just not FX). Alienware wont say when they\'ll make a FX laptop...

> > The scoop at tomshardware maked amd look really good, in 64 bit mode,
> > and I know there are writeins for linux 2.6 on AMD 64FX...
> Really?  It made Quake faster? ;)


> Toms and anandtech usually have a pretty limited selection of mostly synthetic
> bemchmarks that have little to no relvance to Pd and real-time audio and 
> video.

Granted. Perhaps someone should ask them...

> > Any thoughs, as I have had a hard time getting video processing and
> > audio synthsis running in realtime on the same laptop (or at all with
> > some packages that use libquicktime and ffmpeg, \\\'cause thoes two
> > fight)? This could be the answer.
> 64 bit won\'t help you there at all - having libs that are decently coded will
> though.  However, I have been compiling GEM for the G5 since September, and
> have tested the changes on occasion.  Nothing about the 64 bit nature of this
> chip helps the performance, but the massive bandwidth really makes the Altivec
> and GL fly.

I find it hard to believe that the ability to move twice as much information in one pass wouldnt help the ability to create and redraw the screen, and build an audio sample in shorter time. Doesnt the ability to move 64 bits into a register and perform manipulations to each set of 32 bits whilst there, improve on moving 32 bits into registers, processing, moving out, moving another 32 bits in, processing, moving out?


More information about the Pd-list mailing list