Reading this... my first thought was "But newer x86 can.... oh right ISA..." then I googled for USB ISA slots... and they are apparently a thing. That doesn't mean someone wouldn't need to write a new driver but at least they could still use the cards.
Exactly this, you can even look at the old consoles and see the same thing. They were built to a VERY specific margin and tuned for the same. There is as best I can tell no fat in any of the systems shipped except newer consoles and the original xbox. The only reason I'd say there is 'fat' in newer consoles is because they have much wider requirements than old ones do.
It's cents... but consider this. Linux is run on devices embedded in just about everything. Places where even doubling from 128 to 256MB of flash ROM could seriously hurt margins. So as the old saying goes.. a penny here and penny there sooner or later you're talking real money. And it is real money sometimes millions of dollars in margin.
Unfortunately WINE can't just take the windows shim mechanism that largely just nukes these from orbit on binary load and removes the check all together. Maybe at some point MS will be more open about that.
You'd be surprised, MS doesn't do this randomly. They'd rather break a game if the game is actively in production or the company is around. They only put in shims for applications if the vendor isn't still in business usually or can't get source code. But in quite a few cases they'll just put in a patch binary in the shims that just removes the anti-cheat all together from the binary when loaded. Game still runs... nobody cares.
MS has always held that system calls are not guaranteed ABI stable. So any application doing this is subject to breakage at any time. That said I wouldn't be surprised if they are doing something not to dissimilar to this for those processes in kernel mode to emulate for things that are out of support and have no living vendor.
That said if you look at the list linked above some are "stable" meaning that MS probably knows this happens and kept those specific ones stable. But the rule still applies... never do direct system calls on NT.
People forget that the reason this happens is that most countries have laws against spying domestically. They usually don't have laws prohibiting them from taking data from other spy agencies spying on their own country. So the cheap and easy workaround is you let your friends spy on you for you. It's usually pretty critical for counterintelligence anyway. As the first place an enemy tries to get into is the counterintelligence department.
This reminds me of something Joel Spolsky said awhile back[1] "Never Rewrite from Scratch". I stand by that too.. even if it's a legacy mainframe app it's probably better to use strangler pattern if you really need to extend it an the development platform doesn't suit the need.
I'm also reminded of the SABRE rewrite that had similar issues where agents got massively slowed down by the removal of the 10key navigation that ruled the old system and they had to add it back as emulation.
Possible, I kinda doubt they would as Intel could just cut them off at the knees as they threatened MS with for the Surface Pro X. There is the remote possibility they are licensing from Intel too. At the end of the day I doubt they are going to tell us. Once people start getting the dev machines they can find the edges of the implementation. I suspect it has some quirks we'll discover over time. Regardless this is speculation.
True, but they did have the license IIRC. Otherwise they'd be licensing from VIA or whomever owns that license now. That license AFAIK would include up to SSE4. It's not like Apple is going to tell us. But the JIT nature makes me think it's Transmeta as the company currently holding that IP is a "Patent enforcement entity".
RE AVX and above: My guess is that they are licensing the Transmeta IP which doesn't include those licenses IIRC. So unless they wanted to get sued they'd have to be careful. I suspect some SSE instructions may also not be supported as I don't recall if Transmeta had a license up to SSE4.
It comes from the fact that KNL came from Larrabee which was actually developed as a GPU initially (and even ran games... sort of) but was never actually released. The next revision of that was the Xeon Phi chips you used. So the connection is "Lots of small cores with lots of high bandwidth ram" although these cores are definitely superscalar where Larrabee and derivatives were not really.
Oh agreed, but honestly what makes this so interesting is how tuned it is. I'm honestly surprised we haven't seen Intel or AMD ship an HPC CPU with on package HBM2 yet.
So looking at anandtech's breakdown the CPUs are closer to a knights landing 'CPU/GPU' than a traditional CPU (currently). They also have a ton of HBM2 right next to the dies so this should be insanely fast as they can feed those cores very very quickly regardless of how fast each core is by clock and pipeline. That should massively reduce stalls.
Real world? AFAIK no not yet. The issue is that traditional benchmarks don't really tell the whole story. IPC isn't directly comparable because ARM is ostensibly RISC (this is debatable I'm aware) and Intel is CISC (also debatable). So until things like Adobe Premiere or Media Encoder are ported over (if they are), or similar real world workloads like Blender, it's going to be really hard to compare. Even then things like design power matter. A 15w Intel chip is likely to outperform a 5w ARM chip just because it has more headroom thermally. It doesn't mean that either is faster (IPC per watt goes up the more you downclock for a variety of reasons).
If this sounds like I'm saying it's apples (no pun intended) to oranges... that's pretty much the case. Apple is likey not going to produce an ARM chip in directly comparable fashion to an Intel chip. E.g. equal cache, memory bandwidth, TDP (using Intel calc method), PCI-e lanes etc. Mostly because it doesn't make sense to do so because Intel's chips are designed to be a component of the system while ARM chips are largely designed to be an SOC.
I think it is as well, honestly the DX12 part of this is DOA as far as I'm concerned because it's not open source. So that leaves the better support for other APIs as the key delivered feature. Could MS fix that by setting DX12 up as an open to implement API and open sourcing much of this? Yes. But until they do you're better of using the various translation layers from DX to vulkan when using linux even on WSL.
So GN looked at it, the lack of the IGPU basically killed the i3-9100F in premiere pro as did the lower base clock; even compared to the 3100. The i5 parts seem to do better particularly the 9600K (I don't see the 9400F which again would be hampered by the lack of an IGPU).
So for that it's "Easier" because you check the VRM spec for the socket for server. That's the maximum draw the manufacturer expects any CPU for that socket to ever pull. Then generally most of the higher end parts will vary clock speed vs cores etc to stay on that line.
This works because server motherboard manufacturers only ever build to that spec and not one iota beyond it for cost reasons.
But yeah... average expected draw is going to be interesting and most manufacturers won't give a number to avoid getting sued.
> So where do I find the actual maximum power consumption on recent desktop CPUs then?
Unfortunately you do this by putting it on a motherboard and and generally putting an amp meter on the 12v EPS rail. Either that or just power from wall. The CPU vendors have worked really hard to hide this. Mostly because for most people it's largely irrelevant these days as the CPU will scale to cooling and power delivery. There are some limits though.
I'm curious too because looking at pictures of the VRM it looks like it has less output filtering. My guess is that the board firmware tells the CPU to be less aggressive until it can deliver the power because it has a less overbuilt VRM (still 90A power stages though...). That probably means more of the phases are always active which in this case is probably an advantage as it means there is no long ramp to turn on a phase. I'm going to guess the fact that the phases are doubled also means the board is less likely to turn off phases as it would lose two not one.
To me this smells 100% like a transient issue, Gigabyte probably assumed that more phases would wipe the transient response time out. The issue is that if you're shutting down phases as Buildzoid mentions you'd have to do to get efficiency; you then lose that response time advantage until the phase is spun back up which is the longest part of the power system cycle. Normally output filtering is designed to make up that gap, but I think in the case of these chips that's not happening. I suspect it's a lot more complicated because I have a sneaky suspicion that adding more caps wouldn't solve the problem (completely).
That was one of the few that I thought could handle the 64/128 part. However look at the output filtering: It's roughly the same if not a cap or two larger as what you'd find on x299... which is a higher voltage and thus has lower amperage requirements. I have yet to find a back of board shot but unless it has a ton of SMD AL-poly caps back there that board would still struggle with the ramp described in the thread. Even then I'm not sure the socket resistance wouldn't cause enough V-droop to cause a crash anyway.
I remember when Buildzoid of AHOC did the mobo breakdowns of the TR4 boards and thinking that while some of the super high end boards were probably good for this sort of beating, the mid and low range might struggle hard with the 64/128 part if it ever came into being (3990X was just a rumor at that time). But it looks like they need more caps to handle the transient response time, and probably also some firmware fixes to slow ramp because I don't think all the SMD caps in the world are going to handle that sort of ramp. It's just not possible to get them close enough to the actual CPU without literally putting them under the IHS.
That is incorrect, the thermal protection circuits operate well in advance of the actual junction death temperature. Usually 20C or so minimum on mobile and more on Desktop. The CPU will throttle like mad first to save itself and then just reset the computer assuming the BIOS doesn't block the boot in the first place.
IIRC it's very CPU dependent. I remember running into a similar issue with memcpy vs. memmove where the latter was actually faster on some CPUs because it used stosb instead of AVX/SSE and some intel CPUs could make that really go fast.
TL;DR: benchmark for your specific hardware if it really matters.
It is actually, but it requires AMD or Intel to care. AMD could easily make an AArch64 CPU that is x570 compatible, it would require a BIOS update for sure but they could do it. There is nothing Physically stopping them from making a CPU with all the interconnect bits needed and a ton of AArch64 cores... other than there is really no fiscal incentive to do it.