Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sekim]

Just curious if you have thought about a 64 bit version of MJ yet?

I'm sure this is premature, but it sounds like there may be some chips coming out that will speed up apps, provided they are written to take advantage of 64 bit processors.

If so, do you think it could apply to MJs successor releases? I'm trying to keep an eye on the future here. Personally, I like where you guys are headed. But I think if MJ is to become what I believe you guys are trying to make it, this could be a way to add some serious horsepower. Especially with the way the pc is becoming more integrated with audio, video, imaging, etc.

Any thoughts on this?

[Nikolay]

Let's wait until there are 64 bit PCs.  

Do you know anything about them? ETA?

Nikolay

[sekim]

Not a whole lot. Read some stuff that AMD might be first quarter 2003. Intel shorly after. I know it's a ways off, but was thinking when they get a little more common if you guys were gonna get a test mule and have at it.

If I recall, most will not do much for current generation apps (32bit). And the first will probably be for high end CAD and Maya type stuff. But, the AMD chip supposedly will also be backwards compatible for 32bit programs. Anyway, just a thought.

Thanks,
Mike

[skidoo]

Not a whole lot. Read some stuff that AMD might be first quarter 2003. Intel shorly after. I know it's a ways off, but was thinking when they get a little more common if you guys were gonna get a test mule and have at it.

If I recall, most will not do much for current generation apps (32bit). And the first will probably be for high end CAD and Maya type stuff. But, the AMD chip supposedly will also be backwards compatible for 32bit programs. Anyway, just a thought.

Thanks,
Mike

Hmm. Well, Intel's been shipping a 64-bit processor for some time now. It's called "Itanium." Microsoft released a Win2K Advanced Server version for the Itanium back in July. XP for Itanium should be avalable at the beginning of Q1/03.

[Sergio]

The difference between AMD's upcomming 64-bit processors, code-named Clawhammer (home) and Sledgehammer (server), final names Athlon and Opteron respectively, and Intel's Itanium and Itanium 2 is that the Intel processors have a completely new instruction set that requires a recompile of every program (Itaniums are just for high end servers though).

On the other hand, the "hammers" use what AMD calls "x86-64" (www.x86-64.org), an extension of the x86 used by today's processors, adding 64-bit registers and memory access. That way, they still run 32-bit applications, and can run them concurrently with 64-bit ones.

However, in order to run 64-bit apps you do need a 64-bit operating system. Microsoft has announced they will deploy a x86-64 version of Windows XP, and several linux distros are also going to make x86-64 versions.

It is said that Intel is preparing another 64-bit processir, aimed at the desktop market, that will run 32 and 64 bit apps, much like the hammers. The problem is that if AMD's chips are a huge success then Intel will have to adopt x86-64 for their processor, in order to avoid two competing 64-bit standards (not counting Itanium's own standard), which will mean paying money to AMD to license x86-64. Not likely

About what apps will be ported to 64-bit, well, I'd say that nearly every open-source app will be ported, especially CPU intensive ones like LAME. It would mean a huge gain in performance. Small proprietary programs from small companies will probably be in the front line too, again especially if they are CPU intensive. As to big programs by big companies, they will most likely take some more time, though I think when the giants see the benefits of 64-bit they will deploy 64-bit versions with their next product line.

Media Jukebox should *definetely* make a 64-bit version, as any media application should. It will make the app faster and free up more CPU for other programs (most people listen to music in the background while running other programs). You should check x86-64.org once in a while to see if your code is easily portable

Just my thoughts

[sekim]

Sergio,

Thanks for the clarification. The bit about Intels Itanium II is what I was referring to. I read it in a magazine I have, but can't seem to locate right now. Anyway, I guess your explanation was what I was looking for also. If it would make MJ even more responsive then it is now.

It had occured to me after reading the article that it might help cpu stressers like ripping, encoding and perhaps video and visualizations. I'm sure if large databases were being updated, loaded or anything else it would help this as well.

Thanks again. Now, we got to see if J River is gonna get one to flogg. Hint.  

[Sergio]

Hehe I'm an IT student, so I take a lot of interest in these matters. More than glad to help out  

[xen-uno]

There is no automatic speedup from going 32 to 64 bit as there wasn't going 16 to 32. Two architecturally similar (w/ same clock speed) processors will in fact be faster (as real world results have proven) with the narrower instruction set. The wider sets just allow straight forward memory addressing w/o the resorting to tricks (like address translation/paging done in DOS & early windows). That speeds things up.

If all they do initially is widen the set, with no clock speed changes and no real chip advancements, you'll see a DECREASE in speed running 32/64 bit programs as compared to a straight 32 bit chip.

Xenno

[Sergio]

Xenno, the architecture of the 64 bit Athlons is radically changed compared to the 32 bit ones. It allows for much faster processing than before. What you as is: OK, same architecture, just 32 bit, would it be faster?

Well, possibly, but we must see the CPU as a whole. Now, Athlon 64s are not just optimized for 64 bit. They can outperform any x86 processor in 32 bit. Increasing the instruction set does not necessarily decrease performance. It just needs a bigger microprogammed core in the CPU. I don't know how they do that, maybe transistors, maybe some kind of memory. it just has to be larger to hold the microprogramming for the new instructions. It's made of the same material as before, so it won't be slower.

The architecture is built upon x86 32 bit, so instructions don't have to be translated. They are all there. The registers, for example, are 64-bit. 32-bit instructions only use the lower 32-bit word of the register, while 64-bit ones use the whole of it.

The main advantage comes from using these new 64-bit instrucions. There are "regular" ones, similar to the original x86 32 bit set, though much faster due to the extra register space and pipelines. That's why I'd recommend porting everything to 64-bit, to get the most out of it.

[xen-uno]

Yes, you are right from a processor standpoint. But as soon as you actually run an OS on it, I'll bet it behaves according to my predictions as outlined in my earlier post. Why? Overhead baby.

Your logic is solid but breaks when applied in exactly the same way to the 16/32 bit problem. Everything you mentioned was true then.

Xenno

edit:> Believe me, I'm not slammin'. I look forward to it.
2^32 = 4,294,967,296 is too puny - I want 2^64 = 18,446,744,073,709,551,616 which when converted to hard disk space is 2.3 exabytes (almost enough storage to store all the music files I want in FLAC/Ape format).

[sekim]

xen-uno,

I thought dual processor machines had the same problem. That is, if an app isn't written specifically for dual cpu boxes there would actually be no gain in performance.

Someone with a dual cpu machine confirm this? Or is there more to this?

I'd really like to hear thoughts on this. Might order out a board in the next few weeks. There are several dual cpu boards I have seen that are in the same price range as the P4 unit from Soyo I've got my eye on. However, if they don't boost app speed by more then a few percent it probably will not be worth it.

And as long as this getting general, what OS would you need to take advantage of the duals?

[Scronch]

All they have to do is go to the declaration section of the code and change "bit=32" to "bit=64".

Scronch

[xen-uno]

MachineHead,

If the program is written as a multi-threaded application then it can generally take advantage of a 2nd processor. Examples I know of are MS Office (printing is done on a different thread than the main programs), Rhino/Flamingo (solid modeler/renderer), and Picture Publisher.

Flamingo renders twice as fast on a dual 933MHz PIII as it does on a 700MHz PIII.

The only OS's that can take advantage of a 2nd CPU are the NT/W2k/XP family, Linux, and Unix.

If you run your machine hard with alot of CPU intensive apps, then a dual is the way to go.

Xenno

[dnoyeb]

The fact that printing is done in a seperate thread is due to the OS.  That was the most impact I recognized from windows 3.11 to windows 95 preemptive multistaking environment.  The OS spawns that thread for printing.  You dont need 2 processors to have multiple threads.

2 reasons for multiple threads.  1 = responsiveness. (not going to get a cup of coffee while the document prints ala windows 3.11) 2 = speedup.

All programs will benefit from multiple processors because a multitasking OS will always be doing more than 1 thing.  But you dont want to get a 2nd processor for that.  only get 2 processors when you max the speed of the fastest single processor.  2 processors will never be slower than 1 processor.  Even if the OS has to idle 1 processor (which it never will)


MJ is basically an interface.  Their is no strong need to 64bit a window.  The encoders are

already external programs and if they are compiled to 64bits that should be enough to see

the improvement.  This improvement will of course be subtle.  To make it simple, going to 64 bit is just like getting a faster processor, except this time the programmers have a lot more work to do so you end up paying for a new processor, plus you pay more for the software.

Were really at the point where we should start measuring processor efficiency in work / Watt-Hour.

Of course work is a relative term

[xen-uno]

>>The fact that printing is done in a seperate thread is due to the OS

Not true. Word for example hands the print job to the print que on one thread, and could be repaginating or spell checking on another. Once the job is in the print que then you're correct.

Xenno

[dnoyeb]

Your talking about formatting.  If you consider formatting part of printing then yes.  Otherwise, its not printing till it hits the queue.

Anyway really what I was speaking of was the wait you got in win3.11 versus what happend when they introduced win95.

Its all still due to preemptive multitasking.

[NoCodeUK]

Sorry to burst the bubble but didn't Win 95 not have true premptive multitasking??  I thought that was one of the things that was supposedly good for the home user when the code changed over to the NT line in XP.  And as for multi processors not all the NT/2k/XP line support multi processors.  XP home only supports one processor.

Adam

[Sergio]

I still say that porting any app to 64 bit will make teh app faster and better performing in a 64 bit processor, just for the simple reason that the processor is optmized for 64 bit. That really doesn't need much more explaining. And MJ does use CPU intensive features, it's not just "a window". Visualizations and MP3 analysis (Replay Gain and stuff) are major CPU eaters, in the good sense

There mustn't be a lot of money needed to port the program (unless you're using a totally different compiler), so there would only be benefits to porting to 64 bit. 32 bit users would have a 32 bit version, and 64 bit users would have a 64 bit version. The only downside I see is making two builds instead of one, and having them both for download.

[xen-uno]

>>Visualizations and MP3 analysis (Replay Gain and stuff) are major CPU eaters

True

I said enough on this one.

Xenno

[sekim]

Thanks for the answers. Everyone! Guess I'll have to do some more digging.

Thanks again.

Mike

[dnoyeb]

Sorry to burst the bubble but didn't Win 95 not have true premptive multitasking??  I thought that was one of the things that was supposedly good for the home user when the code changed over to the NT line in XP.  And as for multi processors not all the NT/2k/XP line support multi processors.  XP home only supports one processor.

Adam

You dont need multiple processors to do multitasking.  Wether its truely preemptive or not in win95 I don't remember.  Nevertheless, it is multitasking.  It does handle multiple threads.

2000 is also an NTos.

YEs, I forgot about the visualizations.  They are growing on me.  However, is their a need to speed them up?  Will they use less CPU 'energy' if they are coded in 64bit? I doubt it.  Nevertheless, the point is that someone will have to code it, and somebody has got to pay them.  

When you say its not that hard you sound like a hardware guy.  They always act like software is free  The cost of an 64-bit MJ will certainly be higher.  It will be an exercise that MJ can live without and thus will be a special application considering 99% of MJ users will still be on 32bit oses.

I wouldnt be interested in that at all.  Having to manage 2 seperate code bases has got to cost something.  The price will show in the end product.  I'd prefer to keep the cost down except for those hard core encoders.

[Sergio]

2 separate code bases? If the compiler *really* supports 64 bit, then the most you would have to change between versions is a constant/parameter...

[xen-uno]

>>You dont need multiple processors to do multitasking

No one said that. But if you want 2 threads to be processed concurrently then you need 2 or more processors. Otherwise your just time slicing the threads, since 1 processor can only do 1 thing at a time while it's in control.

>>I said enough on this one

Yeah, right

Xenno