G5 vs x86 performance question

H

HateEternal

Mac Metal Head
Last night I installed a second seagate 80gb sata drive(same one the G5 ships with) in my Dual 1.8 G5 with 1.25 GB of PC3200. First I made an image of my hard disk with CCC, then booted to the OS X install cd, ran Diskutility, put my 2 drives on RAID 0 and restored the image to that. After I booted I decided to do a little test and raced my PC (1.53 mhz athlon 512mb pc2100, 120GB ATA hd) and my G5 loading Photoshop 7.0. I was supprised when the PC was faster...

This doesnt make any sense to me what so ever, I know this is not that highly scientific of a test, but if you think about it, first of SATA in general should be faster than a IDE drive, second 2 SATA drives in RAID 0 should be faster than an IDE drive, third Dual channel PC3200 ram should be faster than single channel pc2100, and lastly 2 1.8GHz G5's should be faster than one 1.53 Athlon XP (not to mention the huge difference in bus speed).

Can anyone shed some light on why this may be happening? More fonts on the Mac maybe?

I know this is a silly test and if I tried any other tests im sure the G5 would stomp my PC, but this made my jaw drop.

I also know a lot of people say it is not nessesary to defrag your mac, is this really true? Could this be part of the problem? I defrag my PC nightly (whenever its on over night)
 
um. first off. you're benchmarking, using software RAID, right?

try going back to one drive for System, Apps, etc. and use the other for data. software raid isn't a big plus in my opinion.

secondly. it's common knowledge that all Adobe/Macromedia apps are developed a lot more for windows now.
 
Loading times are highly operating system dependent. Who knows what libraries the apps load at startup and if these libraries where already loaded by the system before you launched the app. These are issues that are out of the users hands and is why almost nobody actually measures the startup time of an application as a cross-platform benchmark.
 
Viro said:
Loading times are highly operating system dependent. Who knows what libraries the apps load at startup and if these libraries where already loaded by the system before you launched the app. These are issues that are out of the users hands and is why almost nobody actually measures the startup time of an application as a cross-platform benchmark.
Click to expand...

Thanks, that is the kind of answer I was looking for. Is there anything you don't know Viro?
 
One particular problem with these comparisons is also cultural. Under windows programs tend to first throw up a splash screen and then open a window before it is actually fully loaded. This is considered bad form on the mac where you are supposed to fully load in while the icon bounced in the dock and then display your window.

The mac way is more in sync with the idea of multiple cooperating applications while the windows way is more directed to the model of using a single application at a time.
 
also. load time is normally more of an issue for Windows (whether it be bootup or app loading) as OS X can generally run for much longer without restarting, and apps are less prone to crashing because of an unstable system.
 
lurk said:
One particular problem with these comparisons is also cultural. Under windows programs tend to first throw up a splash screen and then open a window before it is actually fully loaded. This is considered bad form on the mac where you are supposed to fully load in while the icon bounced in the dock and then display your window.

The mac way is more in sync with the idea of multiple cooperating applications while the windows way is more directed to the model of using a single application at a time.
Click to expand...

EDIT: Oh I see what you're saying. The laggy presentation of the main window where you can almost see everything being created as it's loading. Again, it's up to the developer. I've seen and done both: show the main window then create the UI. Or create the main window, create the UI then show it.

Not entirely true. The whole splash screen effect in Windows is completely up to the developer. The binary image is loaded first, along with all hard linked libs, then program is executed. But in many cases, especially with large programs such as Photoshop, the developer may choose to offload big chunks of code into libraries, and load them at runtime rather than hard link them.

So in effect, what they've created is a very slim fast loading executable that quickly loads itself and starts off with a splash screen. Then the "real" program code is loaded dynamically and all the resources are loaded, initialization performed, etc. If instead the developer decided to hard link everything then it may sit there loading everything before it even begins executing code, thus delaying the splash screen.

The same can be done in OSX. I can create a very tiny loader app that shows the splash screen instantly (even while the Dock icon is bouncing) and then load the heavier libs after the fact, the same way described above.

Now where the OSX vs. Windows program loading comes in, OSX automatically displays a bouncing icon, the developer doesn't have to worry about that. That's about it. The end. The only difference is the visual feedback, both OSes do things the same way, and the actual presentation is largely dependent on the developer.
 
Lycander: Yes I did not mean to imply that there was anything but a developer choice. By throwing up a splash window or bouncing the dock icon you provide the user with feedback that something is going on, it is purely psychological.

Another point is that on both the Mac and Windows it is possible to load parts of your program after it starts. So effectively the order of operations is to have a small splash application that then opens the dll or dylib containing the main program and start it running. There are also automatic means to a similar end using incremental dynamic linking on some platforms.

Really what it gets down to is that this makes any measurements of application startup time between platforms totally bogus.
 
You must log in or register to reply here.
Back
Top