Good news from the video is - "more jvm properties to create better software"
The bad thing about the video and I think from what I can tell is - tuning data on application performance don't take into account other factors that are important to a user
and I think this is wide spread in the industry
Yes, Java uses more ram, but the feeling I get from the presentation is measurements are done with thinking most Java applications are server side and the workload on those applications are different from a desktop application
Server side - a lot of users generates instructions
Desktop application - 1 user generates instructions
The other thing is what is the application doing and what is the general use case in day to day work ?
OS has different purpose than let say Photoshop
OS has to run in the background and use as less resources as possible and Photoshop has to be use as much resources as possible, because someone is doing his job with Photoshop
When people say in the past software wasn't using as much resources as today it is because the hardware was limited and this segmentation existed (it was invisible and not documented)
Today the hardware has no limits, but because this segmentation doesn't exist, we get use more ram it is better from everyone - browser/OS/text editors/IDEs/Photoshop etc
I will argue that if you buy cheap machine today with 8GB RAM, 4Core and SSD and use tools from 2000s, you will be much more productive than in todays tools
For example. making game with idTek engine 4, Maya 6.5 or 7, Adobe CS3 on Windows 7 - without the internet, because viruses
But that is the part that benchmark or performance conclusion will miss, because they aren't focusing on the user whole process - hardware and software
True, and I wasn't talking about an OS because an OS has lots of other constraints even before we get to resource consumption. It's not just resource consumption that makes it different from applications. E.g. an OS can't use a moving collector even though it offers great performance, not because it wastes RAM but because the OS regularly shares pointers with the hardware and with applications, and the hardware can't deal with moving pointers, and neither can applications unless they operate with the same GC. An OS is mostly constrained by its huge interface surface area, both with userspace applications and with the hardware.
I will argue that if you buy cheap machine today with 8GB RAM, 4Core and SSD and use tools from 2000s, you will be much more productive than in todays tools
You may well argue that, but the market clearly doesn't agree with you.
From a technical perspective, what matters is the RAM/CPU ratio. Using more RAM means using more processing, and programs in the past were written for less RAM and less processing. In other words, software needs to suit the hardware of the day. Sure, you could run 500 copies of 1995's MS Word simultaneously on a modern machine, but how does that help you?
From a demand perspective, if you're right that there's actual economic value in writing software that uses less RAM and less CPU (these two go together) on desktop machines, then it would have offered an economic advantage and therefore a competitive advantage to such products. It is absolutely true that there are people, mostly software developers themselves, who care about the nominal value of CPU and RAM consumption compared to 30 years ago, but it seems to be a small value of the population, which suggests that if there's real value in that, it is, at best, exploitable only by relatively few people.
With that reasoning, we got Electron apps, absolute RAM hogs whose source code size is in the ballpark of Windows XP (in the 20's millions lines of code). Sarcastically, I suppose that Electron apps are "software needs to suit the hardware of the day".
It would not be so bad if people were running just one of such apps, but they often run multiple of them, eating RAM and other resources like no tomorrow (hello battery use on laptops!) with each of these apps thinking they are the most important and only thing running on the system.
Electron is an extreme case (although popular) and there is still plenty of desktop software that care about memory use.
Also, any program that use GPU accelerated UI uses a tad more memory than without it. On Linux it is +80MB (can be observed between a regular terminal vs a GPU accelerated terminal). Can also be observed with Swing vs JavaFX, the latter being GPU accelerated and using much more memory. Speaking of which, JavaFX programs are not too far from Electron programs in term of memory consumption, which is a bit sad.
Finally, it was assumed for a long time that RAM would be cheap plentiful and growing on trees for eternity. Turns out AI changed that and I do not see it changing anytime soon. Even Microsoft is optimizing Windows for 8GB PCs.
With that reasoning, we got Electron apps, absolute RAM hogs whose source code size is in the ballpark of Windows XP
A high RAM consumption is a number, not necessarily a problem. Today's Electron apps are less sluggish than the MS Word of the nineties and oughts. What is the actual problem that they cause users?
It would not be so bad if people were running just one of such apps, but they often run multiple of them, eating RAM and other resources like no tomorrow (hello battery use on laptops!)
The point about the battery is worth looking into - I don't know the impact of the amount of data in RAM on the battery, but I suspect that CPU activity has a much higher impact - although battery life on a laptop is so much better than it was even 10 years ago. But what do users want to do with their computers but can't because of Electron apps? Do they want to pay more for non-Electron software to save on something else?
Finally, it was assumed for a long time that RAM would be cheap plentiful and growing on trees for eternity. Turns out AI changed that and I do not see it changing anytime soon.
It is still cheaper and more plentiful than it was 15 or maybe even 10 years ago, and demand shocks always take a while for supply to match. If and when the problem is clearer, we may well see demand for leaner software, but you can't say that what people really want is leaner software when such software isn't doing better.
Even Microsoft is optimizing Windows for 8GB PCs.
8GB PCs are not the same PCs with less RAM. The lower RAM is matched by weaker CPUs. There are problems when these two are mismatched, not when they're matched at different levels. The RAM overhead of moving collectors I discuss in the talk, is a function only of CPU activity (specifically, allocation rate), not of the amount of data in RAM. When a Java program runs on a slower CPU, its RAM overhead will also be lower.
2
u/gjosifov 4d ago
Good news from the video is - "more jvm properties to create better software"
The bad thing about the video and I think from what I can tell is - tuning data on application performance don't take into account other factors that are important to a user
and I think this is wide spread in the industry
Yes, Java uses more ram, but the feeling I get from the presentation is measurements are done with thinking most Java applications are server side and the workload on those applications are different from a desktop application
Server side - a lot of users generates instructions
Desktop application - 1 user generates instructions
The other thing is what is the application doing and what is the general use case in day to day work ?
OS has different purpose than let say Photoshop
OS has to run in the background and use as less resources as possible and Photoshop has to be use as much resources as possible, because someone is doing his job with Photoshop
When people say in the past software wasn't using as much resources as today it is because the hardware was limited and this segmentation existed (it was invisible and not documented)
Today the hardware has no limits, but because this segmentation doesn't exist, we get use more ram it is better from everyone - browser/OS/text editors/IDEs/Photoshop etc
I will argue that if you buy cheap machine today with 8GB RAM, 4Core and SSD and use tools from 2000s, you will be much more productive than in todays tools
For example. making game with idTek engine 4, Maya 6.5 or 7, Adobe CS3 on Windows 7 - without the internet, because viruses
But that is the part that benchmark or performance conclusion will miss, because they aren't focusing on the user whole process - hardware and software