Intel iMac, quartz beam synchronization and xbench

[plinden]

First, let me state that I'm one of those who's dismissive of synthetic benchmarks, more interested in how a computer works in real life. But one of the disappointments with the Intel iMac was the lower than expected xbench results, especially considering the better than expected xbench results from the Intel developer systems.

So while reading arstechnica, I recently came across a reference to this on macintouch: http://www.macintouch.com/readerreports/imacintel/topic2074.html :

The XBench scores are not directly comparable. The PPC binary portion of XBench 1.2 was compiled on 10.3, while the Intel binary portion of XBench 1.2 was compiled on 10.4. This means that the Intel code is running into the coalesced update limitations. See http://developer.apple.com/technotes/tn2005/tn2133.html for more information.

You can perform an "even" test between the PPC and Intel systems by disabling Coalesced Updates on the Intel iMac before running Xbench. Open "/Developer/Applications/Performance Tools/Quartz Debug.app", choose "Tools -> Show Beam Sync Tools" and choose "Disable Beam Synchronization". (You can do this on the PPC mac, but I don't expect it to make a difference).

I decided to try this out, downloaded xbench, and got the results in the attachment. To summarize, with beam synchronization enabled, my results were pretty close to what others get. Comparing with xbench after disabling beam sync, most results were close enough to being identical, but the Quartz graphics test went from 65.45 to 116.78, and the UI test went from 21.22 to 244.92. My overall score almost doubled from 54.94 to 90.38.

Now, like I said, I'm not interested in the synthetic benchmarks, and I'm not going to permanently disable "beam synchronization" (whatever that is) just for bragging rights, but does anyone have any insight into what this means for the UI? Does this "even up" the comparison, or is this just adding a new synthetic parameter?

Anyway, although I'm not interested in the actual figures I get from xbench, any ideas on how to increase the Random Uncached Write figure?

 

[jared_kipe]

Awesome, Let me try....

EDIT: Where the hell is that, can it be done by terminal?

 

[plinden]

Awesome, Let me try....

EDIT: Where the hell is that, can it be done by terminal?

You need to install xcode from the installation DVD, then you can access it from Finder, <your HD>/Developer/Applications/Performance Tools/Quartz Debug. Enter Command-B and disable Beam Sync

 

[mkrishnan]

So does anyone know what beam synchronization actually *is*?

 

[stoid]

So does anyone know what beam synchronization actually *is*?

I thought that had something to do with quantum mechanics... Has Apple jumped too far ahead of their time again?

 

[plinden]

So does anyone know what beam synchronization actually *is*?

I'm hoping someone can answer that, but I've read over the Apple tech note referenced in the quote a few times and let it sink in. One part says:

How does this affect applications?

The majority of applications gain the benefit of coalesced updates, however, there are some situations where it can cause performance regressions. Regressions tend to fall into two categories:

* Over-flushing: Applications which draw and flush much faster than the display refresh are throttled down to the refresh rate. Ideally, applications should not draw faster than the display refresh as it would be wasting time drawing pixels the user won't see on the display. Once a window has been drawn into and flushed the buffer needs to be locked in preparation for window server access, so an application can do anything it likes until that flush makes it to the screen except draw into the buffer again. If an application tries to draw immediately after a flush it will block until that flush actually completes, so if the application just misses a frame sync it has to wait around until the next one, and won't be able to start drawing the next frame in the meantime.

* Extended Drawing Interval: If an animation spends more time in its drawing routine than it takes for the screen to refresh, then it will become throttled to some factor of the refresh rate. So, if the refresh rate was 60 fps and the animation can run at at most 55 fps, it will be throttled down to 30 fps.

I'm guessing, on no evidence, that xbench is affected by the first item, ie. it is trying too hard to draw and flush the display.

 

[jared_kipe]

Beam sync has to do with how closely the operating system monitors how the screen changes. The only side effects to turning it off is MAYBE some tearing, and video artifacts with video clips. Most people don't see anything when they turn it off. I don't know if it really affects real world speed either though, but it sure helps the open GL tests. I think Xbench just needs to be coded a little better.

EDIT: I'm pretty sure its also called Vsync for PC terms.

 

[plinden]

One more idea just occurred to me ... would this affect frame rates in Mac OS X optimized games, like Quake 3, where you would expect a couple hundred fps?

 

[jared_kipe]

I thought that had something to do with quantum mechanics... Has Apple jumped too far ahead of their time again?

if it had to do with quantum mechanics it would look something like <beam|sync|beam>

 

[mkrishnan]

I thought that had something to do with quantum mechanics... Has Apple jumped too far ahead of their time again?

If Macs start using flux capacitors or get unlicensed portable nuclear power generators strapped to their backs, I'm so getting a Dell.

EDIT: Jared...ROFL...that cracked me up.

 

[jared_kipe]

If Macs start using flux capacitors or get unlicensed portable nuclear power generators strapped to their backs, I'm so getting a Dell.

EDIT: Jared...ROFL...that cracked me up.

Thanks, didn't think many people would really dig the Dirac.

And hell yes, if apple releases a fusion reactor with the next round of powermacs that can power my house. Say hello to my credit card.

 

[munkees]

I noticed on the CPU test with the intel CD 2.0 Ghz it not getting all what it should, is the xbench setup to test dual cores? how would this run on a quad ?

 

[plinden]

I noticed on the CPU test with the intel CD 2.0 Ghz it not getting all what it should, is the xbench setup to test dual cores? how would this run on a quad ?

What do you get and what do you expect?

I don't think xBench is very transparent about how it calculates these values, but apparently "baseline", ie. values of 100, is based on a dual G5 @ 2GHz.

Their calculations can't be just averages of the values they get, otherwise my Disk Test/Random would be 68.11 whereas it's 25.82

 

[Heb1228]

So does anyone know what beam synchronization actually *is*?

Hey! I remember... you know, from Ghostbusters? Don't cross beams or you get the end of the universe or something? Or the stay-puff mashmellow man explodes... one of the two.

 

[Makosuke]

Beam sync has to do with how closely the operating system monitors how the screen changes. The only side effects to turning it off is MAYBE some tearing, and video artifacts with video clips.

Not *maybe* some tearing, on my G5 when I switched from a CRT to an LCD (10.3, which didn't have Beam Sync) there was tearing all over the place. Not that it was a big deal, but every time I drug a window or played a video with decent framerate, it would cause noticible tearing. Most 3D games, of course, enable beam sync, so those were no problem.

When I upgraded to 10.4, the difference was noticible within the first minute. As far as I'm concerned, systemwide beam sync was the best single new feature in Tiger. According to that tech note it MIGHT cause some speed issues with redraws in certain apps, but I've never seen one--far more likely to just affect synthetic benchmarks like XBench.

Frankly, now that LCDs are pretty much everywhere, NOT having beam sync systemwide is just plain silly. Fire up Quartz Debug, turn it off, and then drag a large window on any LCD--you'll see what it does immediately.

EDIT: Woah! I just noticed that every post in this thread but the last was from February... guess this reply wasn't exactly necessary anymore.