Is there any reason you must stay on x86-64?
>>109880381It's the same reason why we have been stuck on it for the last 20 years, and why we will be stuck on it for the next 20 years. I have software compiled for x86 platforms and there is no convenient way to emulate or recompile it. Path of least resistance says stick with this stagnant platform for 20 more years.
>>109880512Let's hope it stays forever. Tech should always be as stable and immutable as possible
>>109880381No affordable widely available arm computers that can run linux without issues
>>109880512how can there be no convenient way to recompile?
>>109880541>immutablewhat's immutable about x86?
>>109880541If you want to live in a world decaying into the dark age of technology, that is fine.At this point x86 is so stagnant Intel is probably loosing/forgetting the knowledge why they did some stuff.I've worked in OS/BIOS development for Intel platforms. It's not an exaggeration to say Intel and BIOS vendors basically sorry about windows booting. Why they need to do something to make windows happy, don't know, just that changing it breaks something. It's not really the ISA that is the source of the cruft, its the legacy peripherals and BIOS requirements that stick around.Which is kind of terrifying considering your BIOS has morphed into a lightweight OS over the last 25 years.
>>109880381post a cheaper alternative that has better performance, doesn't require out of tree kernel patches and can play all video games
>>109880381Is there any reason you must shit in the street iJeet?
>>109880381yes
>>109880706>loosing>I've worked in OS/BIOS development thanks for your service sir
>>109880381The only architecture with unlockable bootloader and general hardware compatibility to install a non-glowing OS
>>109880381Yes
>>109880381Anyone who supports Arm for consumer hardware has severe problems.
>>109880381because amd64 has socketed motherboards and an ecosystem of components
>>109880381All the software I want to run is x86/x64 also, non x86 computers are mostly not a thing.
>>109880381Yeah, the ARM ecosystem is built around ultra closed-down proprietary hardware and software with zero compatibility (and also no programs that I use), while x86 is backwards compatible, has multiple operating systems (2) supporting a wide range of hardware, has all the software in the world, and it lets you run whatever you want (they're working on restricting that right now, but most things will keep running forever).
armv6 is a disaster but the new versions sure good
>>109880381The heat death of the universe will come and the world will still run on x86 and C.
yes, move to x64. Jobs said reduce inventions retards, take out the head from the sand. AMD should implement all the CPUID0 like Intel and delete a retard who makes some custom drivers, that will make them good, they still dont have a decent CPU frequency identification which is cruscial for system time.>>109880706whata retard
>>109881136>x64 has 1152 instructionsI wonder how many of them are typically used
>>109880541uh oh u don't wanna be called a luddite, now do u?
>>109880381yeah, POWER
>>109880381x86-64's variable-length encoding keeps instruction density high, which cuts code footprint and slashes I-cache miss rates. That instruction compression pays huge performance dividends on bloated enterprise cloud workloads crammed full of unpredictable if-else branching logic.
>>109880580>>109880512AI will fix that at one point. You might actually start seeing a lot of proprietary or open source chips popping up.Ports are already easier to do than ever with it.
>>109880381ai slop engagement thread, DNI
>>109884659A few dozen to a few hundred, depending on how you count them. The vast majority of x86 instructions are SIMD instructions. And compilers don't really support these very well. Auto-vectorization is limited and does not use any of the more specialized SIMD instructions.
>>109884893Disagree. 32bit had decent code density. But 64bit pretty much completely destroys any code density advantage x86 had.
discard most of my software to save a few compute cycles?no
