Dual Core PowerMacs Tomorrow

K

kainjow

Registered
Power Macs:
  • Dual Core Single chip G5 2.0ghz
  • Dual Core Dual Processor G5 2.3Ghz
  • Dual ethernet jacks
  • Up to 16GB DDR2 RAM (loaded with 512MB?)
  • Nvidia 6600GT PCI-E with native 30" Cinema Display support
PowerBooks
  • 17" PowerBooks have been dropped to $2499
  • Combo drive option on the 15" will be dropped, while maintaining a $1999 price point for the Superdrive option

They also tease there may be "one more thing", again ;)

Some anonymous user posted this to MacRumors. Unfortunately I can't post a URL, but the Power Mac specs have been "confirmed" by 2 anonymous people :D
 
I thought the DC chips hit 2.5GHz. Was I wrong? In any case, a dual-core 2.3GHz chip ought to handily outperform a single-core 2.7GHz one. That is, for multithreaded processes. As with multiple processors, the extra core is not going to make individual "everyday" processes like web page rendering any faster.

It'd be nice if the new Macs were "just plain faster, period", but hey, I'll take what I can get.

16GB of RAM? *droooooooool*
 
remember that tiger can only use more than 4gb in command line: gui apps can only use 4gb ram. only the 64bit apps (command line only at the moment) can use 4gb+ ram.
 
Why would command-line make a difference in 64-bit compatibility or the amount of RAM they use? I don't understand...

Mathematica, one of the most popular mathematical applications, is a full GUI program and fully supports 64-bit computations (and is a 64-bit application) as well as RAM usage above 4GB.

http://www.wolfram.com/products/mathematica/platforms/

What would happen if I wrote a fully 64-bit "command-line application" that consumed more than 4GB of RAM, then added one GUI "Start" button to it? Would it cease working? Where did you get this information?
 
I'm sure it offloads the 64-bit work to a command line utility and then gets the results.. er something like that ;)

Or it uses non-standard methods of working with 64-bit numbers..
 
There is no difference between a command-line application and a GUI application, with the exception of the GUI. The source code is even the same... unless I'm misunderstanding what you mean by "command-line application".

They're all Unix processes -- one and the same. The fact that one has a GUI and the other doesn't have a GUI doesn't change the fact that the source code is all written in the same languages -- C, C++, Obj-C, etc. I'm just not understanding why adding a GUI would cause the application to not work.

What is a "non-standard" way of working with a 64-bit number? You either have a 64-bit number, or you don't. You could possibly simulate a 64-bit number with two or more 32-bit numbers, but then you'd have two or more 32-bit numbers and your application wouldn't be 64-bit. You add, multiply, divide and subtract them, and that's all you can do to them...
 
I think it's mostly a speed issue. You might want to read this: http://developer.apple.com/macosx/64bit.html
It is important to note that in Tiger, the support for 64-bit programming does not extend throughout the entire set of APIs available on Mac OS X. Most notably, the Cocoa and Carbon GUI application frameworks are not ready for 64-bit programming. In practical terms, this means that the "heavy lifting" of an application that needs 64-bit support can be done by a background process which communicates with a front-end 32-bit GUI process via a variety of mechanisms including IPC and shared memory.
Click to expand...
 
kainjow said:
I think it's mostly a speed issue. You might want to read this: http://developer.apple.com/macosx/64bit.html
Click to expand...
Ah, that makes more sense... thanks for clearing that up!

I had no idea -- I knew all along that Mac OS X was only partly 64-bit, but I didn't realize that none of the GUI elements could support 64-bit.

What I was describing earlier (making a command-line app and slapping a GUI on it) is exactly what they describe in that document... but is probably not the most efficient way of doing things!
 
ElDiabloConCaca said:
They're all Unix processes -- one and the same. The fact that one has a GUI and the other doesn't have a GUI doesn't change the fact that the source code is all written in the same languages -- C, C++, Obj-C, etc. I'm just not understanding why adding a GUI would cause the application to not work.
Click to expand...

64 bit GUI applications are multithreaded; they use two or more processes and utilize interprocess communication techniques. One of the processes is the 32 bit GUI, the others can be instances of a 64 bit backend.

The Cocoa frameworks are compiled 32 bit binaries and therefore can't be linked with 64 bit binaries. I guess that'll change with 10.5 8)
 
i am completely and totally wrong. i retract that statement. i got told that.... i don't know where from, that tiger wasn't true 64bit.
 
No, that's correct -- Tiger is not a fully-implemented 64-bit system, it's just some of the libraries are 64-bit and the rest is still 32-bit code... and you were also right in saying that no GUI application can be fully 64-bit (it has to be a 32-bit GUI on top of 64-bit utilities, and those 64-bit utilities must be called from the GUI and the results passed through communication lines to the 32-bit GUI).
 
Actually I think you have that backwards. Tiger as an OS is a fully implemented 64-bit system, it is just that some of the libraries (like the GUI libraries) are only available in 32 bit versions.

This really is just a pissing contest, my old ultrasparc (running 64 bit Solaris) was running 98.437% 32 bit programs - including the GUI - and nobody claimed that it was not fully 64 bit.
 
You must log in or register to reply here.
Back
Top