| |||||||||||||
Quote of the weekQuote of the weekPosted Dec 9, 2004 18:01 UTC (Thu) by iabervon (subscriber, #722)In reply to: Quote of the week by simlo Parent article: Quote of the week
For (1), I think kernel developers tend to consider pointers to structs of function pointers to be more clear than virtual functions, because it is easier to see exactly what has virtual functions and exactly what code fulfills each role in a particular case.
I haven't looked at Ingo's patch, but any problems which prohibited a compile-time solution in C (probably passing locks of unknown implementation through another function) would also prohibit it in C++, and C++ would then general virtual function calls, which would then be prohibitively expensive for such fast-path code. The reason for doing that sort of ugly thing is really that you have a special case with critical performance, and you have to open-code such things in any language.
C++ does have some advantages in type-checking, but C compilers warn about cases where these checks are either impossible or are violated, with the exception of some of the C++ checks which are actually detrimental. Sparse also does better type-checking than C++ supports, since it allows project-defined special conditions (like typed pointers to values in a different address space).
Actually, now I'm curious as to how hard it would be to get sparse to support "struct list_head * __of(struct dcookie_struct)" and type-check that like C++ templates or Java generic types.
(Log in to post comments)
Quote of the week Posted Dec 9, 2004 21:29 UTC (Thu) by simlo (subscriber, #10866) [Link] I haven't looked at Ingo's patch, but any problems which prohibited a compile-time solution in C (probably passing locks of unknown implementation through another function) would also prohibit it in C++, and C++ would then general virtual function calls, which would then be prohibitively expensive for such fast-path code. The reason for doing that sort of ugly thing is really that you have a special case with critical performance, and you have to open-code such things in any language.Ofcourse you wouldn't do it by virtual functions in C++! You use virtual methods when you want to branch out run-time, not compile time. In C++ you simply define two classes with the same public methods. In this case class spinlock and class mutex with public methods lock() and unlock(). Then all code can compile with no further change no matter if you declare your lock by "mutex mylock;" or by "spinlock mylock;". The compiler sees a object with a lock() method and calls the right one (might be inlined). No branching at all. If you then want a flat function interface which matches the current one you can make a very simple templates to generate lock() and unlock() functions. The way Ingo have done it in flat C is by doing making a macro containing "if(TYPE_EQUAL(lock), mutex) lock_mutex((mutex_t*)lock) else if(TYPE_EQUAL(lock, raw_spinlock_t)...." I know, with -O2 this wont actually generate a branching code but it is very, very ugly. C++ is a huge benifit to people who know C++. It will _not_ make inefficient code unless you use it the wrong way ofcourse (see the above examble). On the contrary you can do more efficient code since you can do a lot of the stuff compile time. But to avoid complexity stay away trying smart templates combined with operator overloading. THAT is hell figure out when it can't compile. On the other hand when it can compile there are very few errors in the resulting program due to the strong type-checking.
Quote of the week Posted Dec 13, 2004 7:10 UTC (Mon) by hppnq (guest, #14462) [Link] Well, think of it as a work of art. You probably wouldn't have immediately recognized David when Michelangelo started hammering away. I'm quite confident that this will all be forgotten once Ingo has hammered a bit more.As a side note, ugliness is not necessarily bad, because it will keep urging people to fix the associated problem.
Open-code? Posted Dec 14, 2004 19:41 UTC (Tue) by Max.Hyre (subscriber, #1054) [Link] What does ``open-code'' mean in this context? So far, I've not run across anything that would fit this use. Of course, I tried Google:
Open-code? Posted Dec 14, 2004 21:06 UTC (Tue) by iabervon (subscriber, #722) [Link] Write out the full code that the convenient syntax would stand for, so that you can apply some optimizations based on information the compiler wouldn't have. So rather than having a C++ virtual method or using a function pointer, you'd actually write out tests and calls for all of the functions it could be, because the time to call a function pointer would be significant.
|
|||||||||||||