Silicon and Windows virtual machines?

[tdar]

Yes, it is, but the almost complete lack of drivers for Windows for Arm is a very big problem...

Please provide a example. What driver are you missing? The entire windows 10 driver store has been ported.

 

[Nate Spencer]

I did not assume anything. I asked, not you.. but I pondered.. it would make sense.. to do so.. WHY?

Virtualization layers always do TRANSLATION - how much and from what type to what type is upto them. Simple in concept, but can get complex in execution depending on the variances of what CHILD systems need to be CARRIED on their shoulders.

New app to let you run Windows 10 on your iPhone

Wish you could do more with your iPhone than just run Apple’s app store apps? A group of independent developers is working to sort you out. UTM is a new app that uses QEMU (virtualization software) to run the full version of Windows 10 from Microsoft’s operating system image. iOS devices lack...

www.windowslatest.com

How much money do Intel & all other x86 hardware makers generate?

Would Apple be AVERSE to wanting a CHUNK of that pie?
Would someone not have incentive to LEVERAGE the M1 & its next Gens.. until things at OS level are ported from CISC to RISC?

I am not sure but maybe there were projects or people who had insights into conversion between
big endian <> little endian/ RISC vs CISC .. at what level/ layer.. who knows.. but if the long range incentives exist (which seems to be the case for RISC making a huge come back).. transition pathways for x86 code to execute on Hyper Efficient ARM could exist. In which niches, will have to be checked.

Imagine running Cloud Server Farms on RISC Silicon that is millions of times more power efficient. Operating Cost of that...

ARM uses dynamic translation like x86-64 based system. So it is pretty much as CISC as a x86-64 or AMD64 which is 15 years younger than ARM. AMD64 is a different ISA in Native mode. RISC vs CISC is 20 year ago debate. Most of the m1 gains are combination controlling the whole stack and having the only 5 nm process based SoC. Also most ARM is little endian like x86-64. Intel's issue is mostly they cannot produce anything below 14nm in volume. AMD is already on 7nm and soon on 5 nm via TSMC. Apple has made a calculation that iOS ecosystem is a bigger market to leverage. They are probably right. "RISC" silicon is not millions of times more power efficient. If that were the case Power Mini and mainframes would not drink the power they do and should like jet on a tarmac. You cannot linearly scale CPU performance in that manner.

I own an M1 and fully OS emulation of x86-64 is a non-starter on performance. I have used several solutions based on qemu w/ patches. Win 10 ARM is reasonable TaxACT and brave browser seem to do ok. Civ III and Alpha Centauri almost 20 YO games do ok. But can peg the system at times. The m1 nor ARM tech are magic bullets they make a certain set of tradeoffs. If you are pretty much in the mac ecosystem not a bad solution. If you need Windows or Linux on x86-64 probably not a good choice.

 

[filmak]

Please provide a example. What driver are you missing? The entire windows 10 driver store has been ported.

Right now I do not miss a driver as I do not own a M1 Mac at the moment, even if I like the concept a lot, (except the soldered SSDs and RAM but I hope there will be more options with the higher end Macs to be released) .

Waiting to see how it goes as we need x86 & x64 windows.

I have the information that external devices having intel drivers won't work with the ARM version of Windows, as it was the case with the MS surface too. If this is true, it is a big problem as we need full support for our high end EPSON, HP, Xerox, Dell, scanners, laser printers, LFP, plotters, etc. At their sites they do not offer drivers for ARM windows... Now can you please provide more informations about the entire driver's store ported? How complete is it and what should we wait from it?

 

[tdar]

Right now I do not miss a driver as I do not own a M1 Mac at the moment, even if I like the concept a lot, (except the soldered SSDs and RAM but I hope there will be more options with the higher end Macs to be released) .

Waiting to see how it goes as we need x86 & x64 windows.

I have the information that external devices having intel drivers won't work with the ARM version of Windows, as it was the case with the MS surface too. If this is true, it is a big problem as we need full support for our high end EPSON, HP, Xerox, Dell, scanners, laser printers, LFP, plotters, etc. At their sites they do not offer drivers for ARM windows... Now can you please provide more informations about the entire driver's store ported? How complete is it and what should we wait from it?

The driver store is the built in drivers. I agree that we would like to have support from manufacturers for full function drivers. That will come as more people move towards Arm based systems.

 

[crashnburn]

ARM uses dynamic translation like x86-64 based system.

Very interesting insights - I left the bottom of the stack i.e. Hardware & CPU Arch back..
Recently read a forum thread that mentioned how its a Mix of CISC Opcodes using RISC stuff underneath.

Oh wow! I saw a video where the ARM/ RISC guys found their Low Energy even back then..

What makes a CPU & its Co Processor etc become more Energy Hungry versus not? And more Computing powerful vs not?
Only the wafer silicon process or also some CISC vs RISC or similar DESIGN choices?

So it is pretty much as CISC as a x86-64 or AMD64 which is 15 years younger than ARM.

AMD64 is a different ISA in Native mode.

Hmm..

RISC vs CISC is 20 year ago debate.

And I havent thought about it since way back when I first studied that stuff..

Most of the m1 gains are combination controlling the whole stack and having the only 5 nm process based SoC.

The question is, can someone else replicate such gains in another shop?
What is the hurdle to that?

Also most ARM is little endian like x86-64.

Intel's issue is mostly they cannot produce anything below 14nm in volume.

Why so? Is it a fabrication issue that they cant jump past?

AMD is already on 7nm and soon on 5 nm via TSMC.

So AMD's fabrication of x86 chips is not better than Intels. I remember when there was Intel > AMD & another x86 chip maker.. cant recall started with C??

Will fabrication nm be the KEY Primary factor affecting "energy efficiency" and "computing power" ? moving forward?
Or are there architectural approaches that play a pretty causative Secondary Role?

Apple has made a calculation that iOS ecosystem is a bigger market to leverage. They are probably right.

The mobile app landscape has expanded the Population Access & Time spent on computing/ applications way outside the traditional desktop/ laptop markets.

"RISC" silicon is not millions of times more power efficient. If that were the case Power Mini and mainframes would not drink the power they do and should like jet on a tarmac. You cannot linearly scale CPU performance in that manner.

Hmm.. so that was misconstrued on my part (based on a video of old ARM guy talking about low voltage even 20 years back..) so maybe that's not enough for a full conclusion that I assumed.

I own an M1 and fully OS emulation of x86-64 is a non-starter on performance. I have used several solutions based on qemu w/ patches. Win 10 ARM is reasonable TaxACT and brave browser seem to do ok. Civ III and Alpha Centauri almost 20 YO games do ok. But can peg the system at times.

Hmm.. I guess its a matter of time.. But then how & why are there videos / benchmarks showing crazy performance jumps on M1 for Rosetta emulated apps as well as even Windows ARM which apparently runs better than Surface ARM. I guess its not easy to make translatable comparatives.

In fact some Video etc renderings on M1 just give crazy Computing Results per unit Watts per unit Dollar value spend on machine. What am I missing?

Can apple competitors replicate some pieces of these separately, even if not integrated whole stack like Apple.

The m1 nor ARM tech are magic bullets they make a certain set of tradeoffs.

Do elaborate I'd love to hear your thoughts on this.

If you are pretty much in the mac ecosystem not a bad solution. If you need Windows or Linux on x86-64 probably not a good choice.

Question is can those eco systems follow up this act... with their own show?

 

[jdb8167]

Will fabrication nm be the KEY Primary factor affecting "energy efficiency" and "computing power" ? moving forward?
Or are there architectural approaches that play a pretty causative Secondary Role?

It is a complex interplay between architecture and fabrication. Using TSMC’s 5nm process helps but all you have to do to see that isn’t the whole picture is to notice that the A13 at 7nm was also more efficient than x86 CPUs for the same power requirements.

Apple’s design has a very wide instruction decode. For the M1 it is twice as wide as the best Intel or AMD design. This massively improves the number of instructions per cycle that can be dispatched leading to higher performance at lower clock speeds. For Intel and AMD they have to clock much higher which necessitates needing a higher voltage which leads to much more power required to get the same performance. When they switch to 5nm this won’t change. The power will be lower but not as low as Apple Silicon.

The reason that AMD can’t just widen their instruction decode is because of limitations in the AMD64 ISA. The AMD64 (x86_64) ISA needs a much more complex decode because of variable width instructions and inconsistent opcodes so making the decoder wider just leads to diminishing returns. Both Intel and AMD have stated that they can’t easily create a wider decode stage.

 

[jdb8167]

It is a complex interplay between architecture and fabrication. Using TSMC’s 5nm process helps but all you have to do to see that isn’t the whole picture is to notice that the A13 at 7nm was also more efficient than x86 CPUs for the same power requirements.

Apple’s design has a very wide instruction decode. For the M1 it is twice as wide as the best Intel or AMD design. This massively improves the number of instructions per cycle that can be dispatched leading to higher performance at lower clock speeds. For Intel and AMD they have to clock much higher which necessitates needing a higher voltage which leads to much more power required to get the same performance. When they switch to 5nm this won’t change. The power will be lower but not as low as Apple Silicon.

The reason that AMD can’t just widen their instruction decode is because of limitations in the AMD64 ISA. The AMD64 (x86_64) ISA needs a much more complex decode because of variable width instructions and inconsistent opcodes so making the decoder wider just leads to diminishing returns. Both Intel and AMD have stated that they can’t easily create a wider decode stage.

There is an excellent YouTube video explaining this in another post.
https://forums.macrumors.com/thread...lways-holding-them-back.2242698/post-29472118

 

[haralds]

Yes, it is, but the almost complete lack of drivers for Windows for Arm is a very big problem...

Yes. Hardware attached device emulation is a no go.

 

[crashnburn]

I didn't get any feedback on my writeup which leaves me wondering if the explanation is understandable by non-specialists. It seems really obvious to me but I used to write in machine code and assembler.

There's another explanation at

- this one is spoken instead of written and it has a few diagrams which might make it a bit easier to understand but it may be that it's still difficult for the non-specialist to understand.

It is a complex interplay between architecture and fabrication. Using TSMC’s 5nm process helps but all you have to do to see that isn’t the whole picture is to notice that the A13 at 7nm was also more efficient than x86 CPUs for the same power requirements.

Apple’s design has a very wide instruction decode. For the M1 it is twice as wide as the best Intel or AMD design. This massively improves the number of instructions per cycle that can be dispatched leading to higher performance at lower clock speeds. For Intel and AMD they have to clock much higher which necessitates needing a higher voltage which leads to much more power required to get the same performance. When they switch to 5nm this won’t change. The power will be lower but not as low as Apple Silicon.

The reason that AMD can’t just widen their instruction decode is because of limitations in the AMD64 ISA. The AMD64 (x86_64) ISA needs a much more complex decode because of variable width instructions and inconsistent opcodes so making the decoder wider just leads to diminishing returns. Both Intel and AMD have stated that they can’t easily create a wider decode stage.

There is an excellent YouTube video explaining this in another post.
https://forums.macrumors.com/thread...lways-holding-them-back.2242698/post-29472118

Thanks for those inputs.

That video was a great refresher of my Computer Architecture / CPU & Co Processor fundamentals from college, grad school & ASM/ Device Driver programming days; ALU

If I was Intel or AMD, and had the money to throw at Fabrication + Architecture pipeline boosting, would it be accurate to say its still primarily handicapped by inability or inefficiency of sequencing & fulfilling instruction sets/ OpCodes (longer ones);

Question is.. what could the Chip world folks "copy" from Apple the way Microsoft used to copy from Apple?

 

[jdb8167]

Thanks for those inputs.

That video was a great refresher of my Computer Architecture / CPU & Co Processor fundamentals from college, grad school & ASM/ Device Driver programming days; ALU

If I was Intel or AMD, and had the money to throw at Fabrication + Architecture pipeline boosting, would it be accurate to say its still primarily handicapped by inability or inefficiency of sequencing & fulfilling instruction sets/ OpCodes (longer ones);

Question is.. what could the Chip world folks "copy" from Apple the way Microsoft used to copy from Apple?

Long term, I think they need a new ISA that easily maps onto the existing x86_64 ISA for translation. Considering that Intel and AMD own all the IP needed this should be pretty easy in comparison to what Apple has had to do. After that it is just software tooling to supply compilers and debuggers for the new ISA.

Short term, I don't think there is much they can do except what they are already doing which is pump up the number of cores and boost the clocks where they can within their power budgets.

I have to say that I'm surprised that creating a new RISC ISA isn't something that is currently being discussed widely. With Apple's example, it seems obvious that it is needed. And it doesn't seem particularly risky any longer. Apple is translating x86_64 at about a 10-20% loss for application code. Windows is already available cross architecture so adding a new one won't cause much trouble. Users who want Windows will probably be fine with a new architecture that gives them longer battery life and less heat at the expense of a modest hit on performance--especially when the overall performance will probably still be higher than current architectures.