It's not network, it's not some imaginary latency, it's not magic hamsters. Stop making excuses people. Let's just admit that average software engineer does not understand what makes applications slow. Education on performance is very lacking and that's the one and only issue. No you don't have to hyper optimize your applications, just avoiding the dumbest possible ways to handle things will give you 10x speedups - and this does not take weeks of optimizations to achieve. You don't need to write C to care about performance of your application. Whatever your language, domain or project, you can make it faster and therefore more enjoyable to use.
@@nobodyspecial1553 One proper solution for the problem is of course that stakeholder or customer give clear performance requirements to acceptance testing before development starts. Response time limits are studied in 60s:
All we can do is hope that once Moore's law actually dies and the likes of Intel, Arm and the universities making Risk V develop their architectures as far as they will go programmers will finally stop behaving like mentally challenged baboons and start paying attention to whatever it is they are writing. But that's just hope, nothing concrete.
@@nobodyspecial1553 The devs that made the original Pokemon had to write it in assembly because it wouldn't fit on an original gameboy cartridge otherwise Le'ts not dismiss game degs out of hand. A good game dev is worth 10 webdevs any day of the week. And a great one is worth as much as the whole Javascript community.
@@nobodyspecial1553 but it kinda does excuse it because, usually, less efficient software (developed using higher level languages, frameworks) also means cheaper to develop. If you don't acknowledge that as a fact in modern software development, you're not being realistic. It's just not worth it even think about optimization at all in 99% of cases; just use the bloated stuff and get the product out, earn the money. The users are indifferent to the difference between a screen loading instantaneously and when it takes 0.2 seconds to load. So if you don't use the bloated frameworks, you're just making less money. For the more complex applications that actually require optimization like Photoshop I tend to agree that it makes a difference, but the competition is just not there to push companies to optimize.
Everyone programmer I knew in the 80'ties and 90'ties did it because they loved it. It was almost purely passion driven. Most programmers I know today are in it for the low effort/high pay, cozy job. Nothing wrong with that but it does lead to a fundamentally different approach. The, often times, many layers of abstraction between the 'metal' and the code, of course, isn't helping either.
@@gruntaxeman3740 Abstraction is very usefull it is part of designing good architectures, within these architecture it does not have todo with standardisation, abstraction makes sense from a design perspective. Of course you need abstraction layers for all kind of things outside your design as well, to address HW, etc etc, and these layers do add to less efficient code, nonetheless i would not argue against these kind of abstractions. The kind of abstractions i am against are the ones used in "modern" programming languages, to assist clueless programmers, the ones that don't know how to handle pointers, cause memory leakage, don't know what memory allocation entails and freeing up memory, they write their programs in languages that treat them like little children preventing the children from making mistakes abstracting away basic concepts required when you write in C or C++. The kind if programms, programmed by these programmers with highly abstracted and protected languages, generate very inefficient code, of course i can write inefficient code in C too, but generally C and C++ programmers know their language and the relation with the HW it runs on, this is usualy not the case for high level languages.
@@gruntaxeman3740 Yes, it's not that some, or even many, of the abstraction layers aren't justified but it does remove the programmer from the underlying hardware to an extend where I see people today teaching low-level programming languages but not understanding the difference or ranges of a signed vs an unsigned integer, let alone memory allocation/boundaries/alignment/stack/cache/heap, intrinsics, etc. The OS is an abstraction layer in itself, which is why we don't use one when we need things to run predictably or fast. My point is not that they are inherently bad. My point is that even if you are working in an environment on top of a lot of layers (JS in the browser), you should still know how the hardware works and how your code get's from your environment to the hardware. If you do not know this, you end up not initializing your arrays with a size even in situations where you know the size at "compile time" or you write loops that iterate over date in a way that can not be optimized even by the best compiler. Thereby leaving many X performance on the table even though it would not have been any more difficult to write the code much more optimized.
@@ViaConDias I need to write C or similar instead of assembly, to make my code portable. I need to use OS to abstract system resources and for multitasking. I need to compile software for bytecode or use interpreter so end user doesn't need to puzzle CPU architecture compatibility. If I'm creating game, I like to use game engine to ease maintenance for different GPUs and operating systems. I prefer to build my frontend to run in browser because it is really the only standard for client side. Backend is easier. I just need to build container and choose hardware architecture based on where to deploy, if not using bytecode. --- I know hardware and software thoroughly and the situation is like this because the practice of technology companies is to try to make their own privately owned technology in use so they can have royalties or build walls in their ecosystems. Best thing that software developer can do is to prefer standards or open, available technologies offered by many companies. That's why it is very good idea to write client side software to run in browser but it doesn't fit everything and doesn't make sense in everything.
@@gruntaxeman3740 I agree. It is a bit of a jungle out there. I personally try to steer clear of as much of it as possible but it isn't always possible and more often not really practical. I do not use game engines (I might some day) but I do like jumping on a lib like Raylib. I do not feel Raylib is necessarily an abstraction layer, it is more just me not having to write the exact same code. I prefer to write only what I need but writing a complete 3D physics engine would be one of those places where it really isn't practical and it's already done to death by way smarter people than me. As you state C, Zig, etc., are pretty much just portable asm today, so that is 99,9% the right way to go. That doesn't mean that we should blindly rely on the compiler so there's still a few places where writing the code better will give better performance. Even if it is just writing it in a way that the compiler understands to optimize. The containers etc., I just haven't ever looked into. I do not like the whole concept of introducing that layer when I could just make a clear decision on what environment I will be using. I am sure they are great just not for me. The web as the front end is a bit of a different beast and I have not done a lot of it other than using it as a compilation target through WASM. But it is definitely a lot better today than it was 20 years ago where the browser vendors were at full on war and almost nothing was supported the same way. That was truly horrible times 🙂 But to round all this up, I don't really think a lot of the major performance problems we see today comes from people like yourself, with a knowledge of asm, C, hardware etc. I think it comes more from JS, Python, etc., programmers who never felt the need to understand anything deeper than maybe the runtime. This leaves them in a position where they do not know, that they do not know, how to write high performance code. I have had the pleasure of working with Python programmers who believe themselves to be in the top part of Python programmers but when I have pretty straight forward conversations with them they are at a complete loss. Mind you, I make no claim of being an above developer.
They keep on adding crap into OS's that you don't want and don't need. The bloat is real. It's the reason im still on win 10 and never moved to win 11. I'm keeping my performance TYVM
These kind of comments are amusing from a W7 user perspective. Since Firefox is ending support I will be switching to W10 in a matter of weeks (heavily modified ISO of course) and I intend to use it for at least 8 years.
I believe that the more you actually learn about the develoment of commercial software under time and resource constraints, the less you will love his talks, and the more you will understand why things are the way they are. Not that some of his criticisms are not valid, they are, but he offers no solution and doesn't acknowledge the reason why the problems arise. He implies that all the badness happens because new programmers are dumb. Of course, that's not the reason. Blow is either very sheltered and has never been exposed much to the conditions most developers work under, or he is immature and in denial about how messy the real world is. He might also be autistic, I'm not sure he is, that would also explain a lot.
@renatosardinhalopes6073 Except that he is kind of late to that party too. All of those issues he complains about (but doesn't contextualize or offer viable alternatives) have been well known for decades to everyone who is serious about software engineering. This development time tradeoff is even taught about in university nowadays, that's how you know it's old news.
@@fernandogiongo I guess that's true, but one problem on software and a few other fields is how a lot of stuff is kept in-between or inside groups. It might be obvious to them this stuff but not the general public. Jonathan being a game dev also has the benefit of reaching a bigger audience and he is very well spoken to make even begginers understand what he's talking about.
@@renatosardinhalopes6073 He has identified a problem, sure. But his explanation for it is overly simplified or misguided, and he’s proposing the wrong solution for it. The underlying problem isn’t necessarily about programming. It’s more of an organizational problem. A new fancy programming language won’t solve that.
@@arsenbabaev1022 Thank you. Wikipedia says he started working on it mid-2016. I like Blow, but, for a guy that bemoans developer productivity, he sure does seem to take his sweet time making his puzzle game, even though he claims it's the most ambitious puzzle game ever made.
@@Yxcell The statement is really loud. But considering that the previous owner of the title of "best puzzle game" is The witness (if you don’t think so, I would be glad to hear which games deserve this status more), which he also made, then there is reason to believe him. However, he works in a small team (if I'm not confusing anything, he purposefully let go of part of the team) and in addition to the game, he develops a programming language and a rather impressive standard library for it. In addition, he says that he does not want to release the language unfinished into the world. So, in terms of productivity, he is doing pretty well.
@@cyanmargh Fair enough. I've actually never played The Witness, but I do have fond memories of Braid. I understand that he's working on several ambitious projects at once (Jai, game engine, Sokoban) and he's trying to make sure they are all released in perfect shape. I do sympathize with his complaints about bad software and poor developer productivity, but I just think it's fun to poke fun at his productivity in a good-spirited way. Plenty of large tech companies have teams within them working on a variety of impressive projects that never get heard of or see the light of day. Would he consider those teams productive as well? As I mentioned before, I respect Jonathan Blow and agree with him on a lot of issues, I just think he's too focused on the game development space to see what else is being worked on in other fields of software. :-)
Seeing Half Life Alyx run fast in high res (on 8 year old GPUs), versus a cartoon Meta/Facebook VR world that barely runs shows the difference software makes. Half-life was originally built for 1998~ CPUs.
I haven't seen Facebook VR but when 3D graphics is in question, slowdown may be caused by 3D-assets and not the code. Half-life works in some 32k polygon BSP maps where average polycount in model is something like 256 polygons. That really don't require much of performance to run.
It seems to me that the real reason that programs have become slow is not that people "simply forgot how to write high-performant programs", but that there is no longer a need for it. What is more profitable - to spend a month of development and cover 90% of customer's computers or to spend two or three months and cover 95%? Of course, the first one. I've been using jai for over a year now and I can say that it's a wonderful language and I'd use it instead of C (and especially C++) wherever possible. It really speeds up the development process (especially the refactoring part). However, sadly, if jai becomes successful, then instead of forcing people to write programs, people will have the choice of "spend a week to cover 90% of the market or spend two and cover 95%". Anyway, it's nice that this language (and especially its huge standard library) is better suited for "quick and dirty prototyping that then develops into a real solution" than python.
I would argue that there was never a need for it, but after years of being exposed to slow stuff people just stopped to care. "Just buy w faster machine" is all that you need.
I'm loving what Jai has done being one of the best curly brace programming languages. Just wondering the specific things about its design make it so engineers only spend a week doing the same reflectors in 2 months using other similar languages?
The problem is abstractions are getting higher (now we just tell AK ai what to program) but machines are not really getting faster. "But more cores" you say. All cores have to write to the same memory at the end of the day. If two cores write to the same memory address at the same time there goes your program
Jonathan Blow seems to ignore that CPU or GPU is not what is usually limiting. It is speed how fast data is transferred from volatile memory, non-volatile memory or in network, or latency. This has been reality for decades. However, amount of data is used in images or everywhere is increased because of higher fidelity so that makes things slower. Performance can be actually increased wasting CPU/GPU power to use more compression to minimize time wasted when moving data. Most obvious example is Jpeg images in web. They load much faster than uncompressed file formats. Instead of focusing CPU or GPU, it is better to focus how fast user perform tasks using software.
It's much simpler than that. Most software engineers do not have an intuition about what's slow and what's fast, you can make things fast in any domain, but people just do not have this knowledge. I've worked on everything from websites, web applications to low-level analysis software and even some embedded software, in most cases people do not care, and when they do their focus in the wrong place. Like trying to optimize some algorithm when in reality it's your memory that's messed up and causing a huge slowdown because CPU is busy doing nothing for most of the time. Education on performance is very lacking, where it stops for most people is at: switch to binary search if your element count exceeds XYZ.
@@filipg4 Focus should be code maintainability. When software runs slowly, then something stupid is usually done. Clean, maintainable code makes easier to spot if something stupid is done and makes modifications simple.
@@yessopie But he's not *really* working on a solution to this problem, in fact, is he? His solution is for his own particular problem. Jai is (yet another) C++ alternative. How would that solve the problem of the escalating complexity of software in general, when most software nowadays is written using interpreted languages or GC languages, using massive frameworks, bloated package managers, and massively complex build and deployment systems? It wouldn't, of course. Jai only solves J. Blow's problem of disliking modern C++, Rust and Zig. Maybe it makes his particular approach to game development easier, but most people don't write their own game engines (for good reason), and it does next to nothing to help people who are developing non-game software in a commercial context.
It doesn’t matter if a program is slow, when virtually all useful programs spend 99% of time waiting on network io. Games are mostly trivial programs writing into GPU memory. Real software looks very different to children’s games.
You have no idea what you are talking about. Games are one of THE most complex software systems out there. Sure, they don’t do that much io waiting (actually they do too but it’s not the main computation there), but neither does Pro Tools when i open it. What do you think a DAW is doing for 60 seconds when it’s opening? Surely nothing that couldn’t be avoided with a codebase that has a couple million lines less boilerplate
When your program only waits on network io it is structured wrong. Maybe instead of sending and waiting for requests individually you should batch them up into larger requests or just a single giant one, maybe network io is not even necessary -- not everything has to be a web application -- or maybe you run all the code on the client side where it does only need to load once and then never talk with a server far away. What do you mean "virtually all seful programs", MS Word has a slow Math editor, Photoshop and GIMP take multiple seconds to start, and web applications and sites are now multiple megabytes making them slower (the average website is now larger than DOOM). I could say that my program spends most of the time in memcpy, then it is not the problem that memcpy is slow, the problem is that the program creates useless copies everywhere. When you spend time waiting on network io, you are probably making too many requests and you are not doing them in parallel.
It's not network, it's not some imaginary latency, it's not magic hamsters. Stop making excuses people. Let's just admit that average software engineer does not understand what makes applications slow. Education on performance is very lacking and that's the one and only issue. No you don't have to hyper optimize your applications, just avoiding the dumbest possible ways to handle things will give you 10x speedups - and this does not take weeks of optimizations to achieve. You don't need to write C to care about performance of your application. Whatever your language, domain or project, you can make it faster and therefore more enjoyable to use.
"He's thinking about this from a game dev perspecrive"
That's my favorite. As if that should excuse less intensive programs for being slow.
@@nobodyspecial1553
One proper solution for the problem is of course that stakeholder or customer give clear performance requirements to acceptance testing before development starts.
Response time limits are studied in 60s:
All we can do is hope that once Moore's law actually dies and the likes of Intel, Arm and the universities making Risk V develop their architectures as far as they will go programmers will finally stop behaving like mentally challenged baboons and start paying attention to whatever it is they are writing. But that's just hope, nothing concrete.
@@nobodyspecial1553 The devs that made the original Pokemon had to write it in assembly because it wouldn't fit on an original gameboy cartridge otherwise Le'ts not dismiss game degs out of hand. A good game dev is worth 10 webdevs any day of the week. And a great one is worth as much as the whole Javascript community.
@@nobodyspecial1553 but it kinda does excuse it because, usually, less efficient software (developed using higher level languages, frameworks) also means cheaper to develop. If you don't acknowledge that as a fact in modern software development, you're not being realistic. It's just not worth it even think about optimization at all in 99% of cases; just use the bloated stuff and get the product out, earn the money. The users are indifferent to the difference between a screen loading instantaneously and when it takes 0.2 seconds to load. So if you don't use the bloated frameworks, you're just making less money. For the more complex applications that actually require optimization like Photoshop I tend to agree that it makes a difference, but the competition is just not there to push companies to optimize.
Everyone programmer I knew in the 80'ties and 90'ties did it because they loved it. It was almost purely passion driven. Most programmers I know today are in it for the low effort/high pay, cozy job. Nothing wrong with that but it does lead to a fundamentally different approach.
The, often times, many layers of abstraction between the 'metal' and the code, of course, isn't helping either.
Many abstraction layers in code are justified and they exists because lack of standardization.
@@gruntaxeman3740 Abstraction is very usefull it is part of designing good architectures, within these architecture it does not have todo with standardisation, abstraction makes sense from a design perspective. Of course you need abstraction layers for all kind of things outside your design as well, to address HW, etc etc, and these layers do add to less efficient code, nonetheless i would not argue against these kind of abstractions. The kind of abstractions i am against are the ones used in "modern" programming languages, to assist clueless programmers, the ones that don't know how to handle pointers, cause memory leakage, don't know what memory allocation entails and freeing up memory, they write their programs in languages that treat them like little children preventing the children from making mistakes abstracting away basic concepts required when you write in C or C++. The kind if programms, programmed by these programmers with highly abstracted and protected languages, generate very inefficient code, of course i can write inefficient code in C too, but generally C and C++ programmers know their language and the relation with the HW it runs on, this is usualy not the case for high level languages.
@@gruntaxeman3740 Yes, it's not that some, or even many, of the abstraction layers aren't justified but it does remove the programmer from the underlying hardware to an extend where I see people today teaching low-level programming languages but not understanding the difference or ranges of a signed vs an unsigned integer, let alone memory allocation/boundaries/alignment/stack/cache/heap, intrinsics, etc.
The OS is an abstraction layer in itself, which is why we don't use one when we need things to run predictably or fast.
My point is not that they are inherently bad. My point is that even if you are working in an environment on top of a lot of layers (JS in the browser), you should still know how the hardware works and how your code get's from your environment to the hardware. If you do not know this, you end up not initializing your arrays with a size even in situations where you know the size at "compile time" or you write loops that iterate over date in a way that can not be optimized even by the best compiler. Thereby leaving many X performance on the table even though it would not have been any more difficult to write the code much more optimized.
@@ViaConDias
I need to write C or similar instead of assembly, to make my code portable.
I need to use OS to abstract system resources and for multitasking.
I need to compile software for bytecode or use interpreter so end user doesn't need to puzzle CPU architecture compatibility.
If I'm creating game, I like to use game engine to ease maintenance for different GPUs and operating systems.
I prefer to build my frontend to run in browser because it is really the only standard for client side.
Backend is easier. I just need to build container and choose hardware architecture based on where to deploy, if not using bytecode.
---
I know hardware and software thoroughly and the situation is like this because the practice of technology companies is to try to make their own privately owned technology in use so they can have royalties or build walls in their ecosystems. Best thing that software developer can do is to prefer standards or open, available technologies offered by many companies.
That's why it is very good idea to write client side software to run in browser but it doesn't fit everything and doesn't make sense in everything.
@@gruntaxeman3740 I agree. It is a bit of a jungle out there. I personally try to steer clear of as much of it as possible but it isn't always possible and more often not really practical. I do not use game engines (I might some day) but I do like jumping on a lib like Raylib. I do not feel Raylib is necessarily an abstraction layer, it is more just me not having to write the exact same code. I prefer to write only what I need but writing a complete 3D physics engine would be one of those places where it really isn't practical and it's already done to death by way smarter people than me.
As you state C, Zig, etc., are pretty much just portable asm today, so that is 99,9% the right way to go. That doesn't mean that we should blindly rely on the compiler so there's still a few places where writing the code better will give better performance. Even if it is just writing it in a way that the compiler understands to optimize.
The containers etc., I just haven't ever looked into. I do not like the whole concept of introducing that layer when I could just make a clear decision on what environment I will be using. I am sure they are great just not for me.
The web as the front end is a bit of a different beast and I have not done a lot of it other than using it as a compilation target through WASM. But it is definitely a lot better today than it was 20 years ago where the browser vendors were at full on war and almost nothing was supported the same way. That was truly horrible times 🙂
But to round all this up, I don't really think a lot of the major performance problems we see today comes from people like yourself, with a knowledge of asm, C, hardware etc. I think it comes more from JS, Python, etc., programmers who never felt the need to understand anything deeper than maybe the runtime. This leaves them in a position where they do not know, that they do not know, how to write high performance code. I have had the pleasure of working with Python programmers who believe themselves to be in the top part of Python programmers but when I have pretty straight forward conversations with them they are at a complete loss. Mind you, I make no claim of being an above developer.
They keep on adding crap into OS's that you don't want and don't need. The bloat is real. It's the reason im still on win 10 and never moved to win 11. I'm keeping my performance TYVM
These kind of comments are amusing from a W7 user perspective. Since Firefox is ending support I will be switching to W10 in a matter of weeks (heavily modified ISO of course) and I intend to use it for at least 8 years.
Jblow speaking the truth
7 years ago.
And nothing has changed since then. And the game isn't released either.
Only getting worse
Geez I hope people realize this was recorded 7 years ago
I have zero clue about programmint but i love listening to blow😂
I believe that the more you actually learn about the develoment of commercial software under time and resource constraints, the less you will love his talks, and the more you will understand why things are the way they are. Not that some of his criticisms are not valid, they are, but he offers no solution and doesn't acknowledge the reason why the problems arise. He implies that all the badness happens because new programmers are dumb. Of course, that's not the reason. Blow is either very sheltered and has never been exposed much to the conditions most developers work under, or he is immature and in denial about how messy the real world is. He might also be autistic, I'm not sure he is, that would also explain a lot.
@@fernandogiongo The first problem to finding a solution is identifying the problem.
@renatosardinhalopes6073 Except that he is kind of late to that party too. All of those issues he complains about (but doesn't contextualize or offer viable alternatives) have been well known for decades to everyone who is serious about software engineering. This development time tradeoff is even taught about in university nowadays, that's how you know it's old news.
@@fernandogiongo I guess that's true, but one problem on software and a few other fields is how a lot of stuff is kept in-between or inside groups. It might be obvious to them this stuff but not the general public. Jonathan being a game dev also has the benefit of reaching a bigger audience and he is very well spoken to make even begginers understand what he's talking about.
@@renatosardinhalopes6073 He has identified a problem, sure. But his explanation for it is overly simplified or misguided, and he’s proposing the wrong solution for it.
The underlying problem isn’t necessarily about programming. It’s more of an organizational problem. A new fancy programming language won’t solve that.
GEM of a video
Jon Blow, "These are the breaks..."
2:33 he's conflating instruction flow and parallelism.
Does anyone know what's the game he demo'd in the video and how long he's been working on it (relative to 2024)?
sokoban, not released yet
@@arsenbabaev1022 Thank you. Wikipedia says he started working on it mid-2016.
I like Blow, but, for a guy that bemoans developer productivity, he sure does seem to take his sweet time making his puzzle game, even though he claims it's the most ambitious puzzle game ever made.
@@Yxcell The statement is really loud. But considering that the previous owner of the title of "best puzzle game" is The witness (if you don’t think so, I would be glad to hear which games deserve this status more), which he also made, then there is reason to believe him. However, he works in a small team (if I'm not confusing anything, he purposefully let go of part of the team) and in addition to the game, he develops a programming language and a rather impressive standard library for it. In addition, he says that he does not want to release the language unfinished into the world. So, in terms of productivity, he is doing pretty well.
@@cyanmargh Fair enough. I've actually never played The Witness, but I do have fond memories of Braid.
I understand that he's working on several ambitious projects at once (Jai, game engine, Sokoban) and he's trying to make sure they are all released in perfect shape.
I do sympathize with his complaints about bad software and poor developer productivity, but I just think it's fun to poke fun at his productivity in a good-spirited way.
Plenty of large tech companies have teams within them working on a variety of impressive projects that never get heard of or see the light of day. Would he consider those teams productive as well?
As I mentioned before, I respect Jonathan Blow and agree with him on a lot of issues, I just think he's too focused on the game development space to see what else is being worked on in other fields of software. :-)
not with Microsoft overhead and every single program being a corporate hog
Seeing Half Life Alyx run fast in high res (on 8 year old GPUs), versus a cartoon Meta/Facebook VR world that barely runs shows the difference software makes. Half-life was originally built for 1998~ CPUs.
I haven't seen Facebook VR but when 3D graphics is in question, slowdown may be caused by 3D-assets and not the code.
Half-life works in some 32k polygon BSP maps where average polycount in model is something like 256 polygons. That really don't require much of performance to run.
Memory bandwidth.
It seems to me that the real reason that programs have become slow is not that people "simply forgot how to write high-performant programs", but that there is no longer a need for it. What is more profitable - to spend a month of development and cover 90% of customer's computers or to spend two or three months and cover 95%? Of course, the first one. I've been using jai for over a year now and I can say that it's a wonderful language and I'd use it instead of C (and especially C++) wherever possible. It really speeds up the development process (especially the refactoring part). However, sadly, if jai becomes successful, then instead of forcing people to write programs, people will have the choice of "spend a week to cover 90% of the market or spend two and cover 95%". Anyway, it's nice that this language (and especially its huge standard library) is better suited for "quick and dirty prototyping that then develops into a real solution" than python.
When will he finally release Jai to the public 😢
I would argue that there was never a need for it, but after years of being exposed to slow stuff people just stopped to care. "Just buy w faster machine" is all that you need.
I'm loving what Jai has done being one of the best curly brace programming languages.
Just wondering the specific things about its design make it so engineers only spend a week doing the same reflectors in 2 months using other similar languages?
The problem is abstractions are getting higher (now we just tell AK ai what to program) but machines are not really getting faster.
"But more cores" you say.
All cores have to write to the same memory at the end of the day. If two cores write to the same memory address at the same time there goes your program
@@Salantor You are the reason everything sucks.
Because capitalism does everything in the cheapest way!
If they used LSP to make photoshop it really would've been 192x faster!
"Old man yells at cloud". Or, to put it differently, "I already accepted that everything sucks and he should too".
Should have used LSP
Dude, I love LSPs so much
Jonathan Blow seems to ignore that CPU or GPU is not what is usually limiting. It is speed how fast data is transferred from volatile memory, non-volatile memory or in network, or latency. This has been reality for decades.
However, amount of data is used in images or everywhere is increased because of higher fidelity so that makes things slower.
Performance can be actually increased wasting CPU/GPU power to use more compression to minimize time wasted when moving data. Most obvious example is Jpeg images in web. They load much faster than uncompressed file formats.
Instead of focusing CPU or GPU, it is better to focus how fast user perform tasks using software.
Yeah, he's thinking about it as a game dev, someone that doesn't need to care about IO as much as other devs.
It's much simpler than that. Most software engineers do not have an intuition about what's slow and what's fast, you can make things fast in any domain, but people just do not have this knowledge.
I've worked on everything from websites, web applications to low-level analysis software and even some embedded software, in most cases people do not care, and when they do their focus in the wrong place. Like trying to optimize some algorithm when in reality it's your memory that's messed up and causing a huge slowdown because CPU is busy doing nothing for most of the time.
Education on performance is very lacking, where it stops for most people is at: switch to binary search if your element count exceeds XYZ.
@@filipg4
Focus should be code maintainability.
When software runs slowly, then something stupid is usually done. Clean, maintainable code makes easier to spot if something stupid is done and makes modifications simple.
He is very aware of this and talks about it specifically in other lectures. This is just one clip
@@mattymattffs what I/O makes every basic app take longer to load than it did in 1992 off of floppy disks?
Old man yells at cloud
Except for the part where he is actually proposing and working on solutions... Not just complaining.
Young man dont understand that old men know more then u.
@@yessopie But he's not *really* working on a solution to this problem, in fact, is he? His solution is for his own particular problem. Jai is (yet another) C++ alternative. How would that solve the problem of the escalating complexity of software in general, when most software nowadays is written using interpreted languages or GC languages, using massive frameworks, bloated package managers, and massively complex build and deployment systems? It wouldn't, of course. Jai only solves J. Blow's problem of disliking modern C++, Rust and Zig. Maybe it makes his particular approach to game development easier, but most people don't write their own game engines (for good reason), and it does next to nothing to help people who are developing non-game software in a commercial context.
No one cares about cpu anymore. We need it for controlling but for ai, we need accelerators like npu or GPU. There are new types of parallel cpu.
It doesn’t matter if a program is slow, when virtually all useful programs spend 99% of time waiting on network io. Games are mostly trivial programs writing into GPU memory. Real software looks very different to children’s games.
You have no idea what you are talking about. Games are one of THE most complex software systems out there. Sure, they don’t do that much io waiting (actually they do too but it’s not the main computation there), but neither does Pro Tools when i open it. What do you think a DAW is doing for 60 seconds when it’s opening? Surely nothing that couldn’t be avoided with a codebase that has a couple million lines less boilerplate
What counts as "real software"?
@@drxyd probably enterprise java codebases and react
the vast majority of the kinds of programs he mentions in the talks (compilers, editors, photoshop etc) make few to no network calls
When your program only waits on network io it is structured wrong. Maybe instead of sending and waiting for requests individually you should batch them up into larger requests or just a single giant one, maybe network io is not even necessary -- not everything has to be a web application -- or maybe you run all the code on the client side where it does only need to load once and then never talk with a server far away. What do you mean "virtually all seful programs", MS Word has a slow Math editor, Photoshop and GIMP take multiple seconds to start, and web applications and sites are now multiple megabytes making them slower (the average website is now larger than DOOM). I could say that my program spends most of the time in memcpy, then it is not the problem that memcpy is slow, the problem is that the program creates useless copies everywhere. When you spend time waiting on network io, you are probably making too many requests and you are not doing them in parallel.