I LOVE THIS TALK ! This is relaxing to watch, especially when the whole "slide" is growing up while he explains everything .... definitly one of the best talks ever in the cppcon :) !!!
In my experience warp-block-grid decomposition affects performance a lot in different way on different generations of GPUs, so "only one source for all GPUs" is very bad practice, it will work (thanx to PTX) but it will be very non-optimal on all but one GPUs. So, if you need really high-performance code, you need to know your target GPU before you run clang/CUDA or nvcc :(
In this case, doesn't it make sense to just write the kernel in the most-generic way and then vary the kernel launch parameters based on the detected hardware?
IANA hardware engineer, but I think the CPU cores want to be close to the L3 cache. If you put the cores all adjacent to each other, then they'd necessarily be far from their L3, which as you can see in the CPU, is giant, like 1/3 of the die.
He is clearly not sticking strictly to a script and he knows what points he want to cover. So when he tries to explain something he can do it in paper and in multiple ways instead of 1 way of a powerpoint presentation. I did not see any ppt with "look here is an explanation, but oh you did not understand? lets check slide number 2 here is another explanation of the same thing". presentations needs to be compact and "to the point" so if someone needs to explain 1 thing but a question has came up that someone can only make that second explanation in words not both in words and in graphically.
> What's the lecturer's reasoning behind not making a digital presentation? I'd reverse the question. Why *would* I make a digital presentation. It's what everyone else does, I guess, but I've never been too concerned by that... :) In some ways presenting the way that I want to present would be a lot *harder* with powerpoint, because I'd have no flexibility to change what I'm saying. For example, I give that list of architectural optimizations that are either omitted or simplified in a GPU. If I were using a digital presentation, I'd either have to put up the whole list before saying the words -- which sort of spoils it and distracts the audience (now they're reading rather than listening!) -- or I'd have to put up each word *after* I said it, which would mean I'd need to have the exact order of the list memorized. With the pen and paper, I can go with the flow. When I give presentations to smaller audiences, the pen-and-paper approach also lets me answer questions easily, go back to a previous slide, skip ahead to material I was going to present later based on a question, show two or three pages at once... There's a lot of flexibility afforded by this approach (none of which I use here, of course). The other reason I do it this way is, as a consumer, I like watching this kind of talk! Now, correlation is not causation: It could be that the thing I like is certain presenters, and they just happen to choose this style of presentation. But I have some evidence that the style itself makes a difference to me. The person in my past whose hardware setup I'm emulating most closely is Dan Boneh, one of my university professors. I thought he was a fantastic lecturer, but he also gave a few presentations in one of my classes using powerpoint, so I can make a comparison holding the presenter constant. :) The main downside for me is that it requires a *lot* of preparation. I gave this full one-hour presentation maybe ten times, either to myself or to smaller audiences, before this. I had written notes onstage with me, but they don't provide nearly the level of safety net that you'd get from a ppt. In particular, writing this much code was pretty scary to me, because I knew that nobody would raise a hand and correct a stupid mistake that the whole audience might see. In the end I've only found one (trivial) error in what I wrote, so I'm pretty happy about that. I usually get overwhelmingly positive feedback on this style, but interestingly I got a good amount of negative feedback from conference attendees in their survey feedback. Maybe it's better on youtube than it was in person, I dunno. On YT you can see both my face and the paper clearly, but that wasn't possible in person. I can't say how much of a difference it makes; I wasn't in the audience! Or maybe I should have printed out the code instead of writing it by hand; that was the main complaint as I read it. See also norvig.com/Gettysburg, which is how I feel most of my attempts at powerpoint'ing went before I switched to this style.
@@JustinLebar part of the criticism could be due to readability. Our brains process written words differently and it distracts from the task of understanding what the lecture is trying to say. Keep it simple and use a font that everyone can easily read without having to do extra processing :) For example: Is that a --ldg or an __ldg. Why am I even thinking this? I should be focused on what you are communicating not the ambiguity (I enjoyed the talk, thank you for presenting)
I'm not an expert, but I can't imagine how you could big int or arbitrary-precision computations on a GPU (at least, not efficiently). The best I can figure is having big (but fixed-sized) numbers, and writing GPU-efficient operations tailored to that specific number size. This way, you eliminate non-fixed-sized loops and non-fixed-sized data structures. Anyhow, that's just my intuition, I'd be happy to be proven wrong.
![[LIVE] : ONE ลุมพินี 82 วันนี้!! คู่เอก | ยอดไอคิว vs อับดัลลาห์](http://i.ytimg.com/vi/hSsyTl_9bqs/mqdefault.jpg)
I LOVE THIS TALK !
This is relaxing to watch, especially when the whole "slide" is growing up while he explains everything .... definitly one of the best talks ever in the cppcon :) !!!
agree, I'm kind of baffled by the dislikes.
Agreed. This is an amazing talk.
this is amazing ! one of the best presentation in CppCon 2016
Beautiful. Completely blown away by the lucidity of this.
Thank you so much for your comment.
Very good way of presenting CUDA, especially the lecture like way makes it a lot more enjoyable to watch.
Best intro to CUDA I've ever seen :-) And the drawing/writing is awesome.
I am very very impressed with this talk.
Thank you Justin. The talk is refreshing departure from normal power point.
thanks for putting these talks up!
I liked his way of presentation
In my experience warp-block-grid decomposition affects performance a lot in different way on different generations of GPUs, so "only one source for all GPUs" is very bad practice, it will work (thanx to PTX) but it will be very non-optimal on all but one GPUs. So, if you need really high-performance code, you need to know your target GPU before you run clang/CUDA or nvcc :(
In this case, doesn't it make sense to just write the kernel in the most-generic way and then vary the kernel launch parameters based on the detected hardware?
Awesome presentation!
Excellent speaker!!!!
I wonder some compiler benchmarking, could you give me some advices? thx~
I really like his hand motions :)
Really great! Thanks.
Amazing talk, great job
Please, what camera + stand did you use?
Interestingly I think I posted an answer to this years ago, but TH-cam took it down. Guess you'll have to find one yourself (or email me, I suppose!).
Which C++ compiler are we actually using, how do we debug, if you want to do this in windows?
Do blocked threads ever get stuck in the queue? Like, is there ordering by wait time?
So, ptx is basically a .NET on GPU?
How come the 18 cores are so spread out? Would it not be easier to arrange them in a grid?
IANA hardware engineer, but I think the CPU cores want to be close to the L3 cache. If you put the cores all adjacent to each other, then they'd necessarily be far from their L3, which as you can see in the CPU, is giant, like 1/3 of the die.
What's the lecturer's reasoning behind not making a digital presentation?
He is clearly not sticking strictly to a script and he knows what points he want to cover. So when he tries to explain something he can do it in paper and in multiple ways instead of 1 way of a powerpoint presentation. I did not see any ppt with "look here is an explanation, but oh you did not understand? lets check slide number 2 here is another explanation of the same thing". presentations needs to be compact and "to the point" so if someone needs to explain 1 thing but a question has came up that someone can only make that second explanation in words not both in words and in graphically.
> What's the lecturer's reasoning behind not making a digital presentation?
I'd reverse the question. Why *would* I make a digital presentation. It's what everyone else does, I guess, but I've never been too concerned by that... :)
In some ways presenting the way that I want to present would be a lot *harder* with powerpoint, because I'd have no flexibility to change what I'm saying. For example, I give that list of architectural optimizations that are either omitted or simplified in a GPU. If I were using a digital presentation, I'd either have to put up the whole list before saying the words -- which sort of spoils it and distracts the audience (now they're reading rather than listening!) -- or I'd have to put up each word *after* I said it, which would mean I'd need to have the exact order of the list memorized. With the pen and paper, I can go with the flow.
When I give presentations to smaller audiences, the pen-and-paper approach also lets me answer questions easily, go back to a previous slide, skip ahead to material I was going to present later based on a question, show two or three pages at once... There's a lot of flexibility afforded by this approach (none of which I use here, of course).
The other reason I do it this way is, as a consumer, I like watching this kind of talk! Now, correlation is not causation: It could be that the thing I like is certain presenters, and they just happen to choose this style of presentation. But I have some evidence that the style itself makes a difference to me. The person in my past whose hardware setup I'm emulating most closely is Dan Boneh, one of my university professors. I thought he was a fantastic lecturer, but he also gave a few presentations in one of my classes using powerpoint, so I can make a comparison holding the presenter constant. :)
The main downside for me is that it requires a *lot* of preparation. I gave this full one-hour presentation maybe ten times, either to myself or to smaller audiences, before this. I had written notes onstage with me, but they don't provide nearly the level of safety net that you'd get from a ppt. In particular, writing this much code was pretty scary to me, because I knew that nobody would raise a hand and correct a stupid mistake that the whole audience might see. In the end I've only found one (trivial) error in what I wrote, so I'm pretty happy about that.
I usually get overwhelmingly positive feedback on this style, but interestingly I got a good amount of negative feedback from conference attendees in their survey feedback. Maybe it's better on youtube than it was in person, I dunno. On YT you can see both my face and the paper clearly, but that wasn't possible in person. I can't say how much of a difference it makes; I wasn't in the audience! Or maybe I should have printed out the code instead of writing it by hand; that was the main complaint as I read it.
See also norvig.com/Gettysburg, which is how I feel most of my attempts at powerpoint'ing went before I switched to this style.
@@JustinLebar part of the criticism could be due to readability. Our brains process written words differently and it distracts from the task of understanding what the lecture is trying to say. Keep it simple and use a font that everyone can easily read without having to do extra processing :) For example: Is that a --ldg or an __ldg. Why am I even thinking this? I should be focused on what you are communicating not the ambiguity (I enjoyed the talk, thank you for presenting)
Can CUDA/OpenCL handle GMP? AFAIK I have to "manually import" that into CUDA code.
I'm not an expert, but I can't imagine how you could big int or arbitrary-precision computations on a GPU (at least, not efficiently). The best I can figure is having big (but fixed-sized) numbers, and writing GPU-efficient operations tailored to that specific number size. This way, you eliminate non-fixed-sized loops and non-fixed-sized data structures.
Anyhow, that's just my intuition, I'd be happy to be proven wrong.