Interesting article. I knew that many modern programming languages don't require you to allocate and free manually, but I haven't given it much though. I suppose I'm a little unclear on how much...
Interesting article. I knew that many modern programming languages don't require you to allocate and free manually, but I haven't given it much though. I suppose I'm a little unclear on how much of this is being done by the programming environment (e.g. JVM) and how much is due to the CPU itself; I had always assumed this was just some overhead from the environment.
I would be curious how Dr. Maas's architecture is communicating with the CPU and programs to decide what is safe to remove from memory.
Great idea to decentralize that task; specialized hardware will always perform better than generalized hardware, it just becomes making sure that the specialized hardware is truly worth the development costs and such. Makes me curious what other traditionally CPU intensive tasks could be shipped out to an auxiliary chip to provide non-negligible improvements to performance.
The only gripe I have seen people have with the work is that it tests on "in-order CPUs" even though most new CPUs are "out-of-order CPUs." He may have a lot more work to do, but it is definitely...
The only gripe I have seen people have with the work is that it tests on "in-order CPUs" even though most new CPUs are "out-of-order CPUs." He may have a lot more work to do, but it is definitely a good step forward.
Super interesting idea. I think acceleration units like this have kinda fallen off the bandwagon except for hyper-specific super-technical workloads. I'd love to see something like this become...
Super interesting idea. I think acceleration units like this have kinda fallen off the bandwagon except for hyper-specific super-technical workloads. I'd love to see something like this become more mainstream. Seems like an easy direction to grow into to save power and performance, why it hasn't come up before?
I find the premise interesting, but I'm not sure how much real world value it has. I would think applications sensitive to the "up to ten percent" performance penalty imposed by automated garbage...
I find the premise interesting, but I'm not sure how much real world value it has. I would think applications sensitive to the "up to ten percent" performance penalty imposed by automated garbage collection are likely to be written in an unmanaged language to begin with. And this doesn't really address the other bottlenecks inherited with most managed code frameworks, making C++ or Rust still better options where every ounce of performance is needed.
This article is very light on technical details though, so maybe I'm missing something.
Interesting article. I knew that many modern programming languages don't require you to allocate and free manually, but I haven't given it much though. I suppose I'm a little unclear on how much of this is being done by the programming environment (e.g. JVM) and how much is due to the CPU itself; I had always assumed this was just some overhead from the environment.
I would be curious how Dr. Maas's architecture is communicating with the CPU and programs to decide what is safe to remove from memory.
Great idea to decentralize that task; specialized hardware will always perform better than generalized hardware, it just becomes making sure that the specialized hardware is truly worth the development costs and such. Makes me curious what other traditionally CPU intensive tasks could be shipped out to an auxiliary chip to provide non-negligible improvements to performance.
The only gripe I have seen people have with the work is that it tests on "in-order CPUs" even though most new CPUs are "out-of-order CPUs." He may have a lot more work to do, but it is definitely a good step forward.
For all we know we will be using in order CPUs after all the security issues with out of order.
Super interesting idea. I think acceleration units like this have kinda fallen off the bandwagon except for hyper-specific super-technical workloads. I'd love to see something like this become more mainstream. Seems like an easy direction to grow into to save power and performance, why it hasn't come up before?
I find the premise interesting, but I'm not sure how much real world value it has. I would think applications sensitive to the "up to ten percent" performance penalty imposed by automated garbage collection are likely to be written in an unmanaged language to begin with. And this doesn't really address the other bottlenecks inherited with most managed code frameworks, making C++ or Rust still better options where every ounce of performance is needed.
This article is very light on technical details though, so maybe I'm missing something.
Here is a link to the paper they submitted to IEEE Micro: https://ieeexplore.ieee.org/document/8695831
Neat!