Any Advantages?
I’m replacing my old PIII System. Are there any noticeable performance improvements of 64-bit processing (or dual core) CPUs when using N-Track? Or, am I just as well off with a 32-bit high-end CPU for less $$$?
Thanks
There are advantages to dual-core and 64-bit chips provided the software takes advantage of threading and increased resources/processing available. I’ve read reviews of tests that run on multi-threaded apps that show real performance boosts. It’s unclear that nTrack is optimized for multi-threading, although just having 2 CPUs will usually make your system run faster in general.
Audio applications tend to be serial by nature, i.e., one input is waiting for the output of another process, therefore they don’t really lend themselves to parallel processing. However, reading tracks from disk is a parallel-type operation that might benefit from MT.
In the 64-bit world, it’s best to wait until there’s a good 64-bit OS, so I’d heard it’s better to wait for MS Longhorn, rather than switch to X64. You want to make sure that all the drivers, etc. that come with the OS are also 64-bit, to get the full advantage.
Having said that, I’ll be offering dual-core and 64-bit DAWs as soon as the price of the CPUs come down.
I always refer people to this paper when discussin MT - Multiprocessing in SONAR 3.1
Multithreading and multiple processors are totally different than a 64 bit processor. A 64 bit processor is fundamentally different in how it does math. Instead of using 32 bit numbers like an x86, it uses 64 bit. They may be backward compatible, but you get 0 advantage running 32 bit apps on a 64 bit processor. SO if you don’t have a 64 bit OS, 64 bit application, and 64 bit processor, you get no advantage. You have to have all three… other wise you payed a lot of money to process in 32 bit.
<!–QuoteBegin>
| Quote |
| …but you get 0 advantage running 32 bit apps on a 64 bit processor |
Not necessarily so - doesn’t the Athlon 64 processor run Windows & Windows apps faster than the 32-bit PIV?
But yes, I agree with you about the 64-bit - that’s what I was saying. But you can get X64 today; I’ve just heard it’s not worth it.
| Quote (Mr Soul @ July 08 2005,16:10) |
| In the 64-bit world, it's best to wait until there's a good 64-bit OS, so I'd heard it's better to wait for MS Longhorn, rather than switch to X64. |
Theres also the risk Longhorn will be even more bloated with useless stuff... current joke is that it'll have lens flares everything you close a window..
| Quote (Bubbagump @ July 08 2005,16:38) |
| Multithreading and multiple processors are totally different than a 64 bit processor. A 64 bit processor is fundamentally different in how it does math. Instead of using 32 bit numbers like an x86, it uses 64 bit. They may be backward compatible, but you get 0 advantage running 32 bit apps on a 64 bit processor. SO if you don’t have a 64 bit OS, 64 bit application, and 64 bit processor, you get no advantage. You have to have all three… other wise you payed a lot of money to process in 32 bit. |
GEez how many times must this question be brought up eh?
A few points you made though, it isn’t fundamentally different, it would be comparable to when processors went from 16bit to 32bit on the x86 platform, longer registers (and more of them, but that is beyond the scope of this discussion, and many aren’t directly accessible to a programmer anyhow). Like any new processor the same basic x86 structure is there (to enable binary compatibility with previous itterations), they just extented the architecture and changed how some stuff if done in the background (which happens in any different itteration of a processor, from thunderbird to barton, or northwood to prescott, lots of stuff changed in the background and some stuff was added MMX SSE3 etc, but the basics are the same on all of them).
Of course you were right that you cannot take advatage of those longer registers w/o a 64 bit os (I run ubuntu on mine for linux), but more importantly (as you pointed out) you need software that was compile as a 64bit target binary. In other words with xp64 ntrack will just be running in 32bit compatibility mode, which will not give a performance penalty, but it won’t improve performance over running it in XP on the same processor. It may be worth asking A about a 64bit vers (I did in Dec he said about a year off or so). I’m assuming if he is doing everything in .NET now it shouldn’t be a problem (since MS brags about .NET’s cross platform abilities), but I have no idea so don’t quote me on it.
So far I have found no software (other than m-audio and nvidia drivers) that have been compiled for 64bit windows. Even linux is some what limited in 64bit apps (although I have ardour, audacity etc and my m-audio card seems to be working fine). So far there isn’t a big enough market (I was too young to remeber if this was the case with 32bit too). We should be seeing changes soon though.
Of course with the price getting pretty low on the processors and their 32bit performance being better at slower speed than their previous 32bit bretheren I would say getting a A64 isn’t a bad idea, since it will future-proof your system and will get good 32bit performance… just don’t bother with the fastest ones yet.
If you do go with a AMD 64 chip just make sure it is a S939 (that refers to the socket and how many pins), not a S754. The last processor for the S754 has already been announced (3800+ or something IIRC) and it will limit your possibilities for cheaply upgradeing in the future. Plus dual core chips will be released (or have been?) for S939, but have not and will not be released for the S754. The S754 will now be limited to the 32bit sempron chips and a few more A64 chips. Plus motherboard prices for the two sockets are pretty much the same, as well as the 64bit processors (ie you won’t be saving money by going with S754).
Although if you want a cheap setup fast semprons are very affordable and the S754 has very nice memory bandwidth. Of course that would mean upgrading your motherboard as well as processor in the future, especially if you want to run beenaLONGtimecomingHORN (reference to the pushed back release dates).
Sorry that was much too confusing. To restate it shortly: If a A64 S939 system is a good buy it’s worth it. You will get equal performance to a 32bit Intel of the same PR spec, and better performance when 64bit applications are available.
Oh, and if it comes with XP you can get a free upgrade to XP64.
I want to thank you all for the information provided. Definitely a lot to consider!
It sounds like I should purchase a 64-bit system that may not be fully useable now but, will become the standard somewhere down the road. Or at a minimum, I should purchase a motherboard that allows me to upgrade to 64-bit/dual-core later when the OS and software catch up.
If you have bux to spare, sure, get the best.
If you want a good value, skip the 64-bit for now. It won’t buy you much except for special applications at this time, and even for the next year or two most likely.
You might get a MOBO that’s compatible with the 64-bit chips and just put a 32-bitter in there for now, and upgrade at some point in the future when there is a benefit.
Which leads to the question: for n-Track, when would there be a benefit?
Well, given that the internal architecture of all plugins is 32-bit floating point math, I doubt that converting to 64 bits would help much for n-Track itself. There would be no point for n-Track to change to using a 64-bit internal architecture until there’s a standard for 64-bit plugins, and a number of plugins that handle it. So, there’s one mark against it.
On the other hand, two possible benefits to 64-bit chips.
One is that since n-Track uses .NET for GUI-related stuff, once we have 64-bit NET support in the OS, then some n-Track code (especially GUI-related stuff) would run much faster on a 64 bit machine. Yet the program itself would still be 32-bit compatible, since that part would be in your OS rather than baked into n-Track.
The other is that plugin manufacturers might start taking advantage of 64-bit architectures, either providing two versions, or else providing versions that can switch automatically between running old and new code, to get lower CPU usage for plugins. You see, while the interface architecture for plugins is 32 bits, the more complex algorithms have to run using 64-bit math for internal calculations to avoid round-off errors and also avoiding extremes of near-infinite/infinitesimals (a real bugbear for DSP coders). So, a 64-bit architecture might not help n-Track directly much, but it might make some plugins run quite a bit faster. Its even quite possible that a 32-bit program would run faster on a 64-bit machine without any special programming – if it uses system routines to do the 64-bit math those system routines would run faster. Not as much faster as it would if the program was compiled for 64-bit mode, of course – in which case it would use machine instructions rather than calling routines. (I think, that is … I don’t know the machine code level details for floating point math and today’s compiler calling conventions so I can’t say with complete authority. But the same kind of thing has happened in the past.)
| Quote (dubbreak @ July 08 2005,21:51) |
| Of course you were right that you cannot take advatage of those longer registers w/o a 64 bit os |
That’s what I meant. Yes, x86 is the same through out. But the point I think we are all after is that if the OS and software aren’t written to take advantage, save the bucks.
As for Linux, I dunno, I see tons of stuff written for 64 bit floating around. As if it weren’t bad enough… now you gotta pay attention to one more thing. It is bad enough with noarch, i386, i686, and Alpha tars… I download the wrong thing half the time as it is when I get sloppy with *, now I get the 64 bit version half the time and have to actually type the whole thing even more than before. Maybe I should just break down and use X and a browser instead of wget…
But Learjeff’s point about .NET may be interesting. It will be something to watch how things behave in a new run time environment assuming the instructions and fucntions don’t change in the run time… like (out of my butt example) datenow() doesn’t have to be datenow64() to work in 64 bit. Microsoft would do something dumb like that.
dubbreak, how are you finding Ubuntu? Any other distros worthy of looking at? I have always kinda stuck in the RedHat, Knoppix, and OpenBSD camps depending on the task. It is always interesting to hear what other distros might have to offer.
| Quote (Bubbagump @ July 09 2005,20:16) |
|
dubbreak, how are you finding Ubuntu? Any other distros worthy of looking at? I have always kinda stuck in the RedHat, Knoppix, and OpenBSD camps depending on the task. It is always interesting to hear what other distros might have to offer. |
I love using kubuntu on my 32bit old laptop (even though debian with fluxbox ran faster). The local lug uses a lot of debian, so running something based off that helps. Plus I love apt-get and synaptic. If I want to install a program all I have to do is type 'apt-get install ardour' or what have you and all dependancies are taken care of. Synaptic is a gui for finding stuff to install and anyone should be able to use it. Oh and there are great guides for beginers such as the ubuntu wiki or ubuntu guide.
I used to use mandrake, but I don't like RPM's, and I've had a few problems with fedora/redhat. I personally think mandrake is the easiest to install for an intermediate user (as easy if not easier than windows). It actually has a decent partitioner, which ubuntu doesn't yet. Ubuntu's is easy if you want to wipe your drive, it is not good for a beginer that wants a dual boot as it doesn't automatically configure a boot manager to include your windows partition (a-la mandrake/mandriva and fedora/redhat).
Ubuntu on my 64bit desktop is ok, but certain packages aren't available (deCSS comes to mind although I haven't checked lately), it all seems stable though.
Gentoo is an interesting one. You need a day or two free to deal with all the compiling though. Some people swear by it though, I may try it end of aug on my laptop to see if I can squeeze a little more speed out of it's aging processor.
I use knoppix as a tool on corrupt computers etc, but I liked it so much I tried an install... that didn't go so well. A lot of stuff was just plain broken and the installer is very limited, it basically just dumps everything on the computer (that was 3.8 though the newest may be different).
I love openBSD for firewalls, PF is very easy to use and it seems to run on even the slowest computers (plus they have lots of support for old network cards).
I've fooled around with slackware, but I wasn't a big fan. zipslack is nice though, only 100mb and you can run it on a FAT partition. It is another cool little tool. Of course #### small linux looks a lot cooler (based off debian like knoppix).
Anyhow this is way off topic so I'll wrap it up. At this point I'd personally recomend ubuntu since it is promising 3 years support for each release for the desktop which is much better than most distros that drop support for old releases once a new one comes out. I'd like to try Mandriva though since conectiva and licoris had some interesting stuff (they were bought by mandrake) and Mandrake was already a good distribution.
Hrm, I have never had major issues with RedHat and yum. I mean, that is all you are doing with apt-get, it’s the Debian yum equivalent. Of course, I don’t run too many left field apps either. It is all pretty much main stream ProFTP/Apache type stuff.
I use Knoppix for recovery stuff too. I don’t care for KDE for most work, so I never cared to try to install it.
As for partitions, well, after installing OpenBSD about 1000 times from scratch, partitioning in Linux from the CLI is nothing. 
I hearing Ubuntu and Mandrake over and over, so I am going to have to give them a whirl. That and SUSE, but I am not paying $100 for a distro… Boy am I a spoiled brat.
I just purchased a new computer for my son - lucky devil. Anyway it’s an HP Pavillon with an AMD Athalon64 3500, 512M ram and a 250G SATA disk. I intentionally went AMD as I have been reading alot of hype about the AMD processor and it’s ability to run multimedia apps more efficiently than the comparable Intel processor. Just like my grandfather always drove Fords I have always used the Intel brand of processors or more likely it the power of advertizing.
Based on the date of the last post to this thread (07/05) the x64bit verson of ntrk had not been released. Fast forward to today and please correct me if I’m wrong but I now have all three key elements to run ntrk in a true x64bit world. Albeit both the OS and ntrk are still beta versions I should be able to create a stable x64bit platform…maybe yes…maybe no…? I am aware that I will have round up all the necessary x64bit drivers before attempting the OS install.
So my question is has anyone sucsessfully accomplished a true x64bit ntrk install now that we have all the required components?
There were some earlier posts to this thread that indicated it would be better just to wait for the official release of the x64 bit OS. I’m sure that if it is possible to do the x64bit Beta OS install that there would be countless “tweaking” hours involved after the fact.
To address another post to this thread as well as the need for speed, I created a benchmark test (.sng) file and ran it on both machines. My current platform that I run ntrk on is a Compaq laptop with a P4 2.4Ghz processor, 512M of ram and a 40G disk. I attempted to ensure that when I ran the file on both machines that there were no other processes/disk activity running…just ntrk. The test file was a stereo .wav and I applied 5 vst effects directly to the strip. I selected what I thought were processor intensive vst effects.
The AMD processor won hands down. The AMD rendered the stereo .wav file 30.43% faster than the INTEL processor. Because of the large performance increase I ran the file 3 more times with a clean reboot between each test and the results stood true. The tests were based on the 32bit version of the OS and ntrk.
So now the question that begs to be answered is what would the performance increase be with a true x64bit ntrk install?
Sorry for being all over the place but if anyone has any comments or suggestion I would greatly appreciate the feedback.
Chris
I’m running Windows 7 on a 64bit machine.
Have been using NTrack since 1998. Every time I install Ntrack for 64bit and try to highlight a section on a track the mouse jumps to another section or highlights multiple tracks. Very frustrating. As soon as I switch to NTrack 32 and edit the same song all is well.
I have no clue why this is. I bought the system for my NTrack recording projects opted for the 64 because usually ‘more is better’.
I’m wondering if anyone else had this problem and what they did to make NTrack 64 work.
Feel free to listen to my last NTrack project on my website:
www.bessiemaeblues.com
Beth K
I think that was a bug a remember on one of the older builds,
it was fixed if memory serves me correct.
thanx for bumping this thread, and oldie but a goodie! 
Quote: (dontcare @ Apr. 21 2014, 12:28 PM)
I think that was a bug a remember on one of the older builds,
it was fixed if memory serves me correct.
thanx for bumping this thread, and oldie but a goodie!
Is that 64 bit registered or unregistered memory?
The advantage of 64 bit OS, drivers, software, and fast hard drive is you can use an insane number of tracks and your pc won't choke on them.
I have all of them and on my quad thread CPU I can run the demanding OzoneIII plugin and it uses about 4% less CPU cycles prodcucing much less choppy audio output.