Geekbench 6 is now a thing

[Nycturne]

I was able to try opening this doc in Word for Windows by remoting into an old Windows PC with the following specs, and it took 28 seconds. This suggests that Word for Windows might have somewhat better performance than Word for Mac on this task, since an i9-9900K should be more than ≈17% faster (according to their GB6 SC scores, it's 30% faster). To directly test it I'd need to install Bootcamp on my iMac.

Though this may not be the best task to use to compare Office for Mac with Office for Windows. I find more interactive Office tasks, like switching tabs in Excel, are even more responsive on this old PC than on my newer iMac. And when a program is more responsive on an i5-6600K PC than it is on an i9-9900K iMac, that does tell you it's significantly better optimized for Windows than for MacOS.

So the one thing I’ll caution on is that while this gives you a holistic view of a stage in a workflow, it doesn’t give much insight as to what’s going on under the hood, or “how optimized” it ultimately is. As I’ve tried to point out before, system libraries do play a part here. For interactivity, CoreAnimation vs DirectX is one factor, as is the difference in how Apple handles event loop messaging. For the core engine, I’d not expect much difference beyond the differences with the compilers used (clang vs msvc). For parts that interact with the platform, there will be differences, and there will be a number of reasons why, some from the platform itself.

I honestly wish I could go into more detail, but there’s a couple reasons I can’t, although one reason why is because it’s a hugely complex app and I’d be here all day if I really got into the nuts and bolts.

I remember reading of a thing called ZWrite that, I think, had the right idea. My understanding of it was it gave you a bunch of kerouacs to compose the elements of your thingy and you told it how to assemble them into a document. It seems like a profoundly sensible idea: most long documents are a bunch of parts put together, and it would be much easier to work on the part you need to change than to scroll through a long document to find that part. And, of course, a kerouac would be unpaged (the writer was famous for feeding a roll of paper into his typewriter and just pounding away at it), so pagination would only matter when you were finishing up.

Office being built entirely on the promise of “WYSIWYG” kinda hurls that out the window. That said, I personally prefer an approache like what you describe for my own writing. Word wasn’t ever really built for the sort of high end of document sizes that folks throw at it, but it’s held onto many of those ancient assumptions from decades ago.

 

[Yoused]

I was envisioning something similar to the old HyperCard concept. You would have a heap of source pages that each expand at their own rate, containing text blocks, spreadsheet frames, graphics, even records stacks, and you map the content into a final document when you need to, tweaking the pagination behavior to make stuff fit right.

The records stacks word be the killer feature. The one huge thing Office and its competition lacks is good DB capability. Too many times have I seen xcl used as a database, which is a really bad fit for real utility.

And as for scripting, imagine being able to recruit ML to make it that much easier for the muggles and the boffins alike.


(umm, pardon the hijack)

 

[theorist9]

So the one thing I’ll caution on is that while this gives you a holistic view of a stage in a workflow, it doesn’t give much insight as to what’s going on under the hood, or “how optimized” it ultimately is. As I’ve tried to point out before, system libraries do play a part here. For interactivity, CoreAnimation vs DirectX is one factor, as is the difference in how Apple handles event loop messaging. For the core engine, I’d not expect much difference beyond the differences with the compilers used (clang vs msvc). For parts that interact with the platform, there will be differences, and there will be a number of reasons why, some from the platform itself.

I honestly wish I could go into more detail, but there’s a couple reasons I can’t, although one reason why is because it’s a hugely complex app and I’d be here all day if I really got into the nuts and bolts.

It sounds like you're saying that the higher performance I see for the Windows (vs Mac) version of MS Office could be due to various platform-dependent characteristics that are external to MS Office itself—such as the relative performance (or suitability) of Windows vs. Mac system libraries, and other characteristics of the platform that in turn affect the performance of the app.

[It appears there is something analogous going on with Mathematica, where the AS version has lost access to Intel's very fast Math Kernel Library (though in that case it's because of the change to a different processor rather than an different OS, since that library is equally available to Windows and MacOS Intel machines).]

I was focused on the extent to which MS had better optimized Office to work with Windows, but what you're saying is about the other half, namely that Windows is better optimized (than MacOS) to work with Office. It makes sense that MS co-developed Office and Windows to run as well as possible with each other, and that this synergy is better developed than that between MacOS and Office. Office is probably the single most commercially important aftermarket program for the Mac (when it comes to the Mac's product share). Thus I assume there is extrensive communication between MS's Office team and Apple, such that, if the MS Office team told Apple that they could get much better performance if they did "X" to Mac OS, that's something the MacOS developers would seriously consider. But the co-development surely isn't at the level it is within MS between Windows and Office.

 

[Cmaier]

I was envisioning something similar to the old HyperCard concept. You would have a heap of source pages that each expand at their own rate, containing text blocks, spreadsheet frames, graphics, even records stacks, and you map the content into a final document when you need to, tweaking the pagination behavior to make stuff fit right.

The records stacks word be the killer feature. The one huge thing Office and its competition lacks is good DB capability. Too many times have I seen xcl used as a database, which is a really bad fit for real utility.

And as for scripting, imagine being able to recruit ML to make it that much easier for the muggles and the boffins alike.


(umm, pardon the hijack)

That reminds me - whatever happened to Microsoft Access? That still a thing? I remember coding for that thing for a project for my landlord many years ago.

 

[Yoused]

That reminds me - whatever happened to Microsoft Access? That still a thing? I remember coding for that thing for a project for my landlord many years ago.

The only time I ever actually wrote code for someone else, it was to take an indexed database file and recompose it for printing out in columns on a line printer. I felt that it should have heading letters for alphabetical group starts (further complicating the task) but the client said just put in blank space breaks. It was scripted for dBaseII, an app Microsoft later bought, turned into, IIRC, Foxbase, and probably eventually folded into Access.

 

[Cmaier]

The only time I ever actually wrote code for someone else, it was to take an indexed database file and recompose it for printing out in columns on a line printer. I felt that it should have heading letters for alphabetical group starts (further complicating the task) but the client said just put in blank space breaks. It was scripted for dBaseII, an app Microsoft later bought, turned into, IIRC, Foxbase, and probably eventually folded into Access.

I also coded dBase II professionally for Witco, an oil company, as a teenager. Summer job. I can’t remember what the code did.

 

[exoticspice1]

It sounds like you're saying that the higher performance I see for the Windows (vs Mac) version of MS Office could be due to various platform-dependent characteristics that are external to MS Office itself—such as the relative performance (or suitability) of Windows vs. Mac system libraries, and other characteristics of the platform that in turn affect the performance of the app.

[It appears there is something analogous going on with Mathematica, where the AS version has lost access to Intel's very fast Math Kernel Library (though in that case it's because of the change to a different processor rather than an different OS, since that library is equally available to Windows and MacOS Intel machines).]

I was focused on the extent to which MS had better optimized Office to work with Windows, but what you're saying is about the other half, namely that Windows is better optimized (than MacOS) to work with Office. It makes sense that MS co-developed Office and Windows to run as well as possible with each other, and that this synergy is better developed than that between MacOS and Office. Office is probably the single most commercially important aftermarket program for the Mac (when it comes to the Mac's product share). Thus I assume there is extrensive communication between MS's Office team and Apple, such that, if the MS Office team told Apple that they could get much better performance if they did "X" to Mac OS, that's something the MacOS developers would seriously consider. But the co-development surely isn't at the level it is within MS between Windows and Office.

you really gotta try Office on Mac with M2 Pro/Max. WAY better than a 9th gen Intel Mac. Single core matters

 

[theorist9]

Returning to GB, Primate has replaced its GB5 scores with GB6.

Here's how the Metal scaling for GB5 and GB6 compare on the M1 range. Primate gives only one GB score for each level of chip, except the M1 & M2, where they give two. I've chosen the higher value for each M# chip, and assumed all Primate's scores are for the max-binned models, and that the GPU core counts are thus 8/16/32/64.

I recall someone reported Andrei Frumusanu saying (on Anandtech) that GB5's compute tasks were too bursty to properly load those AS machines with higher core counts, which partly accounted for their poor scaling on this benchmark. If so, that issue hasn't been resolved in GB6:

Processor Benchmarks - Geekbench

browser.geekbench.com

Mac Benchmarks - Geekbench

Metal Benchmarks - Geekbench

 

[ArgoDuck]

That reminds me - whatever happened to Microsoft Access? That still a thing? I remember coding for that thing for a project for my landlord many years ago.

It is still a thing, or was as of a few years ago. Its support of SQL sucked. The performance of its underlying (“JET”) engine wasn’t bad

Its interoperability with the rest of MS Office made some nice things possible, like automated production of emails, Word and Excel documents In response to data red lines or to automate standard reporting. But basically I hated working with it

 

[dada_dave]

Returning to GB, Primate has replaced its GB5 scores with GB6.

Here's how the Metal scaling for GB5 and GB6 compare on the M1 range:
View attachment 21972

Processor Benchmarks - Geekbench

browser.geekbench.com

Mac Benchmarks - Geekbench

Metal Benchmarks - Geekbench

Still not great … interesting

 

[theorist9]

Here I've added Primate's GB6 Metal scores for the M2 chips (and removed the M1 Ultra scores, since there's M2 Ultra yet). As explained above, in all cases I've assumed the scores are for to the max-binned model, and assigned GPU core nos. corresponding to this. Hence the core counts used for the M1-series and M2-series are 8/16/32 and 10/19/38, respectively.

Here I've renormalized the GB6 M2 series' scores (in red) so that they start on the perfect scaling line, to facilitate scaling comparison with the M1 series' scores. We can see that, in GB6 Metal, the M2 series doesn't scale as well as the M1 series (in orange). This could be partly due to the M2's having more GPU cores than the M1's, which makes scaling more challenging.

 

[KingOfPain]

Office is, AIUI, a hack upgraded with a kludge with a bunch of features held on by straight pins (I read that it is, or at least was, full of ***triple-indirect pointers). That people continue to use it is a testament to the power of the MSRDF, alongside their intense marketplace shennanigans.

Not to mention, "slow" is compounded with "stop helping me!"

There is this old joke that Microsoft wanted to call it "Text", but then noticed it doesn't handle longer texts very well, so they went with "Word" instead.

As for the "helping":
Once, I had the audacity to make one word in a table bold to emphasize it. I guess Word must have thought: That's the same style that I use for headers, so it must be a header and I'll put a reference to it in the table of contents!
As far as I can remember I couldn't figure out how to convice Word that this single word in a table isn't actually a header. I had to perform an undo and emphasize the word in a different way.
I hate software that "thinks" it's more intelligent than me, because most of the time it just isn't true. Maybe it'll get better when I get dumber with age...

 

[Nycturne]

It sounds like you're saying that the higher performance I see for the Windows (vs Mac) version of MS Office could be due to various platform-dependent characteristics that are external to MS Office itself—such as the relative performance (or suitability) of Windows vs. Mac system libraries, and other characteristics of the platform that in turn affect the performance of the app.

To an extent. Part of it is that Windows and macOS have different philosophies for development. I’ve always likened Microsoft APIs to Lego blocks. You get everything you need to do the task, but some assembly is required. Apple on the other hand thinks about scenarios, but wants to funnel you into their libraries and flows for the most benefit. So Apple APIs have a tendency to be higher level than their equivalents on Windows. You can get really good perf from Apple’s libraries with less work, but it tends to make cross-platform development more complex if libraries don’t exist at the same level on Windows. It can be akin to OpenGL vs Metal/DirectX. An app that has a lot of its own scaffolding to account for lower level APIs doesn't always mesh well with higher level APIs. This mismatch I believe is a reason why Apple went hard and fast with Metal as a replacement for OpenGL and OpenCL. It brought those APIs to where developers were moving to on other platforms, and enabled better performance as a result.

What I'm about to say doesn't necessarily apply to Office. Again, this is a hugely complicated suite with a lot of interacting parts. Measuring and attacking performance issues on software this big is a complex effort and every time I've done it, I've learned something new and weird about Apple's platform. However, I want to give an example of where differences can apply when it comes to rendering text (something hugely important to an app like Word or Pages).

DirectWrite has some rather useful aspects to it that help in situations that allow for efficient drawing of glyphs to a D2D surface. CoreText serves a similar role on Apple platforms, but is tied to CoreGraphics rather than say, Metal or CoreAnimation which is where GPU acceleration comes into play. CoreGraphics, while it does play nice with hardware acceleration for compositing, is not quite as nice as a fully accelerated D2D surface when it comes to text last time I worked this low down. I honestly don’t know if Apple’s done anything in this space recently. What I do know is that UIKit on iOS is generally more modern when it comes to hardware acceleration than AppKit is on macOS, which is a little disappointing. But generally I want to avoid drawing everything all the time, so this mostly impacts things like scrolling framerate when we need to redraw content.

But it also impacts pagination. Say I want to understand how large a run of text is on a page, I need to know the font metrics for the font(s) used. So I need to ask someone about it. I can either ask my own library that has to be able to read font data itself, or I can ask the system to do it for me. DirectWrite and CoreText both have good APIs for this, so it makes the most sense to use the system APIs, IMO. But it means any differences in performance between the two ripple throughout my layout code. And since pagination time is roughly linear for the length of the text to paginate, that OS call can wind up impacting your tight loop. But is it worth going to my own library if the platform isn't fast enough? It depends... a lot. Font work is a whole regime onto itself, so at some point, I'd argue you want to let DirectWrite/CoreText own it, even if it means accepting some drawbacks. To a point.

I was focused on the extent to which MS had better optimized Office to work with Windows, but what you're saying is about the other half, namely that Windows is better optimized (than MacOS) to work with Office. It makes sense that MS co-developed Office and Windows to run as well as possible with each other, and that this synergy is better developed than that between MacOS and Office. Office is probably the single most commercially important aftermarket program for the Mac (when it comes to the Mac's product share). Thus I assume there is extrensive communication between MS's Office team and Apple, such that, if the MS Office team told Apple that they could get much better performance if they did "X" to Mac OS, that's something the MacOS developers would seriously consider. But the co-development surely isn't at the level it is within MS between Windows and Office.

Yes, there are some things about Windows that likely makes it better suited to how Office interacts with the platform. However, those things could very well be true for say, Photoshop. Or really any large monolithic app that sits on low level APIs because that's all that existed when they were written initially. I'd honestly half expect Office and Photoshop are both better suited for pre-OS X Apple than post-OS X Apple. Moving away from Carbon forces developers to adopt higher level APIs than what they were using before (and still use on Windows). UIKit even more so: just look at keyboard/text input on iOS vs AppKit. I'd argue this is a hurdle that is effectively true for the whole legacy app space.

The one thing I’ve learned about Apple that surprised me is how little they like to play favorites with 3rd party devs. Do they pay attention? Yes. Are they willing to help developers make good products if it’s considered important? Absolutely. Is Apple likely to make a change that mostly enables one developer, or at a single developer's behest? No.

Apple only deals to themselves.