XP 64 bits and N

Hi Guys,

anyone is trying?

yep…no problems at all yet…of course I’m running xp that is only 32 bit. nvidia gforce chip set. really not a glitch but haven’t put it to hard use yet. Only had a week or so
Cheers
:cool:

I’m getting excited about XP64. I read several articles on it last night in PcWorld. I’m waiting till the OS & the hardware are ready before I switch but I can’t wait!

MS

thank you guys. I’m excited with xp64 too. Mostly because in my case, the main bottleneck with the plug-ins use is beeing the CPU processing time.

I was runing winxp 64 beta and I did load ntrack on. Seemed to run the same since ntrack has to run in 32 bit mode since it was compiled as that. Luckily m-audio has 63 bit drivers and they worked flawlessly for me (so kudos to them). I’ll be waiting on it… until programs are available to take advantage of it (compile and or programed specifically for the 64 bit architecture) then it would be best to stick with winxp for now.

On a related note I tried a linux distro for AMD64 with jack (low latency audio connectivety) and it seemed to run well. And ardour looks quite interesting (http://ardour.org/index.html) and of course there is always audacity.

Hey Dub,

I can vouch for Ardour/Jackd - It’s awesome - Really cool architecture, Paul Davies did a great job. I’ve been playing with Zynaddsubfx/Alsa Modular synth/Jackd/Rosegarden for a while and getting great results. It can be a little contentious to get it working, but then, it just works. I’m using the stock Debian Testing Distro with 2.4.25 Kernel/Low-Latency patch on an AMD 2800+ 1G Ram. Lots of fun - getting < 5ms latency with jackd midi…

…Now if I could just play worth a hill-o-beans :laugh:

.-=/gp=-.

cool,

I running ubuntu on an athlon 64 (2800) with 768MB ram. I’m planning on doing a reinstall since i’m not happy with my partitions (the ubuntu installer wouldn’t allow me to create logical partitions for some reason and since I already have 3 partitions (2 primary one logical) it wouldn’t let me create more than one! So no swap or anything!. I may have to get out partition magic and fool with my windoze partitions.

I may try debian since that is what the local LUG is using, I’m just not sure of the status on ports for the x86-64 branch (but hey if ubuntu has them then debian testing must). I’ve also had some gentoo guys push me that way (compile time is pretty short on an A64 (extra registers == less swapping to memory)).

Of course for windows ntrack is my choice :D.

Mostly because in my case, the main bottleneck with the plug-ins use is beeing the CPU processing time.

I wouldn't expect much difference in CPU usage of the kind that N and plugins do, using a 64-bit OS (even if they were compiled in 64-bit mode). I could be mistaken because I don't have a lot of the facts. But my understanding is that a 64-bit OS uses 64-bit addresses. And possibly 64-bit long integers for certain API calls. This makes programs that use huge amounts of memory (over 4GB) possible without playing funny addressing tricks. No doubt it also improves the speed of the OS on systems with lots of memory. I'm sure there are other benefits, too.

However, n-Track and plugins do mos of their work in 32-bit floating point numbers. I would expect this kind of processing to be unaffected by whether the OS is 32-bit of 64-bit.

If someone can clue me in to what specific features of a 64-bit system would improve operation of programs like n-Track, I'd be very interested to hear it.

It might actually reduce performance, since OS APIs would usually be carrying around bits of information that aren't needed. Memory usage will be bigger, because all stack push/pop operations probably need to be 8-byte aligned rather than 4-byte (not sure about whether this is the case, though).

Don't expect 64-bit OS to be a win-win situation, where every application benefits ("just add money and everything's faster!") For the "just add money" thing, get a faster CPU and memory (FSB and RAM, as well as more and faster cache). These thingds will give you a clear advantage with no disadvantages other than the price tag.

Since ntrack is not compiled for a 64bit os (xp 64 in this case) there would be no benfit to running a 64 bit processor. At this point the extra adressable ram will not help and the extra registers will not be used since even on a 64bit OS ntrack is 32 bit and will use compatibility mode (kind of like running 16bit binaries on a 32bit system). At this point an althon 64 may be jumping the gun a little unless you are going to run linux, but that won’t help with ntrack.

On a side note though, with the onchip ram controller and the way the bus is handled there is thereoretically a lot more throughput available (especially compared to some of the earlier socket a chipsets).

I am personally a computer geek and want whatever is new, I admit it. If I were recomending a computer it would be a NFORCE 2 chipset running a Barton (i had a 2500 and it perfomed quite comparably to my current a64-2800 in fact a barton 2800 socket A will outperform my a64 (in 32 compat mode) in multiple benchmarks , although iirc the memory bandwidth difference was noticeable).

I’d stay away from the socket A semprons since they are basically the celerons of the AMD world (smaller cache and less performance for the PR rating ie number which some would think is the “speed” of the processor). And don’t get me started on clock speed versus performance… intel is now eating their own dog food on that with their new processors that run a slower clock but outperform previous models. As my computer design teacher said today, “Buy last years’ processor and buy ram, buy lots of ram.”

As my computer design teacher said today, "Buy last years' processor and buy ram, buy lots of ram."

Um, yup. Anymore, the processor is rarely the bottleneck.

I didn’t have the opportunity to read more about Athlon 64 bits architecture but it seems logical to me that, if I´m running a 32 bits application the 64 bits processor can have a behavior like a dual 32 bits processor. Somebody knows if is true?

Sorry, makako – no dice.

<!–QuoteBegin>

Quote
“Buy last years’ processor and buy ram, buy lots of ram.”


My sentiments exactly! Best performance value point, IMHO.

When buying memory, you get two choices:

1) Buy as much RAM as you can afford but using up only half the memory slots, for a cheaper upgrade later
2) Fill the slots and then throw them away (or upgrade your mother-in-law’s memory) a couple years later when you expand

Option 2 is usually cheaper short-term but more expensive long-term. However, sometimes the bigger chips are prohibitively expensive – it depends on where in the memory cycle price curve your purchase falls.

The first family computer I got was 1MB, in 86 (Mac Plus). The rest were Windows laptops:

- 120 MHz 16MB in 95
- 650 MHz 256MB in 2000

So, I suppose we’re due for a 3GHz, 1GB machine this year!
Quote (makako @ Feb. 22 2005,09:03)
I didn't have the opportunity to read more about Athlon 64 bits architecture but it seems logical to me that, if I´m running a 32 bits application the 64 bits processor can have a behavior like a dual 32 bits processor. Somebody knows if is true?

Not really, I think you have the wrong mental model, you are imagining a dual core 32bit with a 64bit pathway i think. A more accurate model would be the relation between the 286 and the 386.

The 286 was a 16bit processor and the 386 was an extension on that which basically stretched the main registers to 32bit. You can take a look at the 386 architecture here.
When used in 16 bit more only half of the general purpose registers are used (they cannot be used as two). This was to facilitate backwards compatibility (so the 16bit binaries would run on the 32 bit processor).

The AMD64 keeps backwards compatibility as well. Of course when it does run 32bit binaries it has many tricks up it's sleeve so it doesn't tell the whole story (advance branch prediction, most likely hidden registers holding values and evaluating them before the call I'm not sure and at this point it really doesn't concern me as a user :laugh: ).

The little tricks (and faster bus) get a athlon64 2800 which only runs at 1.8ghz to run like a 2.08ghz Athlon 2800 (which is comparible to a p4 2.8ghz). Of course now intel is creating "slower" processors that are in fact faster. And by that I mean slower clock speeds but higher amounts of data processed, which has really bitten them in the rectum since they have been pushing the whole we are the fastest by clockspeed and that means speed.

Actually iirc there was some class action suite against intel (or some laptop producer that was using intel chips) that claimed it's laptop/processor was the fastest available at that time. It did in fact have the highest clockspeed, but there was an AMD chip avail at the same time that beat it out on many benchmarks (enough to be considered faster I assume).

Ack I went off the topic again. Anyhow, if it did behave like a dual core then it would need an OS to support that and I would expect much better benchmarks than I can get in 32bit mode.