I've finished reading the Larrabee paper, linked in the realtimerendering blog. Very nice, intresting in general, even if you're not doing rendering... And it has a few very nice references too.
It seems that my old Pentium UV pipes cycle-counting abilities will be useful again... yeah!
I'm wondering how it can succeed commercially... It's so different from a GPU that it will require a custom rendering path in you application to be used properly, wonder how many will do that as nothing that you can do on Larrabee is replicable on other GPUs... Maybe, if its price is in the rage of standard GPUs and its speed with DirectX (or a similar API) is comparable... or if they manage to include it in a consolle. Anyway, it's exciting, and a little bit scarying too. We'll see.
I've also found a nice, old article about Xenos (the 360 Gpu) that could be an intresting read if you don't have access to the 360 sdk.
Warning: another anti-C++ rant follows (I've warned you, don't complain if you don't like what you read or if you find it boring...)
Last but not least, I've been watching to a nice presentation by Stroustrup that he gave at university of Waterloo, on C++0x, it's not new but it's very intresting. It shows again how C++ is at an evolutionary end.
Key things you'll learn from it: C++ design process is incredibly slow and constrained, C++ won't ever deprecate features so it might only grow (even if Bjarne would like to do so, but he says that he was unable to convince the compiler vendors...), not change. That means that all the problems and restrictions imposed by the C compatibility and by straight errors in the first version of the language won't be addressed. That also means that C++ is almost at its end, as it's already enormous and it can't shrink, and there is a limit to the number of things a programmer can know about any language. C++ is already so complicated that some university professors use its function resolving rules as "triky" questions during exams...
You will also hear the word "performance" each minute or so. We can't do that because we care about performances, we are not stupid windows programmers! Well, Bjarne, if going "low level" means caring about performances, then why aren't we all using assembly? Maybe because writing programs in assembly was so painful that not only become impractical, but was also hampering performances, as it was hard enough to write a working program, let's not talk about profiling and optimizing it... Try today to write a complete program in assembly that's faster than the same written in C (on a modern out-of-core processor I mean, of course on C64 assembly is still a nice choice)... So the equation higher level languages == less performance is very simple and very wrong in my opinion, and we have historical proofs of that. C++ is dead, it's only the funeral that's long and painful (especially when incredilink takes five minute to link our pretty-optimized-for-build-times solution).
I can give C++ a point for supporting all the design-wise optimizations pretty well (i.e. mature optimizations, the ones you have to do early on, that are really the only ones that matter, for function level optimizations you could well use assembly in a few places, if you have the time, that is something that's more likely to happen in a language that does not waste all of it in the compile/link cycle), while other languages still don't allow some of them (i.e. it's hard to predict memory locality in C#, and thus to optimize a design to be cache efficient, and there's no easy way to write custom memory managers to overcome that too).
Still C++ does not support them all, and that's why when performances really matter, we use compiler specific extensions to C++, i.e. alignment/packing & vector data types... The wikipedia C++0x page does not include the C99 restrict keyword as a feature of the language but I did not do any further research on that, I hope it's only a mistake of that article... Even the multithreading support they want to add seems to be pretty basic (even compared to existing and well supported extensions like OpenMP), quite disappointing for a language that's performance driven, even more considering that you'll probably get a stable and widespread implementation of it in ten years from now...
P.S. it's also nice to know that the standard commitee prefers library functions to language extensions, and prefers to build an extensible language over giving natively a specific functionality. Very nice! It would be even a nicer idea if C++ was not one of the messiest languages to extend... Anyone that had the priviledge of seeing a error message from a std container should agree with me. And that is only the standard library that's been made together with the language, it's not really an effort of a third party to extend it... Boost is, and it's nice, and it's also a clear proof that you have to be incredibly expert to make even a trivial extension and kinda expert to use and understand them after someone, more expert than you, have made one! Well I'll stop there, otherwise I'll turn this "small update" post into another "c++ is bad" one...
It seems that my old Pentium UV pipes cycle-counting abilities will be useful again... yeah!
I'm wondering how it can succeed commercially... It's so different from a GPU that it will require a custom rendering path in you application to be used properly, wonder how many will do that as nothing that you can do on Larrabee is replicable on other GPUs... Maybe, if its price is in the rage of standard GPUs and its speed with DirectX (or a similar API) is comparable... or if they manage to include it in a consolle. Anyway, it's exciting, and a little bit scarying too. We'll see.
I've also found a nice, old article about Xenos (the 360 Gpu) that could be an intresting read if you don't have access to the 360 sdk.
Warning: another anti-C++ rant follows (I've warned you, don't complain if you don't like what you read or if you find it boring...)
Last but not least, I've been watching to a nice presentation by Stroustrup that he gave at university of Waterloo, on C++0x, it's not new but it's very intresting. It shows again how C++ is at an evolutionary end.
Key things you'll learn from it: C++ design process is incredibly slow and constrained, C++ won't ever deprecate features so it might only grow (even if Bjarne would like to do so, but he says that he was unable to convince the compiler vendors...), not change. That means that all the problems and restrictions imposed by the C compatibility and by straight errors in the first version of the language won't be addressed. That also means that C++ is almost at its end, as it's already enormous and it can't shrink, and there is a limit to the number of things a programmer can know about any language. C++ is already so complicated that some university professors use its function resolving rules as "triky" questions during exams...
You will also hear the word "performance" each minute or so. We can't do that because we care about performances, we are not stupid windows programmers! Well, Bjarne, if going "low level" means caring about performances, then why aren't we all using assembly? Maybe because writing programs in assembly was so painful that not only become impractical, but was also hampering performances, as it was hard enough to write a working program, let's not talk about profiling and optimizing it... Try today to write a complete program in assembly that's faster than the same written in C (on a modern out-of-core processor I mean, of course on C64 assembly is still a nice choice)... So the equation higher level languages == less performance is very simple and very wrong in my opinion, and we have historical proofs of that. C++ is dead, it's only the funeral that's long and painful (especially when incredilink takes five minute to link our pretty-optimized-for-build-times solution).
I can give C++ a point for supporting all the design-wise optimizations pretty well (i.e. mature optimizations, the ones you have to do early on, that are really the only ones that matter, for function level optimizations you could well use assembly in a few places, if you have the time, that is something that's more likely to happen in a language that does not waste all of it in the compile/link cycle), while other languages still don't allow some of them (i.e. it's hard to predict memory locality in C#, and thus to optimize a design to be cache efficient, and there's no easy way to write custom memory managers to overcome that too).
Still C++ does not support them all, and that's why when performances really matter, we use compiler specific extensions to C++, i.e. alignment/packing & vector data types... The wikipedia C++0x page does not include the C99 restrict keyword as a feature of the language but I did not do any further research on that, I hope it's only a mistake of that article... Even the multithreading support they want to add seems to be pretty basic (even compared to existing and well supported extensions like OpenMP), quite disappointing for a language that's performance driven, even more considering that you'll probably get a stable and widespread implementation of it in ten years from now...
P.S. it's also nice to know that the standard commitee prefers library functions to language extensions, and prefers to build an extensible language over giving natively a specific functionality. Very nice! It would be even a nicer idea if C++ was not one of the messiest languages to extend... Anyone that had the priviledge of seeing a error message from a std container should agree with me. And that is only the standard library that's been made together with the language, it's not really an effort of a third party to extend it... Boost is, and it's nice, and it's also a clear proof that you have to be incredibly expert to make even a trivial extension and kinda expert to use and understand them after someone, more expert than you, have made one! Well I'll stop there, otherwise I'll turn this "small update" post into another "c++ is bad" one...
11 comments:
Hi Angelo
ok, assume that C++ is dead: alternatives in your opinion? I've always thought that object oriented programming is limited (doh!) and preferred C, but for job reasons (everybody uses C++) I code in C++. Ahhh... I remeber the old good days with Watcom C!!! :)
Scala is a nice 'scalable' language, though not sure if it is suitable for gamedev..
Nice linking to a completely bogus comparison of x360 vs ps3 power. Provides some laughs.
And again, C++ is bad if you use it in a bad way. Make a small library of useful objects and macros and stick to C-like C++.
Universities and tutorial-sites teach C++ in the worst way possible, and thus you see newbs trying to use all its features, to have their code turn into a disgusting furball. A student, that learnt C beforehand and used it for some time, will be many times more productive and produce clear tight code.
In C++ you can add almost all conveniences of other languages.
Riccardo: we're still using a dead language exactly because we lack alternatives, I have great hopes on C# as I already said in older posts. We'll see.
Michael: no, I don't think that scala is suitable for game development. Unfortunately the JVM itself is not nice for that purpose too.
Anonymous: I've removed the link to the ps3 vs 360 comparison as it seems it wasn't clear that it was a joke... :D And I wonder which other languages have you tried if you think that in C-like C++ you can have everything...
Angelo: last warning - stop whining about C++ or we gonna call a couple pipe-hittin' niggers, who'll go to work on you with a pair of pliers and a blow torch.
And by the way, we know you are getting paid by Microsoft for this money-oriented language (C#) propaganda.
D is nice but I don't see much adoption of it now, while C# is used for tools almost everywere, it used for pc and 360 "indie" games with XNA and there are also a couple of AAA games using it as their main programming language, so it's gaining momentum. Surely it's not perfect yet, my main concern is about the inability of controlling memory locality. But that's not a huge deal if you're writing your own CIL->native code compiler, and we can hope that those issues could be solved in future versions of the language if M$ is serious about its use in videogames...
Hi, I won't argue on which language is better, I'd like to ask You for something more informationabout Pentium UV pipe cycle counting. I'm really interested in and I hope that one of following posts on Your blog will tell us something more about it.
Maybe You have some references that is worth reading?
Cheers
mateusz: Agner Fog has everything you need: http://www.agner.org/optimize/
Basically Pentium I was still a in-order CPU so you could easily predict how instruction did get executed by its two pipelines (U and V). The U one can accept any instruction, the V is a limited one, with a little care you could structure your assembly routines to always or almost always use both (thus executing two instructions per cycle).
Thanks, those seem to be great documents :)
You are such a C# fanboy no if's and's or but's about it. Go home and let the big boys do the real man's work.
Kiddo, I'm not a fanboy of anything, I have a strong interest in computer languages, and I know many, many of them. C# is a fine one, but just one. Anyway your arguments really persuaded me you're an (anonymous) jerk. Kiss my ass.
Post a Comment