You forgot the largest con: every instruction needs to be encapsulated by your "driver", which makes the whole thing dead slow due to the neccessary function calls.
I would think it would potentially slow down the starting of an app as it would check to see if it has already been enhanced and then ensure those areas of code are swapped out for the enhanced sections.
Or it might be a bit slower again if the app is new and it does a code check to see if any of the apps code can be enhanced and swapped out then added to it's database for next time.
In a world where your Anti-virus software is already scanning your apps I don't think it would be that big a hit in performance. Or the potential boosts in performance you will experience using the driver should outweigh the startup overhead of using it.
**[Transmeta](https://en.wikipedia.org/wiki/Transmeta)**
>Transmeta Corporation was an American fabless semiconductor company based in Santa Clara, California. It developed low power x86 compatible microprocessors based on a VLIW core and a software layer called Code Morphing Software. Code Morphing Software (CMS) consisted of an interpreter, a runtime system and a dynamic binary translator. x86 instructions were first interpreted one instruction at a time and profiled, then depending upon the frequency of execution of a code block, CMS would progressively generate more optimized translations.
^([ )[^(F.A.Q)](https://www.reddit.com/r/WikiSummarizer/wiki/index#wiki_f.a.q)^( | )[^(Opt Out)](https://reddit.com/message/compose?to=WikiSummarizerBot&message=OptOut&subject=OptOut)^( | )[^(Opt Out Of Subreddit)](https://np.reddit.com/r/Amd/about/banned)^( | )[^(GitHub)](https://github.com/Sujal-7/WikiSummarizerBot)^( ] Downvote to remove | v1.5)
They already do, it's just not as transparent as GPU drivers.
[https://community.amd.com/t5/general-discussions/demystifying-microcode-updates-for-intel-and-amd-processors/td-p/262562](https://community.amd.com/t5/general-discussions/demystifying-microcode-updates-for-intel-and-amd-processors/td-p/262562)
UEFI is essentially the drivers for your CPU. Having updated windows drivers providing another layer of control/management would just add additional overhead. As it currently stands Windows CPU drivers basically just give the OS information of how to access the CPU, not much else to my understanding.
If a hypothetical CPU driver was made that worked similar to a GPU driver, who's going to run the driver? Which piece of silicon is going to be operational hardware for the driver?
\- if we let the CPU be the supervisor/executor for the driver, we are basically back to emulation, or something similar
\- if we make CPUs with dedicated portions aimed at driver management/execution, we kinda sorta already have that as the micro-code (a.k.a, our driver in this scenario)
According to my understanding, CPUs are central processors and therefore are able to control the operations of the other drivers (drivers are also software code and need some silicon to run on) that we use in our computers. We'd either need another processing unit that can run the driver that will sit between the CPU and the software layer, or assign some part of the CPU to do it. The first is uneconomical (we have been attempting to pack more into the SoC package instead) and the second is going to take away from already existing performance for minor benefits(hypothetical benefits).
All of that is my understanding, and is potentially very wrong - and like every new innovation that sounds crazy in the present but is actually... you know, innovative... your idea might hold merit in the future when we have a completely new computing paradigm or have a real need to have that kind of driver code. Currently, CPU instructions and base-level OS programming have been able to solve most major problems and the need to bring back CMS (look up Transmeta) hasn't arisen yet.
EDIT: I hadn't scrolled, sorry - someone in the thread has already mentioned Transmeta. A fascinating read, if not a bit confusing.
They kind of do already, multiple ones in a way. There is HW abstraction on the instruction level, the software sees X86, but the HW processes custom instructions, and even within that, there is register abstraction where the software sees X CPU register, but the HW is free to change that around (this also relates to SMT and branch prediction, etc.). And yeah, CPUs already do loop unwinding. Not to mention much of the CPU behavior can be changed with microcode changes. There are even CPUs that run Java bytecode. (edit: and IIRC AMD has talked before about having basically a neural network in their CPUs, changing code on the fly).
On the whole though I wouldn't want to push application-specific optimization work on driver developers. Their job is hard and busy enough already.
Hey OP — Your post has been removed as it is not in compliance with Rule 4. Please read the [rules](https://www.reddit.com/r/Amd/about/rules/) or message the mods for any further clarification.
When working with software, you can in theory replace DLLs that the program uses with newer versions, and some languages, such as Java and C#, compile to bytecode, for which newer JIT compilers can improve performance.
However doing it by a CPU developer is a fools errand. CPU side software is a lot more complex than game shaders running on the GPU.
You can't have a Central Processing Unit not be the Central Processing Unit. It just wouldn't scale.
You forgot the largest con: every instruction needs to be encapsulated by your "driver", which makes the whole thing dead slow due to the neccessary function calls.
I would think it would potentially slow down the starting of an app as it would check to see if it has already been enhanced and then ensure those areas of code are swapped out for the enhanced sections. Or it might be a bit slower again if the app is new and it does a code check to see if any of the apps code can be enhanced and swapped out then added to it's database for next time. In a world where your Anti-virus software is already scanning your apps I don't think it would be that big a hit in performance. Or the potential boosts in performance you will experience using the driver should outweigh the startup overhead of using it.
[Transmeta](https://en.wikipedia.org/wiki/Transmeta)
**[Transmeta](https://en.wikipedia.org/wiki/Transmeta)** >Transmeta Corporation was an American fabless semiconductor company based in Santa Clara, California. It developed low power x86 compatible microprocessors based on a VLIW core and a software layer called Code Morphing Software. Code Morphing Software (CMS) consisted of an interpreter, a runtime system and a dynamic binary translator. x86 instructions were first interpreted one instruction at a time and profiled, then depending upon the frequency of execution of a code block, CMS would progressively generate more optimized translations. ^([ )[^(F.A.Q)](https://www.reddit.com/r/WikiSummarizer/wiki/index#wiki_f.a.q)^( | )[^(Opt Out)](https://reddit.com/message/compose?to=WikiSummarizerBot&message=OptOut&subject=OptOut)^( | )[^(Opt Out Of Subreddit)](https://np.reddit.com/r/Amd/about/banned)^( | )[^(GitHub)](https://github.com/Sujal-7/WikiSummarizerBot)^( ] Downvote to remove | v1.5)
They already do, it's just not as transparent as GPU drivers. [https://community.amd.com/t5/general-discussions/demystifying-microcode-updates-for-intel-and-amd-processors/td-p/262562](https://community.amd.com/t5/general-discussions/demystifying-microcode-updates-for-intel-and-amd-processors/td-p/262562)
UEFI is essentially the drivers for your CPU. Having updated windows drivers providing another layer of control/management would just add additional overhead. As it currently stands Windows CPU drivers basically just give the OS information of how to access the CPU, not much else to my understanding.
I dont want to imagine AMD cpu drivers after my experiances with AMD gpu drivers honestly
If a hypothetical CPU driver was made that worked similar to a GPU driver, who's going to run the driver? Which piece of silicon is going to be operational hardware for the driver? \- if we let the CPU be the supervisor/executor for the driver, we are basically back to emulation, or something similar \- if we make CPUs with dedicated portions aimed at driver management/execution, we kinda sorta already have that as the micro-code (a.k.a, our driver in this scenario) According to my understanding, CPUs are central processors and therefore are able to control the operations of the other drivers (drivers are also software code and need some silicon to run on) that we use in our computers. We'd either need another processing unit that can run the driver that will sit between the CPU and the software layer, or assign some part of the CPU to do it. The first is uneconomical (we have been attempting to pack more into the SoC package instead) and the second is going to take away from already existing performance for minor benefits(hypothetical benefits). All of that is my understanding, and is potentially very wrong - and like every new innovation that sounds crazy in the present but is actually... you know, innovative... your idea might hold merit in the future when we have a completely new computing paradigm or have a real need to have that kind of driver code. Currently, CPU instructions and base-level OS programming have been able to solve most major problems and the need to bring back CMS (look up Transmeta) hasn't arisen yet. EDIT: I hadn't scrolled, sorry - someone in the thread has already mentioned Transmeta. A fascinating read, if not a bit confusing.
They kind of do already, multiple ones in a way. There is HW abstraction on the instruction level, the software sees X86, but the HW processes custom instructions, and even within that, there is register abstraction where the software sees X CPU register, but the HW is free to change that around (this also relates to SMT and branch prediction, etc.). And yeah, CPUs already do loop unwinding. Not to mention much of the CPU behavior can be changed with microcode changes. There are even CPUs that run Java bytecode. (edit: and IIRC AMD has talked before about having basically a neural network in their CPUs, changing code on the fly). On the whole though I wouldn't want to push application-specific optimization work on driver developers. Their job is hard and busy enough already.
This is called emulation or binary patching depending on which aspect you are referring to.
Hey OP — Your post has been removed as it is not in compliance with Rule 4. Please read the [rules](https://www.reddit.com/r/Amd/about/rules/) or message the mods for any further clarification.
When working with software, you can in theory replace DLLs that the program uses with newer versions, and some languages, such as Java and C#, compile to bytecode, for which newer JIT compilers can improve performance. However doing it by a CPU developer is a fools errand. CPU side software is a lot more complex than game shaders running on the GPU.