4 ms·

Good. Java is doing something similar with Graal Native Image thing. In a way it is funny to see few years back so many people were claiming that heavy CPU/mem

by geodel 4y ago

Good. Java is doing something similar with Graal Native Image thing. In a way it is funny to see few years back so many people were claiming that heavy CPU/memory usage of JIT based platforms would be even more non-issue in Cloud because one can scale as much they need on demand. And now I see AOT/Slimmed Runtime/Compact packaging are happening largely because of cloud deployments. Seems cloud bills are making impact in places where enterprise cloud architects were running amok with everything micro service deployments.

pjmlp 4y ago
Actually I think it is more competition pressure of languages like Go and Rust than anything else. I have been using Java and .NET languages for distributed computing for the last two decades, and JIT has always been good enough. By the way, Google rolled back their AOT compiler introduced on Android 5, and since Android 7 it uses a mix of highly optimized interpreter written in Assembly, a JIT compiler with PGO feedback, and when the device is idle, those PGO profiles are used to only AOT compiler the application flows that matter. On more recent Android versions, those PGO profiles are shared across devices via the Playstore. On the .NET front, I think the team has finally decided to make front of the whole C++ rulez of WinDev, specially after Singularity and Midori projects having failed to change their mind.
- geodel 4y ago
  Nowadays Go is working on a PGO solution, so there is that. I don't disagree but kinda doubt that new upstart languages with single digit market and mindshare in enterprise space would force .net /JVM behemoth to do anything. Forget Go, places I work would not know a single new thing beyond Java 1.7 or latest Java 1.8. But they have stood up a dozen cloud teams doing every buzzword you can hear about cloud. So unless finance guys ask tough questions about rising Amazon billing IT wouldn't care if their SpringBoot crapola take 2GB of RAM or 32GB.
  - pjmlp 4y ago
    The new upstart languages are where the younger generations are, that is why you see .NET doing all those changes to make rolling an Hello World website as easy as doing it in Go, with global usings, single file code, simplified namespaces and naturally AOT.
- deleted 4y ago
  [deleted]
heurisko 4y ago
> And now I see AOT/Slimmed Runtime/Compact packaging are happening largely because of cloud deployments. I see the main driver of AOT to be startup time for things like lambdas. The JVM is pretty lightweight anyway on modern hardware, especially if you use modules.
kevingadd 4y ago
I do extensive profiling of managed apps and while the JIT does eat a measurable amount of CPU time, it's really not much. And at least on .NET, you can manually ask the runtime to JIT methods, so you can go 'okay, it's startup time, I'm going to spin up a pool of threads and use them to JIT all my code' without blocking execution - for a game I'm working on it takes around 2 seconds to warm ~4000 methods while the other threads are loading textures and compiling shaders. At the end of that the CPU usage isn't a problem and you're mostly dealing with the memory used by your jitcode. I don't know how much of a problem jitcode memory usage actually is in production these days, but I can't imagine it would be that bad unless you're spinning up 64 entirely separate processes to handle work for some reason (in which case I would ask: Why? That's not how managed runtimes are meant to be used.) I mostly do JIT warming to avoid having 1-5ms pauses on first use of a complex method (which is something that could be addressed via an interpreter + background JIT if warming isn't feasible.) The slimmed runtime and compact packaging stuff is definitely attractive in terms of faster deploys and lower storage requirements, however, because the cost of needing to deploy 1gb+ worth of stuff to your machines multiple times a day is still a pain. I don't actually know if AOT is an improvement there though, since in some cases the IL that feeds the JIT can be smaller than the AOT output (especially if the AOT compiler is having to pre-generate lots of generic instances that may never get used.) You also have to ship debug information with AOT that the JIT could generate on demand instead.
- zeroc8 4y ago
  I 've never understood the point of JITing. Just compile the thing once for your target architecture and you're done. No more spawning threads for doing the same thing over and over again. I'm glad that languages like Go and Rust are bringing back the lost simplicity of yesteryear's dinosaur languages. Life can be so easy.
  - lillecarl 4y ago
    Reflection in C# is a thing, it isn't in either Go or Rust. I've read some kind of compiler shenanigans can get something that resembles reflection in C++. I love reflection, the fact that libraries can look at your types is really really cool. Not saying it can't be done with a compiled language but I don't see it anywhere. Being able to load a shared library, search it for classes implementing interfaces, instantiate them and call their methods is pretty slick too.

by geodel 4y ago

pjmlp 4y ago

Actually I think it is more competition pressure of languages like Go and Rust than anything else. I have been using Java and .NET languages for distributed computing for the last two decades, and JIT has always been good enough. By the way, Google rolled back their AOT compiler introduced on Android 5, and since Android 7 it uses a mix of highly optimized interpreter written in Assembly, a JIT compiler with PGO feedback, and when the device is idle, those PGO profiles are used to only AOT compiler the application flows that matter. On more recent Android versions, those PGO profiles are shared across devices via the Playstore. On the .NET front, I think the team has finally decided to make front of the whole C++ rulez of WinDev, specially after Singularity and Midori projects having failed to change their mind.

geodel 4y ago
Nowadays Go is working on a PGO solution, so there is that. I don't disagree but kinda doubt that new upstart languages with single digit market and mindshare in enterprise space would force .net /JVM behemoth to do anything. Forget Go, places I work would not know a single new thing beyond Java 1.7 or latest Java 1.8. But they have stood up a dozen cloud teams doing every buzzword you can hear about cloud. So unless finance guys ask tough questions about rising Amazon billing IT wouldn't care if their SpringBoot crapola take 2GB of RAM or 32GB.
- pjmlp 4y ago
  The new upstart languages are where the younger generations are, that is why you see .NET doing all those changes to make rolling an Hello World website as easy as doing it in Go, with global usings, single file code, simplified namespaces and naturally AOT.
deleted 4y ago
[deleted]

heurisko 4y ago

> And now I see AOT/Slimmed Runtime/Compact packaging are happening largely because of cloud deployments. I see the main driver of AOT to be startup time for things like lambdas. The JVM is pretty lightweight anyway on modern hardware, especially if you use modules.

kevingadd 4y ago

I do extensive profiling of managed apps and while the JIT does eat a measurable amount of CPU time, it's really not much. And at least on .NET, you can manually ask the runtime to JIT methods, so you can go 'okay, it's startup time, I'm going to spin up a pool of threads and use them to JIT all my code' without blocking execution - for a game I'm working on it takes around 2 seconds to warm ~4000 methods while the other threads are loading textures and compiling shaders. At the end of that the CPU usage isn't a problem and you're mostly dealing with the memory used by your jitcode. I don't know how much of a problem jitcode memory usage actually is in production these days, but I can't imagine it would be that bad unless you're spinning up 64 entirely separate processes to handle work for some reason (in which case I would ask: Why? That's not how managed runtimes are meant to be used.) I mostly do JIT warming to avoid having 1-5ms pauses on first use of a complex method (which is something that could be addressed via an interpreter + background JIT if warming isn't feasible.) The slimmed runtime and compact packaging stuff is definitely attractive in terms of faster deploys and lower storage requirements, however, because the cost of needing to deploy 1gb+ worth of stuff to your machines multiple times a day is still a pain. I don't actually know if AOT is an improvement there though, since in some cases the IL that feeds the JIT can be smaller than the AOT output (especially if the AOT compiler is having to pre-generate lots of generic instances that may never get used.) You also have to ship debug information with AOT that the JIT could generate on demand instead.

zeroc8 4y ago
I 've never understood the point of JITing. Just compile the thing once for your target architecture and you're done. No more spawning threads for doing the same thing over and over again. I'm glad that languages like Go and Rust are bringing back the lost simplicity of yesteryear's dinosaur languages. Life can be so easy.
- lillecarl 4y ago
  Reflection in C# is a thing, it isn't in either Go or Rust. I've read some kind of compiler shenanigans can get something that resembles reflection in C++. I love reflection, the fact that libraries can look at your types is really really cool. Not saying it can't be done with a compiled language but I don't see it anywhere. Being able to load a shared library, search it for classes implementing interfaces, instantiate them and call their methods is pretty slick too.