By ensuring privacy and allowing E2E encryption?
All it’s ensuring is that people who don’t understand privacy have something to complain about.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Anyone else a bit skeptical about Apple silicon future?
- Thread starter dapa0s
- Start date
- Sort by reaction score
All it’s ensuring is that people who don’t understand privacy have something to complain about.
That may well have been what the original K8 was about. I never saw the originally proposed ISA.
Games are one area I think Apple Silicon will actually help the mac. There were always two problems with games on mac - Apple ships with crappy GPUs and Apple ditched OpenGL/Vulcan and doesn’t have a DirectX compatibility layer. It’s basically use Metal or nothing.
Mac is way too small the of market share to make that work, but add in iPad and iPhone and now you have a decent reason to port/support Apple Silicon.
I am not really happy about it but I just ask myself the question: what do I have to hide? Nothing really; I'm pretty boring.
You're talking about niche markets (except for gaming---and why should Apple care when games on the App Store are the top downloads? Apple is making $$$ hand over fist in gaming, just not the way you're thinking of it).
Not an issue for Apple.
I found it, it’s “real mode” I was referring to.
Attachments
Ah, yes, real mode. Just one of the many modes that, if removed, would make Intel’s job a lot easier (at the cost of the inability to run old software that most people don’t run anymore).
It’s hard to directly compare so I extrapolated from Geekbench compute benchmarks. On Metal the M1 is a bit slower than an AMD Radeon RX 560. Looking at the Vulkan benchmark puts the the RX 560 at about equivalent to the NVIDIA GeForce GTX 1050 Ti at about 20,500. The NVIDIA GeForce RTX 3090 is about 137,000. This about an 6.5 to 7 times performance improvement. So being conservative I rounded up to an 8x improvement needed for the ASi GPU to match the RTX 3090. Hence 64 M1 GPU cores.
It is interesting from a FPU32 perspective more cores are needed for the ASi GPU to match the 3090. But as you say, TFlops really aren’t reliable. I trust Geekbench a bit but until real world tests can be performed we won’t really know. Maybe it is just because Metal is more performant than Vulkan.
Edit: Good article. Maybe Geekbench is testing with both INT and FLOAT 32 at the same time which would but the RTX 3090 at a FPU32 disadvantage. I need to read up on Geekbench compute benchmarks.
Last edited:
It would make everyone's life easier. I mean initial hurdle for the boot loader people having to update their code to not assume the chip starts in real mode, but what a bloody blessing it would be if we could just strip out real mode, segmentation, A20 gates - While we're at it, let's simply for the TSS and GDT structures. We don't need most of what the GDT does without segmentation anyway, and most (all?) modern operating systems don't use hardware task switching beyond having two or three tasks or something with different privilege levels. While we're at it, let's rip out all addressing of 8-bit registers like AL and AH. It seems to be faster to use AND to bit mask what we want anyway if we want to pack things together that tight. While we're at it, let's let go of the 16-bit versions too - bye-bye AX. We can keep the 32-bit EAX,etc. if people want those still.
Apple's A chips have dropped all sorts of legacy stuff including 32-bit support since the A7 I think it was. ARM's own ARMv9 designs drop 32-bit hardware support for a lot of them. Ball's in your court Intel and AMD.
Might also depend on the size of the data sets. I don't know how large datasets Geekbench works with - if it's fairly small bits of data sent to the GPU and then massively manipulated. Apple's TBDR GPU has quite substantial tile cache that could perhaps be speeding up the compute tasks if it can store more of the data in a cache than the other GPUs. Main memory access will then be slower on the M1, but if the other GPUs need to access more of the data from GDDR and the M1 access it from L2 then that's a substantial difference.
It's also worth noting that, generally speaking, TBDR GPUs will perform better with fragment shaders and all sorts of screen space effects and worse with geometry. Now I don't know the precise characteristics of the M1 relative to AMD/Nvidia GPUs and I know that since Maxwell Nvidia has used some form of "tiling" in their GPUs even though they are still considered immediate mode renderers, but the different GPUs will have different strengths and weaknesses.
Geekbench may also use a variety of precision levels, FP16, 32, 64, INT8 - and GPU performance will scale differently with different data types - some GPUs at least historically - have been artificially handicapped in FP64 to make those who need good FP64 performance have to buy Quadro/FirePro/Tesla
In short I'm echoing the sentiment that FP32 peak performance isn't everything, Geekbench is one valid testing solution but also won't show the whole picture and only tests GPGPU. We also don't know how well it's going to scale with more GPU cores - GPUs of course generally scale well, being massively parallel, but we don't know how Apple is going to make the larger GPU core chips. And whether it will get to a point of memory starvation - TBDRs are generally more efficient with respect to memory bandwidth but the more you scale up the more bandwidth is needed and so on and so on. - So really time will tell and we will have more data points to extrapolate from if/when we get a 16 core and/or 32 core (or other numbers) GPU(s) and I think in particular, seeing the scaling from the M1 to whatever options we get will be fascinating, especially with respect to memory starvation, and finding out if those chips will do something special to try and prevent that - or whether it'll really even be a problem for the architecture at that scale yet at all.
Yep. You could make a lot of progress with x86 by getting rid of all that stuff and increasing the number of 64-bit registers (and using one of the instruction bits that you freed up by getting rid of all the low/hi register stuff to index the the new additional registers).
And meanwhile it wouldn't sell, backwards compatibility is the most important thing. Though getting rid of real mode would be more of a blessing than a curse. We have enough old old hardware available for those things that still need real mode.
fwiw, We still have 3 PC's that need real mode that can't be replaced with something newer without a LOT of $$$$$'s. (hardware controlling / testing PC's)
You'd kill your customer base.
Make no mistake, a large part of why x86 is the dominant computing platform today is due to compatibility with legacy software. Its certainly little to do with being objectively "good".
Pull some move like that, where you wipe out 16 or 32 bit code compatibility or make it hard/slow to run and you'll hand the market to your competitor that didn't. Or your competitor which has an existing software library that runs on their already 64 bit platform.
In fact, it happened more or less - intel tried their Itanium 64 bit platform and AMD ate their lunch with X64 which could run x86 code. Itanium ran x86 via software emulation and it was SLOOW. AMD64 killed it, literally.
Some call what x86 has "baggage". Others call it "mission critical software compatibility".
Happily as emulation/JIT translation/cloud migration/architecture independence becomes more of a thing this is becoming less important - but when x64 was in its infancy, intel or AMD betting the farm on a clean sheet 64 bit platform would have been suicide.
Yeah but the Itanic had lots of performance issues even in native mode. If it had been a competent RISC design instead of a computer science experiment it might have beat out AMD64.
If you need 16-bit real mode and can’t meet your needs with virtualization or even emulation, something is very wrong.
Specialized hardware -- virtualization/emulation can never handle that without costing more than buying new equipment. You'd actually have to write your own drivers to tie into your virtualization solution, and a lot of this kind of hardware doesn't include details like that to write your own..
I wonder if the way Apple sees gaming as a future for MacOS is the integration with iOS via ARM. There's certainly a big game market outside of iOS, but that's a pretty potent one to be able to port over....
Assuming Microsoft would play along, it would run all software from the last 5 years or so. Not everyone needs backward compatibility. Microsoft is already abandoning “old” hardware with Windows 11. The time is coming when such a chip would be a good seller. 95% of PCs are running games, web browsers, and office suites. 99% are running that stuff or Adobe or the like. None of that needs real mode. And you can keep selling crappy processors for those people.
Itanium didn’t use software emulation to run x86. It had an actual x86 core on there. It was crap.
And why is everyone pretending that if you sell chips that do not have real mode that means you can’t sell any chips that do? Intel is a big company with lots of chips. It can sell chips that cater to the ever-shrinking market that needs to run software from the 1990’s, as well as chips that burn a third less power for the same performance, or a third more performance for the same power, and do so by jettisoning compatibility with real mode and some of the other seldom-used modes.
As long as they keep selling crappy processors, I'm good.
fwiw, Windows 11 runs everything Windows 10 did, even our oldold 32-bit corporate stuff.. Can't say as I like 11 much, the shell is not as functional.
One thing to remember about Apple Silicon is it is built around the idea of doing a lot more work each cycle than other silicon. This is why it can outperform anything but high end Intel and AMD and stands toe to toe with the high end stuff at a fraction of the power usage. It has crazy high ILP with a lot of decoders and a ton of cache. Of course, to exploit this type of microarchitecture fully you need software written for it so to speak (more threads and more things in it that can be done in parallel).
As to gaming, remember that MoltenVK also handles transklation of Vulkan to Metal. It is inexpensive, performs well and already is starting to find its way into games and other graphics intensive items.
As to gaming, remember that MoltenVK also handles transklation of Vulkan to Metal. It is inexpensive, performs well and already is starting to find its way into games and other graphics intensive items.
The nice thing is, for the parallelism we are talking about here, you don’t have to do anything. More threads isn’t really going to help too much, as those go to other cores. Where apple excels is parallelism WITHIN a core, and that exists naturally in almost all code without having to do anything. If you have these instructions, for example:
a = a + 1
b = b + 1
x = 30
c = a + b + x
b = b + 1
You can do the first three instructions in parallel within one core. You can even do the final b = b + 1 before the c =, using a register renaming scheme. The software developer doesn’t have to do a thing.
But Win 10 did drop 16-bit support
And Windows 11 will only run, officially, on fairly new hardware even if it can run old software on that hardware. Which is what I believe was meant
That’s what i meant. Which means if you counted on old ports, graphics cards, interface cards, etc., you are out of luck. Windows is getting ready to clean house.But Win 10 did drop 16-bit support
And Windows 11 will only run, officially, on fairly new hardware even if it can run old software on that hardware. Which is what I believe was meant
32-bit Windows 10 can still run 16-bit code.But Win 10 did drop 16-bit support
And Windows 11 will only run, officially, on fairly new hardware even if it can run old software on that hardware. Which is what I believe was meant
Don't really care about Windows 11 for a few years. All my personal hardware runs it and we don't usually do OS upgrades on work computers unless there's a very compelling reason.