Love the focus on speed and optimized data storage. Most programmers have lost this art and are unfortunately creating bloated and slow software. And certainly the languages that I use today at work gives me no opportunity to even consider this problem. That is why I love coding for old 8 bit systems in machine code/assembly, because it keeps me sane and getting back that feeling of control of the hardware! Every byte counts!
Cool, Valve uses the same tech! One of their physics programmers gave a talk (it's somewhere on youtube) which mentioned that. It's awesome how easy it makes serializing and deserializing structs into files.
this might be the talk you are referencing, and it appears to be a good watch for more then just the pointers.. th-cam.com/video/Nsf2_Au6KxU/w-d-xo.html
If you had a way to specify a minimum object alignment on the underlying buffer, you should be able to 2x, 4x, ... the range of the relative pointer. (i.e if something can only be at offset 0, 2, 4 there is no need for an encoding that allows for offset 1). EDIT: Ah yes, it's in the comment for 'possible future work' seen flying by at 31:39.
I would love to see more videos of you coding or dealing with / explaining different programming/game topics. I find them very educative and interesting to watch. I hope you have time to make more videos. Thanks for this one
Thank you for doing these. This is one of the only demos of yours that I have felt I truly understood what was going on, at least in part. Mostly because I have done basically no C++ or game programming so I can't really relate to your lamenting on how poorly C++ does x. Even still I really like your thought process and would be very excited to try out this language when it is made available. I suspect it would make it easier for me to try out some low-level optimizations (something I don't have much experience in). Cheers!!!
Jon answered that on a stream: That would be 64bits but it's not working right now. Anyway he'll probably change the SOA behavior and he doesn't want to complicate it for now.
42:35 Wait! Have I understood correctly that the compiler looks for *_all_* workspaces in the program and builds something for each one of those? Nothing more required except setting the build-options?
Pretty much. When you say compiler_create_workspace you are saying "here is a new thing to compile" and the build_options says the details of how to compile it. The code shown in that segment is all of the code that was necessary to build that separate program.
Damn you're right... www.google.com/patents/US6625718 The fact that you can patent something like this sounds like total bullshit to me but it looks legit. :/
It might be nigh unenforceable, but I'm still pretty sure that it would be able to go to court if whomever holds the patent at the moment doesn't agree with you? It would probably lose, but court cases are expensive and a huge waste of time...
Technically not true draculatern, hence "patent trolls". However after a recent supreme court ruling at a minimum they cannot take advantage of how East Texas tended to favor the one bringing suit.
Since the relative pointer has a particular alignment, could you get more range by using element offsets rather than byte offsets? That is, multiply the relative pointer value by the element size before doing the rest of the steps involved in dereferencing it.
But the relative pointer *doesn't* have a particular alignment. It could point to a struct that just got loaded from disk, packed. If you want bigger numbers, use bigger numbers.
Question. Is that pack functionality going to be available in the standard library for the language, or will we have to implement it ourselves? Also I hope you don't get in any trouble over relative pointers, because there's a (really, really stupid) patent "US 6625718 B1" as defined here www.google.com/patents/US6625718
The behavior of copying that struct (at 18:00) should probably be the way you had it already, imo. memcpy is a straightforward enough way to preserve the internal relativity, or so it seems to me.
It should be a "view". That terminology is relatively standard and agreed upon in C and C++. en.cppreference.com/w/cpp/string/basic_string_view. www.khronos.org/registry/vulkan/specs/1.0/apispec.html#_vkimageview_3 Even if you wanted to be different here, "view" says exactly what it is: a lightweight, non-owning handle that, by default, points to the whole thing. The most important thing is to convey how low-overhead and non-owning it is.
At 43:33 am i correct that if you were to switch around the "value" and "data" fields in the "NodeGeneral" struct, your two relative pointers would be pointing a NULL? That doesn't seem ideal, although i understand that some trade-off is necessary.
back in asm and in with C (with macros) I used to do these relative to the base of the containing object (the logic being it was just that little bit easier to generate the address. 'load this field, add that value to the object pointer, done.'). then moving to C++ i gave in to the urge to c++-ify and made a c++ templated class for that sort of thing but considered storing the offset pointer relative to the actual pointer inferior.. it slightly frustrated me. I wished there was a way to silently pass or reference the 'this' of the enclosing scope or something
Was distracted so I hope it wasn't mentioned in the video, but does that mean assignment of such a pointer involves a conditional branch? Written as C ints: b = a == 0 ? 0 : (intptr_t)&a + a - (intptr_t)&b;
I thought you meant it would resolve if it was a relative or absolute pointer at assignment time. What exactly are you asking about then? How it provides some sort of safety net for not doing arithmetic on null pointers?
First, I would like to thank you for this feature. It is really needed. Really, though, I just came to ask an unrelated question. Given how fast you have gotten your compile time for this language, what do you think the guys that work on clang/LLVM could be doing better? These kinds of videos by Chandler Carruth (th-cam.com/video/vElZc6zSIXM/w-d-xo.html) suggest to me that they care quite a bit about performance.
I agree for the most part(certainly about the complexity...), but I meant something along the lines of handling #includes, templates, and/or general file I/O naively vs something more fundamental like slow syntactic/semantic processing that is just due to their coding style, which is where you could make that modern C++ argument. How do you think such experienced engineers could inadvertently write slow C++ code? Taking your opinion on modern C++ for granted, what do you think the main thing that jai(not sure if it's an acronym or what) is doing/will do to make it more obvious that you are writing slow code? Right now, it looks like there's: 1. removal of hidden costs, 2. intuitive support for meta-programming up front and simplified/better support for generics, and 3. decoupling of data and procedures. Though, I don't think you can get away with not supporting dot calls (not sure if I missed the verdict on that one), and I think I can make a good case for them if it comes up in the future.
#includes are terrible for performance to begin with. They should go away. C++ is working toward that with 'modules' but I presume the result is going to be nasty and complicated, because everything in C++ is that way. C++ templates were done in an unfortunate way to begin with. The only way to fix them is a do-over, but at this point that would mean scrapping 3/4 of C++, which they are not about to do. I dunno. I just don't think 'saving C++' is a worthwhile project. Things get *much* better if you toss out all the old problems and start over. About this: > How do you think such experienced engineers could inadvertently write slow C++ code? I think you are giving "experienced engineers" too much of the benefit of the doubt. Experience is good, but the exact nature of the experience matters critically. If you have 20 years of experience of being indoctrinated regarding smart pointers and RAII and std::string, then the code you write isn't going to be very fast, but you'll be convinced that it's fast because the propaganda told you that. If everyone around you is writing similarly slow code (or slower code, because you are programming in C++ and they are in C# or Javascript), then it won't be obvious that you're going wrong. In this talk: th-cam.com/video/gWv_vUgbmug/w-d-xo.html I raise the point that I think almost no programmers in the modern day understand how to write fast code, really. Many programmers think they know what "optimization" is, but until you have done it for real, i.e. drilled down into the very basics of what your CPU is stalling on and how much, and then successfully fixed the problems and got your code running anywhere near peak theoretical speed, and then done that again maybe 2 or 3 times ... until that, you haven't really understood optimization at the low level, and saying you know how to optimize is a bit of Dunning-Kruger. And by "you" I include me in the general "you" -- I know how I used to "optimize" before I got serious about it, and yeah I made code a little faster probably, but I got nowhere near the potential of how fast that code really "should" go. This includes the times I programmed in assembly language -- it wasn't serious enough because I didn't look at what the chip was actually doing. I could turn your question around ... how do such "experienced engineers" as are building Photoshop at Adobe manage to create a program where it takes one second to open the New Document menu? (As seen in linked video). I don't think quantity of experience has much to do with it.
Ha, yea I watched that talk, and it was really good. I also agree with the experience thing. I'm personally much better at writing fast code than my coworkers that have been programming for 20-40 years simply because my experience is with games. That being said, by experience I meant the experience that people like Chandler(have you watched any of his talks?) presumably have. His day job consists of measuring and optimizing code, with, presumably, full knowledge of how modern hardware works. Also, I would like to make it clear that I am on board with replacing C++. I'm well aware that #inlcudes are archaic(and that they should have had modules from the start) and slow and templates weren't designed with meta programming in mind. I just meant to ask if those shortcomings are enough to justify the performance difference between clang and your compiler or whether you are prepared to say that you just know more about optimization than the clang/LLVM team.
I liked some talks of Chandler's I saw a while back (e.g. zero-cost abstractions talk), but sometime around a year ago he lost my benefit of the doubt. Chandler gave a talk where he explicitly called out me and Fabian and said we are clueless about UB. So then I was like, uh oh, he is going to provide some really good arguments for C++'s Undefined Behavior in his talk, that I wasn't aware of, I am going to be forced to adjust my worldview! And then ... his examples were the same lousy goofball integer shift and overflow stuff as always. At that point it was clear to me that the whole UB thing was truly misguided and broken (as opposed to being a difference in taste that I obstinately refused to agree with, or whatever) because there are clear and obvious solutions to the shift and overflow stuff that would both improve the compiler's ability to optimize and result in the programmer having a much clearer understanding of what the compiler is doing. All you'd have to do is change the semantics of the language a little, even just to the point of adding new integer types that people can optionally use if they want their code to be fast, and that have no impact otherwise. Okay, maybe you don't want to do that, but you have to at least then acknowledge that it is merely your own decision to exploit all this UB, rather than some kind of necessity, but no such admission took place in the talk. So I have to think they haven't even seriously tried to solve the problem. I came away from that talk with the conclusion that there is just a lot of cognitive capture in the C++ community and it prevents people from seeing problems clearly (I guess that should not be too big a surprise since this happens often in life). Maybe Chandler spends too many hours at conferences and in meetings and managing now, and not enough time solving real problems, I don't know! About your last paragraph .. To the degree that my compiler is faster than clang, or whatever, I wouldn't say that it's due to my knowledge of optimization, because as I said in the Reboot Develop talk, I have not spent very much time optimizing the compiler! The compile times you are seeing are the *baseline* speed, before I try very hard to make it fast! This is just how fast code is when you write it the simple way and don't try to be Modern C++ about it or whatever.
Cool, I'll have to check out the Q&A part :). I like where you are going with this language, and love that you are making these videos about it, very interesting stuff, keep up the good work :).
+Jonathan Blow here's the link to the official REBOOT video of your talk: th-cam.com/video/De0Am_QcZiQ/w-d-xo.html Maybe TH-cam will let you add this one to your channel! Hope could help. :)
I was just thinking about how we haven't had a demo in a while. I refresh TH-cam to see if anything's new and BAM! This pops up. Are you reading my mind?
I'm still confused about the fact that the stupid ; at the end of each line ist still there. Would be the first thing i've dropped when creating a new language. Using a special symbol to define a 99% normal situation instead of 1% of special cases is just plain stupid to keep imho.
Maybe you should give me the benefit of the doubt that I am not an idiot. If you don't understand why I am using semicolons, and you haven't built a programming language, there is at least a possibility that the deficit in understanding is on your end!
Kotlin, a language announced at the recent Google I/O to be a formally supported language for Android, doesn't use semicolons. So you should admit there's at least a possibility that semicolons are not absolutely essential in a programming language.
Love the focus on speed and optimized data storage. Most programmers have lost this art and are unfortunately creating bloated and slow software. And certainly the languages that I use today at work gives me no opportunity to even consider this problem. That is why I love coding for old 8 bit systems in machine code/assembly, because it keeps me sane and getting back that feeling of control of the hardware! Every byte counts!
Cool, Valve uses the same tech! One of their physics programmers gave a talk (it's somewhere on youtube) which mentioned that. It's awesome how easy it makes serializing and deserializing structs into files.
this might be the talk you are referencing, and it appears to be a good watch for more then just the pointers.. th-cam.com/video/Nsf2_Au6KxU/w-d-xo.html
If you had a way to specify a minimum object alignment on the underlying buffer, you should be able to 2x, 4x, ... the range of the relative pointer. (i.e if something can only be at offset 0, 2, 4 there is no need for an encoding that allows for offset 1).
EDIT: Ah yes, it's in the comment for 'possible future work' seen flying by at 31:39.
Keira Metz
Jonathan is the MAN! What a wonderful mind. I love you, your games and this channel! ;)
Yay JAI videos are back!
I would love to see more videos of you coding or dealing with / explaining different programming/game topics. I find them very educative and interesting to watch. I hope you have time to make more videos. Thanks for this one
37:10 "...by just ensmallning the pointerd..." ..ensmallning... Love it! :P
I really enjoy watching this video series. Glad its back!
Wish I had the time to watch all of your videos. They seem very informative. Have a 4 hour drive tomorrow, might be able to listen to a few.
Thank you for doing these.
This is one of the only demos of yours that I have felt I truly understood what was going on, at least in part. Mostly because I have done basically no C++ or game programming so I can't really relate to your lamenting on how poorly C++ does x.
Even still I really like your thought process and would be very excited to try out this language when it is made available. I suspect it would make it easier for me to try out some low-level optimizations (something I don't have much experience in).
Cheers!!!
How does relative pointers fit with SOA (128bit) pointers?
If you declare a s32 relative SOA pointer will it be 64bits?
Jon answered that on a stream: That would be 64bits but it's not working right now. Anyway he'll probably change the SOA behavior and he doesn't want to complicate it for now.
42:35 Wait! Have I understood correctly that the compiler looks for *_all_* workspaces in the program and builds something for each one of those? Nothing more required except setting the build-options?
Pretty much. When you say compiler_create_workspace you are saying "here is a new thing to compile" and the build_options says the details of how to compile it. The code shown in that segment is all of the code that was necessary to build that separate program.
Super interested if this allows having relocatable heaps, which would be super convenient for quick serialisation schemes
I've missed these, baby. Though I've been enjoying the gammin'
I recall there being a patent on storing pointers relative to the address of the pointer itself...
really?
Yep seems to be the case
Damn you're right...
www.google.com/patents/US6625718
The fact that you can patent something like this sounds like total bullshit to me but it looks legit. :/
It might be nigh unenforceable, but I'm still pretty sure that it would be able to go to court if whomever holds the patent at the moment doesn't agree with you?
It would probably lose, but court cases are expensive and a huge waste of time...
Technically not true draculatern, hence "patent trolls". However after a recent supreme court ruling at a minimum they cannot take advantage of how East Texas tended to favor the one bringing suit.
Since the relative pointer has a particular alignment, could you get more range by using element offsets rather than byte offsets? That is, multiply the relative pointer value by the element size before doing the rest of the steps involved in dereferencing it.
Or multiply by the alignment I mean, not the element size…
But the relative pointer *doesn't* have a particular alignment. It could point to a struct that just got loaded from disk, packed. If you want bigger numbers, use bigger numbers.
Ah, I just noticed +eloj's reply -- it looks like a comment appears on screen at 31:39 saying this feature could be added in the future.
Question. Is that pack functionality going to be available in the standard library for the language, or will we have to implement it ourselves? Also I hope you don't get in any trouble over relative pointers, because there's a (really, really stupid) patent "US 6625718 B1" as defined here www.google.com/patents/US6625718
damn, I used this technique back in 1995, they'll have to sue me or something.
The behavior of copying that struct (at 18:00) should probably be the way you had it already, imo. memcpy is a straightforward enough way to preserve the internal relativity, or so it seems to me.
If you don't want to say "slice" you could say "window", though I can see why that might also have too much baggage. Portion? Chunk?
"array view" Keep it simple.
Yeah, I hate when languages introduce "intuitive" new terminology. C's "double" is bad enough for god's sake, I don't care about your fucking runes.
I'm cool with slice.
It should be a "view". That terminology is relatively standard and agreed upon in C and C++. en.cppreference.com/w/cpp/string/basic_string_view. www.khronos.org/registry/vulkan/specs/1.0/apispec.html#_vkimageview_3
Even if you wanted to be different here, "view" says exactly what it is: a lightweight, non-owning handle that, by default, points to the whole thing. The most important thing is to convey how low-overhead and non-owning it is.
Rational Coder I kind of like 'lonoh' for 'low overhead non owning handle'. :)
I missed you.
idk anything about programming but i like hearing john talk xD
At 43:33 am i correct that if you were to switch around the "value" and "data" fields in the "NodeGeneral" struct, your two relative pointers would be pointing a NULL? That doesn't seem ideal, although i understand that some trade-off is necessary.
No. They can store offsets of 0 just fine. I talk about this in the Q&A (but should have covered it in the main talk).
back in asm and in with C (with macros) I used to do these relative to the base of the containing object (the logic being it was just that little bit easier to generate the address. 'load this field, add that value to the object pointer, done.'). then moving to C++ i gave in to the urge to c++-ify and made a c++ templated class for that sort of thing but considered storing the offset pointer relative to the actual pointer inferior.. it slightly frustrated me. I wished there was a way to silently pass or reference the 'this' of the enclosing scope or something
Was distracted so I hope it wasn't mentioned in the video, but does that mean assignment of such a pointer involves a conditional branch?
Written as C ints:
b = a == 0 ? 0 : (intptr_t)&a + a - (intptr_t)&b;
bloody_albatross Jon says relative pointers are resolved automatically at compile-time
I don't understand. How can something be solved a t compile time that depends on runtime data?
Because the type of the pointer (relative pointer to xxx) is known at compile time
The type of the pointer, yes, but not whether it's null or not.
I thought you meant it would resolve if it was a relative or absolute pointer at assignment time.
What exactly are you asking about then? How it provides some sort of safety net for not doing arithmetic on null pointers?
Jai reminds me a bit of pascal for some reason.I'm struggling to get my head around relative pointers at this point(er)
First, I would like to thank you for this feature. It is really needed.
Really, though, I just came to ask an unrelated question. Given how fast you have gotten your compile time for this language, what do you think the guys that work on clang/LLVM could be doing better? These kinds of videos by Chandler Carruth (th-cam.com/video/vElZc6zSIXM/w-d-xo.html) suggest to me that they care quite a bit about performance.
I think the entire culture of "Modern C++" leads to code that is slow and confusingly overcomplex.
I agree for the most part(certainly about the complexity...), but I meant something along the lines of handling #includes, templates, and/or general file I/O naively vs something more fundamental like slow syntactic/semantic processing that is just due to their coding style, which is where you could make that modern C++ argument.
How do you think such experienced engineers could inadvertently write slow C++ code?
Taking your opinion on modern C++ for granted, what do you think the main thing that jai(not sure if it's an acronym or what) is doing/will do to make it more obvious that you are writing slow code?
Right now, it looks like there's:
1. removal of hidden costs,
2. intuitive support for meta-programming up front and simplified/better support for generics, and
3. decoupling of data and procedures. Though, I don't think you can get away with not supporting dot calls (not sure if I missed the verdict on that one), and I think I can make a good case for them if it comes up in the future.
#includes are terrible for performance to begin with. They should go away. C++ is working toward that with 'modules' but I presume the result is going to be nasty and complicated, because everything in C++ is that way.
C++ templates were done in an unfortunate way to begin with. The only way to fix them is a do-over, but at this point that would mean scrapping 3/4 of C++, which they are not about to do.
I dunno. I just don't think 'saving C++' is a worthwhile project. Things get *much* better if you toss out all the old problems and start over.
About this:
> How do you think such experienced engineers could inadvertently write slow C++ code?
I think you are giving "experienced engineers" too much of the benefit of the doubt. Experience is good, but the exact nature of the experience matters critically. If you have 20 years of experience of being indoctrinated regarding smart pointers and RAII and std::string, then the code you write isn't going to be very fast, but you'll be convinced that it's fast because the propaganda told you that. If everyone around you is writing similarly slow code (or slower code, because you are programming in C++ and they are in C# or Javascript), then it won't be obvious that you're going wrong.
In this talk: th-cam.com/video/gWv_vUgbmug/w-d-xo.html
I raise the point that I think almost no programmers in the modern day understand how to write fast code, really. Many programmers think they know what "optimization" is, but until you have done it for real, i.e. drilled down into the very basics of what your CPU is stalling on and how much, and then successfully fixed the problems and got your code running anywhere near peak theoretical speed, and then done that again maybe 2 or 3 times ... until that, you haven't really understood optimization at the low level, and saying you know how to optimize is a bit of Dunning-Kruger. And by "you" I include me in the general "you" -- I know how I used to "optimize" before I got serious about it, and yeah I made code a little faster probably, but I got nowhere near the potential of how fast that code really "should" go. This includes the times I programmed in assembly language -- it wasn't serious enough because I didn't look at what the chip was actually doing.
I could turn your question around ... how do such "experienced engineers" as are building Photoshop at Adobe manage to create a program where it takes one second to open the New Document menu? (As seen in linked video). I don't think quantity of experience has much to do with it.
Ha, yea I watched that talk, and it was really good. I also agree with the experience thing. I'm personally much better at writing fast code than my coworkers that have been programming for 20-40 years simply because my experience is with games.
That being said, by experience I meant the experience that people like Chandler(have you watched any of his talks?) presumably have. His day job consists of measuring and optimizing code, with, presumably, full knowledge of how modern hardware works.
Also, I would like to make it clear that I am on board with replacing C++. I'm well aware that #inlcudes are archaic(and that they should have had modules from the start) and slow and templates weren't designed with meta programming in mind. I just meant to ask if those shortcomings are enough to justify the performance difference between clang and your compiler or whether you are prepared to say that you just know more about optimization than the clang/LLVM team.
I liked some talks of Chandler's I saw a while back (e.g. zero-cost abstractions talk), but sometime around a year ago he lost my benefit of the doubt. Chandler gave a talk where he explicitly called out me and Fabian and said we are clueless about UB. So then I was like, uh oh, he is going to provide some really good arguments for C++'s Undefined Behavior in his talk, that I wasn't aware of, I am going to be forced to adjust my worldview! And then ... his examples were the same lousy goofball integer shift and overflow stuff as always. At that point it was clear to me that the whole UB thing was truly misguided and broken (as opposed to being a difference in taste that I obstinately refused to agree with, or whatever) because there are clear and obvious solutions to the shift and overflow stuff that would both improve the compiler's ability to optimize and result in the programmer having a much clearer understanding of what the compiler is doing. All you'd have to do is change the semantics of the language a little, even just to the point of adding new integer types that people can optionally use if they want their code to be fast, and that have no impact otherwise. Okay, maybe you don't want to do that, but you have to at least then acknowledge that it is merely your own decision to exploit all this UB, rather than some kind of necessity, but no such admission took place in the talk. So I have to think they haven't even seriously tried to solve the problem. I came away from that talk with the conclusion that there is just a lot of cognitive capture in the C++ community and it prevents people from seeing problems clearly (I guess that should not be too big a surprise since this happens often in life). Maybe Chandler spends too many hours at conferences and in meetings and managing now, and not enough time solving real problems, I don't know!
About your last paragraph .. To the degree that my compiler is faster than clang, or whatever, I wouldn't say that it's due to my knowledge of optimization, because as I said in the Reboot Develop talk, I have not spent very much time optimizing the compiler! The compile times you are seeing are the *baseline* speed, before I try very hard to make it fast! This is just how fast code is when you write it the simple way and don't try to be Modern C++ about it or whatever.
If a null relative pointer has a value of 0 then does that mean that a limitation of relative pointers is that they can't point to themselves?
No; they can point at themselves fine. I demonstrate this in the Q&A.
Cool, I'll have to check out the Q&A part :). I like where you are going with this language, and love that you are making these videos about it, very interesting stuff, keep up the good work :).
37:05 "ensmallening the pointers" 😂
+Jonathan Blow here's the link to the official REBOOT video of your talk: th-cam.com/video/De0Am_QcZiQ/w-d-xo.html
Maybe TH-cam will let you add this one to your channel! Hope could help. :)
He's alive!
Emacs woo!
I was just thinking about how we haven't had a demo in a while. I refresh TH-cam to see if anything's new and BAM! This pops up. Are you reading my mind?
wow.. ancient terminal green colors...
turinreza but at some point he got new emacs colors
yaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay
I'm still confused about the fact that the stupid ; at the end of each line ist still there. Would be the first thing i've dropped when creating a new language. Using a special symbol to define a 99% normal situation instead of 1% of special cases is just plain stupid to keep imho.
Maybe you should give me the benefit of the doubt that I am not an idiot. If you don't understand why I am using semicolons, and you haven't built a programming language, there is at least a possibility that the deficit in understanding is on your end!
Kotlin, a language announced at the recent Google I/O to be a formally supported language for Android, doesn't use semicolons. So you should admit there's at least a possibility that semicolons are not absolutely essential in a programming language.
Lots of languages don't use semicolons. Stop wasting my time.
What the fuck.