Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds on C++

harmful.cat-v.org

Post reply on HN
Print view View original

131–140 of 190 posts

Re: Linus Torvalds on C++

#131

Post by brodd »

winestock wrote: post #52
nxn wrote: post #6

Earlier quoted context omitted.

Haven't seen it. I've seen many other examples of Torvalds being an ass, but I don't bother to keep track really. It does make me wonder though how he's able to get away with responses like that, when most other "founders" (not sure what the proper term here really is) would have the majority of their users/supporters just go elsewhere. EDIT: ... Let alone have supporters who get defensive enough to start downvoting…

This man is being downvoted unfairly. I've read Torvalds' post at the top of the page. I've also read the balance of opinion on this page. The majority view is that C++ really is a terrible language for writing a kernel. Fine, I accept that. Now re-read Torvalds' post. How many people here would want to work with someone who regularly expresses himself like that? I know, I know; substance is more important than image…

I'd say life's too short to beat around the bush.

Re: Linus Torvalds on C++

#132

Post by cageface »

cygx wrote: post #126
cageface wrote: post #122

Earlier quoted context omitted.

C++ can actually be faster because it doesn't throw away as much type information. A good, typed C++ quicksort implementation, for example, will be faster than a C version using void*.

One of the reasons for the performance difference is that you can't inline into the libc DLL blob: If you use qsort(), you'll get a lot of overhead from calling the comparison function. If you use a custom quicksort implementation and put it into the same translation unit as the comparison function (or compile statically and use link-time optimizations with a sufficiently advanced compiler) you can get the same perfo…

Function call overhead is only one of the issues with the C version based on void pointers.

Check out Stroustrup's keynote at Going Native 2012 for more details: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

Re: Linus Torvalds on C++

#133

Post by gsg »

shin_lao wrote: post #116
kabdib wrote: post #55

I use C and C++ extensively (30+ years writing C, 25 or so writing C++). I much prefer C when writing systems-level code. It's simpler and a lot more predictable. You don't get the illusion that things like memory management are free. I /have/ written drivers in C++. Here you have to be very careful about memory allocation (calling 'new' in an interrupt handler is usually death, though I've also written very speciali…

#include is hardly going to work at the first insertion that will call the allocator. The argument "let's use a castrated language to avoid mistakes" falls short. What about communication within the team? Properly used and tailored, the STL is extremely adequate to kernel development. The power of the template engine enables the compiler to do some very clever optimizations. More information: http://www.osronline.com…

Huh? That link claims "The STL will not work in kernel mode and cannot be used", which is not much of a surprise given the STL's use of exceptions and dynamic allocation.

In any case, kernel guys seem to prefer their data structures in intrusive style rather than the container style ubiquitous throughout the C++ standard library. (For an example, see the intrusive list and red-black tree implementations in the Linux kernel.) Intrusive structures allow for exactly the kind of low allocation, very memory friendly layout that kernel developers are looking for - no clever optimisations necessary.

C++ features like stronger type checking, more careful casts and RAII are a more compelling argument for the language.

Re: Linus Torvalds on C++

#134

Post by cageface »

zoul wrote: post #125
cageface wrote: post #121

Earlier quoted context omitted.

The problem is that Obj-C message passing is always going to have a cost. STL implementations can inline accessors, for instance, to provide containers and algorithms with essentially zero overhead that can even be faster than raw C because the compiler has more type information.

That’s a non-issue for the vast majority of people. As an example, I have written games in Objective-C for the first iPhones. In a game running at 50 fps you have about 20 ms to get a single frame out, and still I could freely use message passing in the inner game loop without giving it a thought. See also some older measurements by Mike Ash: http://goo.gl/DBTPE .

An Obj-C message is still about 5x slower than a C++ virtual function call, but even that is too slow for inner loops of expensive algorithms. For example, I'm doing DSP at 44.1k ops per second and I can only afford about one virtual function call for every sixteen samples but I can put my samples in an STL vector with no access overhead vs a raw array.

It's true that most people don't need the performance you can get with C++ but if you do it's still really your only serious option.

Re: Linus Torvalds on C++

#135

Post by [deleted] »

acqq wrote: post #127
cageface wrote: post #120

Earlier quoted context omitted.

Notice the dates on these papers though. 2005 and 2007 are a long time ago in C++ compiler land. I'm using the STL in very low latency DSP code with zero problems. You have to make sure you don't allocate memory in realtime callbacks but that's just as true of malloc.

Dates are irrelevant if you really want to control where something gets allocated. Last time I've checked there weren't the level of control described in the linked articles in "standard" C++. If you know how I can achieve it, please write, but please don't dismiss my need with "you wouldn't notice everything is fast enough it's 2012."

[deleted]

Re: Linus Torvalds on C++

#136

Post by cageface »

acqq wrote: post #127
cageface wrote: post #120

Earlier quoted context omitted.

Notice the dates on these papers though. 2005 and 2007 are a long time ago in C++ compiler land. I'm using the STL in very low latency DSP code with zero problems. You have to make sure you don't allocate memory in realtime callbacks but that's just as true of malloc.

Dates are irrelevant if you really want to control where something gets allocated. Last time I've checked there weren't the level of control described in the linked articles in "standard" C++. If you know how I can achieve it, please write, but please don't dismiss my need with "you wouldn't notice everything is fast enough it's 2012."

Can you name any language that does give you that level of control in its standard collection classes? At least C++ gives you the power to define your own if you really need to.

Re: Linus Torvalds on C++

#137

Post by muyuu »

kabdib wrote: post #55

I use C and C++ extensively (30+ years writing C, 25 or so writing C++). I much prefer C when writing systems-level code. It's simpler and a lot more predictable. You don't get the illusion that things like memory management are free. I /have/ written drivers in C++. Here you have to be very careful about memory allocation (calling 'new' in an interrupt handler is usually death, though I've also written very speciali…

For my low level stuff I use C with namespaces. Seriously. C with namespaces beats the hell out of both C and C++ for most stuff. You can still link to C and C++, and you don't need to worry about the myriad of quirks you have in C++ and its compilers, while you can have some decent organisation in your code.

Re: Linus Torvalds on C++

#139

Post by cbsmith »

gsg wrote: post #133
shin_lao wrote: post #116

Earlier quoted context omitted.

#include is hardly going to work at the first insertion that will call the allocator. The argument "let's use a castrated language to avoid mistakes" falls short. What about communication within the team? Properly used and tailored, the STL is extremely adequate to kernel development. The power of the template engine enables the compiler to do some very clever optimizations. More information: http://www.osronline.com…

Huh? That link claims "The STL will not work in kernel mode and cannot be used", which is not much of a surprise given the STL's use of exceptions and dynamic allocation. In any case, kernel guys seem to prefer their data structures in intrusive style rather than the container style ubiquitous throughout the C++ standard library. (For an example, see the intrusive list and red-black tree implementations in the Linux…

Intrusive structures can be done in nice clean ways in C++. See policy based design.

Re: Linus Torvalds on C++

#140

Post by zoul »

cageface wrote: post #134
zoul wrote: post #125

Earlier quoted context omitted.

That’s a non-issue for the vast majority of people. As an example, I have written games in Objective-C for the first iPhones. In a game running at 50 fps you have about 20 ms to get a single frame out, and still I could freely use message passing in the inner game loop without giving it a thought. See also some older measurements by Mike Ash: http://goo.gl/DBTPE .

An Obj-C message is still about 5x slower than a C++ virtual function call, but even that is too slow for inner loops of expensive algorithms. For example, I'm doing DSP at 44.1k ops per second and I can only afford about one virtual function call for every sixteen samples but I can put my samples in an STL vector with no access overhead vs a raw array. It's true that most people don't need the performance you can ge…

According to Mike’s measurements I linked above a cached Objective-C message send is faster than C++ virtual method call, so in a loop both languages should come pretty close. You can also get a pointer to the function implementing a method and call it directly. But I think we now understand each other – yes, Objective-C is not as fast as C++ in some cases, but those cases only matter to a very small number of people.
Post reply on HN