Will Software Stop Getting Slower? - Jonathan Blow
ฝัง
- เผยแพร่เมื่อ 25 ส.ค. 2022
- Jonathan Blow gives some advice on how to improve your skills as a game developer based on his experience.
Snip taken from "Reboot Develop 2017 - Jonathan Blow, Thekla Inc. / Making Game Programming Less Terrible"
Original video: • Reboot Develop 2017 - ...
#gamedev #gamedevelopment - วิทยาศาสตร์และเทคโนโลยี
The slowness will continue until morale improves
No, the slowness of a software will continue as long as a hardware accelerates
I’m yet to meet a product manager that values performance of applications 1/100 of getting new features out. On old hardware there is no “this sort of works” it either works well or it doesn’t work at all. But we did have a lot of crashes in the old days, nostalgia makes people forget that. A lot of the time things did not work
@@fenixfve2613 hardware is about to stop it's acceleration, I hope GPT comes and saves the day, but I don't think it will.
"Andy giveth and Bill taketh away" was definitely a thing in the early 90s, and I first heard it in the transition from DOS to Windows, where the heaviness of the GUI made applications significantly slower than their old text mode equivalents.
I blame the slowdown in today's software to the modern insistence to use JavaScript for absolutely everything. Photoshop 6 was almost certainly written in C. I bet the current version is Electron or something similar.
> I bet the current version is Electron or something similar.
I'm almost certain it has got some web tech mixed in. I know After Effects uses node.js for its startup screen and some other pages in the UI.
Blender uses python for UI and it's fast even on low-end devices, scripting languages are not the problem.
@@pokefreak2112 I agree, the laziness of programmers is also of great importance. I am still surprised that on my computer Photoshop can give an error "not enough RAM to use the tool: brush", provided that the blender works on it without problems.
The real answer is because there's no motivation to make it faster.
Noone cares really that Photoshop takes a few seconds, noone cares that opening a window takes half a second.
It probably could be programmed the take less time, but for what purpose? Unless people stop using the software because of it why would they put more development time into it.
@@ClarksonNo1 I think the real answer here is that noone cared that it got a tad slower than before and now we are where we are now.
Companies want the money at the end of the stick as fast as possible true low level optimization would be too costly for them, it's about minimum viable product.
Will software ever stop getting slower? No. The more that developers rely on existing libraries, that the more of these "time/work saving" libraries that are used in programs, the slower programs will likely become.
the best libraries continually improve which results in ones like the python numpy library which is much faster than python itself since it’s implemented in C. Improving common libraries can increase performance for everyone who uses them and happens as an ecosystem matures.
It has nothing to do with which libraries exist. It is good to have libraries.
The problem is lack of judgement of when they should use what.
@@user-ov5nd1fb7s Did I not specify usage? It has *everything* to do with the libraries used. And, yes, those with lack of judgment will use libraries that provide little benefit or no at all. In any case, if you don't understand what a library is doing to you app, don't use it.
I agree with ur first comment. software development has become lazy where all we do is program glue to hold other peoples codes together. i believe this is mostly due to the lack of documentation in literally everything software related. The operating systems are a major problem, they make a mess of api calls and understanding graphics apis are like trying to translate sumerian into sanskrit. the problem i see is the lack of how to use or why to use in documentation, what isnt nearly enough, if that's even included. proper documentation is the best way forward, or everything will continue to get worse. love2d, a lua game engine, has the perfect example of how documentation should be. it is perfect. imagine if vulkan or opengl api's had neatly formatted and simple to use documentation like that.
@@knuxyl that is the initial problem. The reason it isn't fixed is because no one is paying for it to be fixed. People are getting what they paid for.
Back in the Windows XP days things felt faster.
I think PS is slow at startup is because it loads hundreds of plugins, probably single-threaded.
That would explain it, but that's not a good reason lol. Now the question is why on earth is there 100s of plugins?
@@jondoe6608 Because plugins can be independently developed and deployed.
Plugins are not the real problem either. Any reasonably big project will need some sort of plugin architectures set up for various parts of the project. Jonathan Blow employs the technique EXTENSIVELY in his programming.
@@jondoe6608 Yeah, there really isn't a good reason. They could probably relatively easily hot-fix this by just having those plugins load in the background while more necessary features like the basic UI and displaying the image work. (Although I guess if displaying the image depends on some of the hundreds of plugins then you have a much more systemic problem)
@@spiritwolf448 I don't see a reason to load all the functionality of PS on start up, I don't think a user uses over half the functionality of PS in one session normally. So why load all of it :^)
I would make it so that on start they just register a few add menu entries so that start is under a few MS for the plugins. then on first use the plugin is fully loaded.
@@jondoe6608 Yeah that sounds about right.
I have gimp running on a core2 quad using 8GB of DDR2 and Ctrl+N and Enter works about as fast as I can type it.
Linux is still pretty fast if you know what you are doing. I recently backed up several multi-gigabyte partitions processed thru a multithreaded compressor @ 300Mb/s.
Needless to say, you still need an almost encyclopedic knowledge of how everything works or spend several hours googling and/or reading documentation.
That's a pretty slow compressor! Demand more!
Yeah. Blow doesn't like shared libraries but it's precisely the culture of shared libraries that allows me to know I don't have slow js monsters on my system. I check what every package over 10MB contains but that's only possible because there are few of them.
Preach it!
Everyone is using bloated libraries now. Acceptance test is based on your average expected tolerable wait time.
We are currently in multithreading madness, programming multi core system will be very complex, why? Because of all possible thread locks, raise conditions, way to much stuff get into actual game or business logics. Why multicore is a thing a future , well its all about efficiency, but we are nearing end of what is possible to use , microchip shortages comming and no way we would able to develop cpus. The hope is to have more maintainable systems.
If it gets intolerable that will force change through markets. It is at the level that markets will tolerate. It takes more work to make it go faster which could be spent on features etc / costs money, so only if people demand it would that extra work be put in (at some point people start switching to gimp or older Photoshop versions). So its not gonna get slower forever if hardware stopped slowness would stop its as cheaply made as the market allows probably
Software will collapse, and that's a good thing.
Compile times are getting slower because theirs more to compile. It's a trade off ands rational one. If you can speedup run time by increasing time done at the beginning that makes sense.
If the huge code bases with hundreds of libraries are impossible for these compilers to process within tens of seconds, imagine how hard it must be for humans to comprehend.
JBlow definitely has a point about people being not as allergic to complexity as he wants them to be. Having that said, I'm sure there had to be a way to serve the "sophistication" that these customers deserve without literally making code bases into humongous labyrinths that are hard to navigate and fit inside their head.
@@SimGunther if there was it would already be done. JBlow thinks people are more incompetent than they are when they are just making rational tradeoffs.
That's very often not the case, especially in C(++) code because of its compilation model. You can very easily get into a situation where you compile something 100x times unnecessarily. And even if you don't, C++ has some unfortunate features that make it slow to compile unavoidably in many situations.
Other languages and build systems have their own quirks, some are more prone to accidental slowness than others, but you will very often find them wasting a ton of resources on simple things for various reasons. Build time is only increasing if you don't pay attention to it, and after some time you can spot the build doing ton of unnecessary work if left unchecked.
There isn't more to compile, people just bloat up their projects and don't pay attention to compile times. If you have the project correctly laid out, compile times should be fast. The only way they can be slow is if you are letting the compiler do a ton of wasted work.
The tradeoff that people are making is just that they can't be bothered to pay attention to their compile times and see what wasteful work the compiler is doing that they can fix. Most of the time if they took the time to do this, they would benefit enormously from faster compile times and therefore faster iteration and debugging. It's a tradeoff, but not a rational one.
@@fennecbesixdouze1794 you can call whatever you want bloat. If you think there isn't more to compile somehow you think programs are getting smaller and offering less in terms of their feature set overtime.
Economics matter. Things like time to market, portability, etc all take a performance hit for other gains. Without it we'd have software from ~10 years ago that could run faster on hardware from ~22 years ago... and we'd be way worse off for it.
Blow's programming style is actually extremely similar to every other systems programmer today. He acts like his insights are somehow novel and counter-industry, but they are very much not. For example, he constantly rails against classes and "object oriented programming", advocating for use of plain structs instead. Is this counter-industry? Well, it's counter the 90's, and if you're programming in C++ then you're largely stuck with the bad ideas of the 90's. But today? The most successful recent systems programming language, backed by the largest software engineering employer on the planet (a web company) is Go, and it doesn't have classes at all, instead favoring structs.
Software objectively is actually not getting slower. It's getting much faster. Especially in critical areas.
Blow's talks mainly focus on the buggy, taped-together products that you frequently encounter in daily life, on the web etc. This is simply a product of more people building in more and more haphazard ways. When people can tape together a few libraries with a few cheap bootcamp grads and launch a product, they will, because they simply aren't prioritizing speed or efficiency. But the community of serious and knowledgeable programmers is still growing very rapidly, and they are working on many performance-critical systems, as well as improving practices, methodology, and languages.
It does not matter if "the community of serious and knowledgeable programmers is still growing very rapidly" if everytime I try to use an application on my everyday use is slower af like photoshop, epicstore, visual studio code, any jetbrains IDE, slack, etc. If those programmers are not the one making our every day software and websites then what's the point on growing their community?
No one is claiming that the capacity for performance is in decline. That's great and all about the community of knowledgeable programmers growing, but that really doesn't take away from that fact that real world programs are slow. Your explanation of taped together libraries doesn't ease any frustration users of slow software have. Our potential for faster software isn't useful if not utilized.
"Hey man don't complain about Photoshop being slow, they aren't prioritizing speed man!" ???
Go is a "systems programming language"? Also, most apps are not written in Go.
First?
The witness is laughably bad in this respect. Its performance for the low fidelity of the graphics was dire (doubly ironic because he wrote a bunch of stuff about exactly the kind of performance issues - popin etc that the witness suffered from) There's a difference between talking and doing I guess.
> popin etc that the witness suffered from
The fuck are you talking about
Also there is no connection between low fidelity graphics and "it should run fast". At least not for CPU it's not
@@saniel2748 There's not a huge cpu load for the witness, it's a puzzle game. The engine is terribly optimized and for a guy that goes around waffling about these things on any stage or magazine that will allow he doesn't actually deliver.
@@michael1 I don't think you understand where cpu load in games comes from
I also don't think you have proof of your claim?
@@saniel2748 Well try thinking some time. Maybe you'll manage it. Stop if your head hurts
@@michael1 You are arrogant, please apply your advice to yourself
Do you like not understand how having huge open world with lots of objects is CPU intensive? And lots of it is alpha clipped foliege which is also expensive for GPU no matter how "high fidelity" it is
Blow's programming style is actually extremely similar to every other systems programmer today. He acts like his insights are somehow novel and counter-industry, but they are very much not. For example, he constantly rails against classes and "object oriented programming", advocating for use of plain structs instead. Is this counter-industry? Well, it's counter the 90's, and if you're programming in C++ then you're largely stuck with the bad ideas of the 90's. But today? The most successful recent systems programming language, backed by the largest software engineering employer on the planet (a web company) is Go, and it doesn't have classes at all, instead favoring structs.
Software objectively is actually not getting slower. It's getting much faster. Especially in critical areas.
Blow's talks mainly focus on the buggy, taped-together products that you frequently encounter in daily life, on the web etc. This is simply a product of more people building in more and more haphazard ways. When people can tape together a few libraries with a few cheap bootcamp grads and launch a product, they will, because they simply aren't prioritizing speed or efficiency. But the community of serious and knowledgeable programmers is still growing very rapidly, and they are working on many performance-critical systems, as well as improving practices, methodology, and languages.
Go is not successful or widely used or backed by Google (anymore)
This example included Photoshop, which is one of the most used programs in the world. I don't see how you can make the argument that he's complaining about subpar software made by ameteurs.
The trend is clear software is getting bloated and slower.