Geekbench 6 is now a thing

[leman]

@theorist9 Are you you using talked about as a backup for MR now or is it the other way around

 

[theorist9]

@theorist9 Are you you using talked about as a backup for MR now or is it the other way around

Like you, I enjoy sharing my thoughts on both sites .

And sometimes my questions as well. For instance, I hoped that by posting my Adobe Acrobat Pro benchmarking request on both sites I'd get more data. No luck yet, though...

 

[leman]

And sometimes my questions as well. For instance, I hoped that by posting my Adobe Acrobat Pro benchmarking request on both sites I'd get more data. No luck yet, though...

I'd love to help out but I have a strict policy of not allowing any Adobe software on my computers

 

[Cmaier]

Like you, I enjoy sharing my thoughts on both sites .

And sometimes my questions as well. For instance, I hoped that by posting my Adobe Acrobat Pro benchmarking request on both sites I'd get more data. No luck yet, though...

I just posted my M1 Max MBP results. 30 seconds faster than yours.

 

[theorist9]

I just posted my M1 Max MBP results. 30 seconds faster than yours.

Nice! That's a 74/44.9 – 1 = 65% improvement over my 2019 i9 iMac—or (74 – 44.9)/(2*(74 – 44.9)) = 50% improvement, if we calculate the % change in quadrature.

That's a refreshing change after seeing an average improvement of only ≈10% (in quadrature) with Mathematica. Many of the routine office processes I do with both MS Office and Acrobat always seemed unreasonably slow to me on my Intel Macs, so I was hoping we might see a striking improvement in this area. Some of this could be due to MS Office, at least, being badly written for MacOS. I don't have a fast Windows PC to compare.

 

[Cmaier]

Nice! That's a 74/44.9 – 1 = 65% improvement over my 2019 i9 iMac—or (74 – 44.9)/(2*(74 – 44.9)) = 50% improvement, if we calculate the % change in quadrature.

That's a refreshing change after seeing an average improvement of only ≈10% (in quadrature) with Mathematica. Many of the routine office processes I do with both MS Office and Acrobat always seemed unreasonably slow to me on my Intel Macs, so I was hoping we might see a striking improvement in this area. Some of this could be due to MS Office, at least, being badly written for MacOS. I don't have a fast Windows PC to compare.

And M2 would be even faster (Presumably)

 

[Nycturne]

That's a refreshing change after seeing an average improvement of only ≈10% (in quadrature) with Mathematica. Many of the routine office processes I do with both MS Office and Acrobat always seemed unreasonably slow to me on my Intel Macs, so I was hoping we might see a striking improvement in this area. Some of this could be due to MS Office, at least, being badly written for MacOS. I don't have a fast Windows PC to compare.

I think you'd be surprised when it comes to Office. It also depends a lot on what workflows you are trying to test with MS Office when looking at performance.

Office is ancient (that Word 1.1a code that's out in the open is about as old as I am, but would still be very familiar to today's Word engineers), single-threaded, and where code is shared, generally runs equally on different platforms. However, there are specific cases where Darwin itself makes things harder for large monolithic suites like this. Boot is one such area, where Apple went so far as to changing how dyld worked in iOS 15 / macOS 12 to make the linker perform faster during app launch. But you only get the benefit if your minimum target is iOS 15 / macOS 12. https://www.emergetools.com/blog/posts/iOS15LaunchTime

 

[exoticspice1]

Nice! That's a 74/44.9 – 1 = 65% improvement over my 2019 i9 iMac—or (74 – 44.9)/(2*(74 – 44.9)) = 50% improvement, if we calculate the % change in quadrature.

That's a refreshing change after seeing an average improvement of only ≈10% (in quadrature) with Mathematica. Many of the routine office processes I do with both MS Office and Acrobat always seemed unreasonably slow to me on my Intel Macs, so I was hoping we might see a striking improvement in this area. Some of this could be due to MS Office, at least, being badly written for MacOS. I don't have a fast Windows PC to compare.

MS office on a 12th Intel is very quick on Windows. Sometimes I wish Apple kept Intel for desktops.

 

[Cmaier]

MS office on a 12th Intel is very quick on Windows. Sometimes I wish Apple kept Intel for desktops.

Office is VERY fast on my M1 Max mac, too. In fact, colleagues complain about not being able to work with 400 page documents (takes forever to scroll, search, etc.) I create on their firm-issued machines, but they work fast on my machine.

Office is not particularly challenging to a CPU with a high single-core performance.

 

[theorist9]

MS office on a 12th Intel is very quick on Windows. Sometimes I wish Apple kept Intel for desktops.

I don't think that would help, since I've got a reasonably fast Apple Intel desktop (i9-9900K), and get delays with Office. I suspect the speediness you see on PC's is mostly because Office for Windows is better-coded than Office for Mac.

 

[theorist9]

I think you'd be surprised when it comes to Office. It also depends a lot on what workflows you are trying to test with MS Office when looking at performance.

Office is ancient (that Word 1.1a code that's out in the open is about as old as I am, but would still be very familiar to today's Word engineers), single-threaded, and where code is shared, generally runs equally on different platforms. However, there are specific cases where Darwin itself makes things harder for large monolithic suites like this. Boot is one such area, where Apple went so far as to changing how dyld worked in iOS 15 / macOS 12 to make the linker perform faster during app launch. But you only get the benefit if your minimum target is iOS 15 / macOS 12. https://www.emergetools.com/blog/posts/iOS15LaunchTime

I get bigger delays opening Office documents than Office apps. I've got a large Word reference document (207 MB, 257 pp) I often consult, and opening it fully (by which I mean it finishes paginating at the bottom so I can search it) takes 24 seconds. And it's not the read speeds on my SSD that are causing the bottleneck:

 

[Yoused]

I don't think that would help, since I've got a reasonably fast Apple Intel desktop (i9-9900K), and I get delays with Office. I suspect the speediness you see on PC's is mostly because Office for Windows is better coded than Office for Mac.

What OS are you running? Because it would seem that a current macOS would le tuned for AS and not so much to favor older x86 Macs.

 

[theorist9]

What OS are you running? Because it would seem that a current macOS would le tuned for AS and not so much to favor older x86 Macs.

I'm using Monterey, but I don't believe that the OS significantly affects app performance. Plus this has been a consistent problem with Office across many different OS's (at least for me). My previous Mac was a BTO 2014 15" MBP with the fastest available processor and SSD*, and even when it was new Office felt slow.

[*Yes,'fastest SSD' wasn't typo; it had the largest (1 TB) SSD option, which was the only one with 4 PCIe lanes; all smaller ones used two. ]

 

[exoticspice1]

Office is VERY fast on my M1 Max mac, too. In fact, colleagues complain about not being able to work with 400 page documents (takes forever to scroll, search, etc.) I create on their firm-issued machines, but they work fast on my machine.

Office is not particularly challenging to a CPU with a high single-core performance.

Yeah, I am not surprised it's fast on M1 Max. I mentioned 12th gen Intel because they have comparable ST to M1.

Theorist is on 9th Gen Intel which is not very fast these days going by ST.

If the Mac had a 12th Gen Intel it would have been comparable to M1 Max and since desktop users don't care about pref/w that's why I mentioned Apple should have kept x86 and ARM64. Apple can afford both.

edit: I forgot about VMs. Lol. Office on ARM windows 11 is quick on M1 but I want Apple to create boot camp again. You know what I will create a thread about this...

 

[Yoused]

My previous Mac was a BTO 2014 15" MBP with the fastest available processor and SSD*, and even when it was new Office felt slow.

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!"

 

[Cmaier]

On repagination, I recall a time when the original (pre-gui) word, and perhaps the first windows versions, didn’t repaginate until you told them to. I never figured out why they don’t cache the pagination and store it as part of the file.

 

[Nycturne]

I get bigger delays opening Office documents than Office apps. I've got a large Word reference document (207 MB, 257 pp) I often consult, and opening it fully (by which I mean it finishes paginating at the bottom so I can search it) takes 24 seconds. And it's not the read speeds on my SSD that are causing the bottleneck:

It wouldn’t be the case no. XML Office documents do have some inefficiencies, which creates some overhead compared to the older binary formats, but make them a bit easier to version and maintain. But I absolutely agree it shouldn’t be disk I/O that determines how long it takes to open a file, and I wouldn’t expect Windows to be much better here based on your comments.

Cmaier is right that there is no on-disk cache for pagination data, so it will always repaginate on open, which means reading through the entire document and running full layout of the document. That’s never going to scale well for larger documents. It’s one reason background pagination exists, but it’s more of an “interruptible pagination” than something that truly happens in the background. This stuff is expensive when doing it from scratch like this.

eBook readers have a similar problem, but they solve it by mostly just saying “give me a page starting at character N”, which is generally fast enough. They don’t want “page N”, like Word does. Caching would help, but properly invalidating such a cache would be… interesting.

(I read that it is, or at least was, full of ***triple-indirect pointers).

There were/are handles from the era where heap compaction was something you needed to run periodically, which are double-indirect pointers. I suppose certain structures would look like triple-indirect in specific circumstances? But generally the opposite was true where structures would have arrays embedded into them to maintain data locality (something handles make possible).

This sort of thing is not likely to be the root cause of performance issues anyways.

 

[theorist9]

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).

It certainly feels that way on MacOS. It does seem to operate better on Windows. Part of the problem is they keep increasing the overhead. I had an old Word benchmark file (which I can't seem to find) that actually took longer to complete when I upgraded my 2008 MBP to a 2011 MBP, because at the same time I also switched to a newer version of Office.

That people continue to use it is a testament to the power of the MSRDF, alongside their intense marketplace shennanigans.

What's MSRDF? To balance my bashing of MS Office's coding inefficiency with some praise, I think the main reason people continue to use it is that there's nothing out there that can match its functionality, including Open Office, Google's office suite, and Apple's office suite.

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

Yeah, I do tend to turn off most of the autocorrect features.

 

[theorist9]

It wouldn’t be the case no. XML Office documents do have some inefficiencies, which creates some overhead compared to the older binary formats, but make them a bit easier to version and maintain. But I absolutely agree it shouldn’t be disk I/O that determines how long it takes to open a file, and I wouldn’t expect Windows to be much better here based on your comments.

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.

 

[Yoused]

Cmaier is right that there is no on-disk cache for pagination data, so it will always repaginate on open, which means reading through the entire document and running full layout of the document.

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.