[cenutrio]

So, I have a TiPB 400 (384MB/ 5,400 rpm 40 GB HD), a snail compared to today's PBs (I have a low student budget, so I'll keep my PB for at least another year, hopefully the G5 rev b will be around the corner).

Yesterday a friend of mine brought her two years old HP laptop (AMD Athlon xp 1.2 GHz, 512 MB, XP system).

Quite a mid-quality system those days and supposedly, faster, much faster, than my 3 1/2 years old TiPB.

She has a clean system, uses Norton antivirus, etc.


So, she wants me to teach her how to use iTunes, handle her music library, and work the Mini iPod and FW card I bought her.

I did encode some CDs to mp3 format.

Very, very disappointed, encoding speed never exceed 6x while my 400 MHz TiPB does 6-7x easy.

Is there any reasons besides the windows iTunes encoding program being penalized by Apple?

I'm also considering defragmentate the HD, etc because the Athlon should be much faster.

[cambro]

You are confusing processor clock speed with processor performance.

Ripping a CD makes heavy use of the vector processing unit (aka altivec or Velocity Engine) of the G4. This can give performance gains equivalent to about 3-4x processor speed (depending on the nature of the task), which makes sense in the situation you outlined.

Apple isn't "penalizing" windows iTunes encoding, but Apple is making it very easy to see why Mhz aren't all that matters.

[cenutrio]

OK, I'm not that naive...

I'm aware of the altivec, the MHz mith and so on, but come on, the athlons were very appreciated by professionals as very cheap and high efficient. This is a 1.2 GHz processor and I have a 400 MHz G4. A good procesor 4 1/2 years ago...may be as fast as a PIII 850 MHz, but not faster.

There must be something else, any ideas?

[cambro]

Originally posted by cenutrio:
400 MHz G4. A good procesor 4 1/2 years ago...may be as fast as a PIII 850 MHz, but not faster.

You just can't say this. The speed with which a task is completed is HIGHLY dependent on what that task is and how it is coded and compiled. Period.

If you do a task that does NOT make use of altivec, then your G4 400 isn't going to be much faster than a 400 Mhz G3. However, if you ARE making use of altivec, then you can effectively take your G4 400 clock speed and multiply it by 3 or 4 to get the "equivalent" speed in comparison to non-altivec processors. In fact, for highly vectorized processes (like mp3 encoding), the G4 can process some serious amounts of data in each clock cycle. That's why Apple could call your computer a portable "supercomputer." It could achieve this arbitarary performance level when excecuting vectorized code.

So, yes, your G4 400 is going to be as fast or faster than a 1.2 Ghz PIII for somethings, like ripping CDs, and it is going to be much slower for other things. It just depends.

We won't even mention what different compilers can do...(and this is a remote possibility in the Windows iTunes thing).

[rglenn]

It could be a slower optical drive, or that the optical drive doesn't have DMA enabled on the PC (which slows things down *dramatically* in my experience)

[RooneyX]

Originally posted by cambro:
You are confusing processor clock speed with processor performance.
.

You're living in the early 90s. That Athlon massacres that G4 but iTunes is simply very badly coded for Windows.

Why is it when an app or game performs badly on a Mac we say badly coded but don't apply the same rules to Windows?

Mac Muhajideen hypocrisy if you ask me. Just remember the days when iTunes used to suck 30-60% of a G4s CPU. It was bad even on Macs at one point.

[cenutrio]

Yeah, optical drive may be responsible. Also my PB HD is much faster than the HP.

I think iTunes is highly optimized for the G4, but not that much in the windows version. This is just my thought.

I can see a speed increase of highly optimized altivec applications up to 1,6-1.9x compared to non-altivec, but not more. I think cambro is way too optimistic.

Still think the windows system is somehow slowed down. I'm using a deframentator, registry medic and adaware tonight to get the system in good shape.

[ManxStef]

I'm with Rooney on this one. I'm afraid this whole 3 to 4 orders of magnitude performance increase is mostly hype, you'll get nowhere near that for average practical operations. Besides, x86 processors have MMX, SSE, SSE2 and 3DNow which are pretty much the same sort of SIMD extensions as the Altivec/Velicity Engine so, assuming the code is written to take advantage of these then the performance will be similar (though the Altivec vector engine does rock compared to the others).

As for the "megahertz myth", hmmmm... there's *some* truth to it when compared against deep-pipeline/high-MHz CPUs such as the P4 but it doesn't hold half as much water against the "wide and shallow" approach of the K7/Athlons. The fact is that Apple stopped using this marketing line as soon as they got hold of the IBM PowerPC 970 because it's actually a decent performing chip; previous to this they were quite worried that Motorola weren't ramping up the speed of the "G4" processors in line with the PC market, primarily 'cause Motorola didn't care too much (with their biggest CPU market by far being embedded devices - not Apple). If you want independent performance comparisons I'd recommend the SPEC website, it's about as unbiased as you'll find. I'd also recommend arstechnica.com for their technical papers comparing CPU architectures (if you're into that sort of thing) - they're pretty unbiased too (in that they're jsut as much fans of Macs as they are of PCs).

The fact is that iTunes is either hamstrung or, more likely, just unoptimised on win32. I've run it on a dual CPU Athlon MP 2400 (2GHz) system with one of the best consumer CD drives available (the LiteOn LTR-52246S, which is one of the very few drives to have 100% accurate C2 error reporting) and it rips CDs at 8-9x max. with CPU usage hanging at 50% across both processors (with CD error correction enabled).

Not that it matters much really - one rips CDs 30 seconds or so faster, nothing to worry about

[Eug Wanker]

I'm with Rooney on this one. I'm afraid this whole 3 to 4 orders of magnitude performance increase is mostly hype, you'll get nowhere near that for average practical operations. Besides, x86 processors have MMX, SSE, SSE2 and 3DNow which are pretty much the same sort of SIMD extensions as the Altivec/Velicity Engine so, assuming the code is written to take advantage of these then the performance will be similar (though the Altivec vector engine does rock compared to the others).

I'm not sure how you would expect that to be true at all. If the code is built around Altivec, it's not correct to assume it would be trivial to port that SIMD code to x86, and expect identical performance, esp. when the port was done quickly. I'd expect them to spend a LOT more time just making sure it worked and CD burning was seamless, etc, than wasting time doing SIMD optimizations. Not to mention the fact that many Windows machines out there wouldn't even have SSE2 anyway.

The fact is that iTunes is either hamstrung

Unlikely.

or, more likely, just unoptimised on win32.

Yup.

I've run it on a dual CPU Athlon MP 2400 (2GHz) system with one of the best consumer CD drives available (the LiteOn LTR-52246S, which is one of the very few drives to have 100% accurate C2 error reporting) and it rips CDs at 8-9x max.

This is a meaningless number unless the settings are exactly the same. With my settings I get something like those speeds, on a Celeron 1.4 GHz with PC100 memory.

[ManxStef]

Originally posted by Eug Wanker:
I'm not sure how you would expect that to be true at all. If the code is built around Altivec, it's not correct to assume it would be trivial to port that SIMD code to x86, and expect identical performance, esp. when the port was done quickly. I'd expect them to spend a LOT more time just making sure it worked and CD burning was seamless, etc, than wasting time doing SIMD optimizations. Not to mention the fact that many Windows machines out there wouldn't even have SSE2 anyway.

Uh, did I say *any* of that?

Like you say, maybe they've just concentrated on getting the basics working, though I'd expect at least a *bit* of optimisation. If any was done I'd expect it to at least use MMX and/or SSE as they'll be available on 90% of the PC market if not more (given the required OS specs of 2000/XP themselves and iTunes needing a P500 or up) and you can always write detection code to fallback if you processor doesn't have the capabilities (though you'd obviously write this first then optimise second). As for porting, they may be using a different codebase and maintaining them in parallel (unlikely due to it requiring a lot of maintenance time), or keeping core parts common and rewriting the main GUI - which seems likely given the COM automation capabilities from the recently released SDK.

This is a meaningless number unless the settings are exactly the same. With my settings I get something like those speeds, on a Celeron 1.4 GHz with PC100 memory.

My point with that was that I'd imagine with a machine of those specs that the process wouldn't be limited by the hardware but rather the code. Sorry I didn't mention the bitrate, I tried it at both 128kbps and 196kbps and the ripping time was pretty much identical.

But yeah, I don't want to get into an argument over this - what it comes down to is that it's a different (be it ported or rewritten) bit of software running on a different platform so performance comparisons aren't a particularly fair benchmark of either system's capabilities.

When it comes to Cenutrio's original premise, that "Powerbooks age much better than PC (laptops)", I'd broadly agree, thanks largely to OS X being such an amazing effort compared to NT 5/5.1 (2000/XP). Linux works better on old hardware compared to NT too but it's still just not there as a desktop OS; athough Mandrake 10, SuSe 9.2, Fedora Core 2/Redhat Desktop, Sun's JAVA Desktop, etc. all show a lot of promise OS X just blows them all away

[cambro]

Direct from Apple's Developer site:

The AltiVec instruction set allows operation on multiple bits within the 128-bit wide registers. This combination of new instructions, operation in parallel on multiple bits, and wider registers, provide speed enhancements of up to 30x on operations that are common in media processing.

For ripping a CD, you can expect a very, very large enhancement due to Altivec because that task is perfect for vectorization. That's all I'm saying.

The Athlon is a fine chip, but if you think MMX and SSE are equally efficient, then you are wrong (Developer page).

Because the original poster used an iTunes benchmark as the basis of comparison, I suspect that much, if not all, of this difference is due to Apple's use of altivec, probably in combination with rather little effort to optimize for other processors.

[RooneyX]

Originally posted by cambro:
Direct from Apple's Developer site:



For ripping a CD, you can expect a very, very large enhancement due to Altivec because that task is perfect for vectorization. That's all I'm saying.

The Athlon is a fine chip, but if you think MMX and SSE are equally efficient, then you are wrong (Developer page).

Because the original poster used an iTunes benchmark as the basis of comparison, I suspect that much, if not all, of this difference is due to Apple's use of altivec, probably in combination with rather little effort to optimize for other processors.

Crap. He's already stated his HD and optical drive are slow.

[cenutrio]

So I used the defragmentator, cleaned the system with the software package I mentioned and so on.

No results, max encoding speed still 6x.

The system did not seem more responsive.

The HD is slow (a 4,200 rpms), the optical dirve is not that bad (a combo, burns at speed 8x, reads at 24x).


ITunes in x86 may not be that optimized (it is version 1.0 pretty much).

Or windows just slows down over time. I don't know.