It’s Faster Because It’s C • Hacker News Board

Re: It’s Faster Because It’s C

#41

Post by wheaties » Tue, Jul 13, 2010, 4:31 PM UTC

redcheetah wrote: post #37

wheaties wrote: post #18

When I was younger I would have agreed wholeheartedly with this article because he seems more knowledgeable. After a few years experience I would have disagreed with him. Now I'm experienced enough to realize I have no idea if he's right or wrong but he seems to make reasonable points. I've only worked in I/O bound, memory bound, and CPU bound code before (but never at the same time.) My hats off to anyone or group t…

I wonder if there are any startups out there who hire folks with "kernel developer" mentality/experience. I love dynamism and excitement of startup life but unfortunately it often comes with Ruby/JavaScript, which is fine but I prefer lower-level hacking: hardware interrupts, malloc-free environment, etc. I do believe startups who need such skills exist, they just seem to be quieter for some reason. :-(

Maybe not start-ups but I hear and I've seen postings at many hedge funds and their ilk for those that can do low latency algorithms. They're specifically looking for kernel level developers.

Re: It’s Faster Because It’s C

#42

Post by joe_the_user » Tue, Jul 13, 2010, 4:31 PM UTC

wheaties wrote: post #18

When I was younger I would have agreed wholeheartedly with this article because he seems more knowledgeable. After a few years experience I would have disagreed with him. Now I'm experienced enough to realize I have no idea if he's right or wrong but he seems to make reasonable points. I've only worked in I/O bound, memory bound, and CPU bound code before (but never at the same time.) My hats off to anyone or group t…

Reading the article, he discusses some places where language choice doesn't matter and some where it would (the unpredictable latency you get with Garbage collector even if average speed is the same). So it's not refreshingly undogmatic.

One thing the article doesn't mention is that Java once had a slow interpreter and now it has a potentially faster interpreter. When Java had a slow interpreter, then it would be inherently slow for a larger spectrum of problem - but still not all of them.

Re: It’s Faster Because It’s C

#43

Post by kunley » Tue, Jul 13, 2010, 4:33 PM UTC

" I’d even argue that the main reason kernel code tends to be efficient is not because it’s written in C but because it’s written with parallelism and reentrancy in mind, by people who understand those issues. A lot of code is faster not because it’s written in C but for the same reasons that it’s written in C. "

Brilliant.

I'd say that C programs are generally faster because C world has near-zero amount of mediocre and copy/paste programmers, so coders just know what they're doing.

Re: It’s Faster Because It’s C

#44

Post by btilly » Tue, Jul 13, 2010, 4:33 PM UTC

wheaties wrote: post #18

When I was younger I would have agreed wholeheartedly with this article because he seems more knowledgeable. After a few years experience I would have disagreed with him. Now I'm experienced enough to realize I have no idea if he's right or wrong but he seems to make reasonable points. I've only worked in I/O bound, memory bound, and CPU bound code before (but never at the same time.) My hats off to anyone or group t…

My experience says that he's exactly right.

I've had to sort out a lot of performance problems. Almost always they were algorithm problems, architecture problems, or some simple bottleneck. Only once have I encountered a performance problem which was best solved by writing in a lower level language. More than that, my experience says that people who brag about how they've designed for scalability have generally made stupid design mistakes that cost them huge amounts of performance.

In fact here is a performance tip. If you want performance, make sure you have verbose logging options written in. Because when you hit performance problems, it is incredibly valuable to flip logging on, take the logs, study them, and identify your performance problems that way. Try it. For most applications that will matter a lot more than what language you write it in.

Re: It’s Faster Because It’s C

#45

Post by kunley » Tue, Jul 13, 2010, 4:38 PM UTC

joe_the_user wrote: post #42

wheaties wrote: post #18

When I was younger I would have agreed wholeheartedly with this article because he seems more knowledgeable. After a few years experience I would have disagreed with him. Now I'm experienced enough to realize I have no idea if he's right or wrong but he seems to make reasonable points. I've only worked in I/O bound, memory bound, and CPU bound code before (but never at the same time.) My hats off to anyone or group t…

Reading the article, he discusses some places where language choice doesn't matter and some where it would (the unpredictable latency you get with Garbage collector even if average speed is the same). So it's not refreshingly undogmatic. One thing the article doesn't mention is that Java once had a slow interpreter and now it has a potentially faster interpreter. When Java had a slow interpreter, then it would be inh…

The Java problem is not that JVM is itself slow, but that Java is so inconvenient to use, that people use tons of stacks of libraries to accomplish even simplest things (think dependency injection) that JVM becomes bloated by loading and calling all these libraries, and in effect is slow.

I've seen most ridiculous stacktraces only in Java.

Re: It’s Faster Because It’s C

#46

Post by joe_the_user » Tue, Jul 13, 2010, 4:38 PM UTC

ramy_d wrote: post #24

tptacek wrote: post #22

No. C programs have fine-grained control over the memory layout of all their data, and thus are far better positioned to exploit caching in general and optimize for locality in particular. It's an attractive fallacy to suggest that most programs are I/O bound and thus are equally performant in Java and in C; while that statement does bode well for async code and poorly for threads, it's not as relevant for language c…

yeah i was wondering something. Let's say we are bound by I/O, wouldn't we reap more benefits by using lower level languages in the event that I/O boundaries improve? like faster drives or types of drives. Same applies for memory. shouldn't the paradigm be "least amounts of bottle necks possible"? Also the points mentioned by other comments are also valid (battery, VM behaviours) However, his final point, or at least…

Let's say we are bound by I/O, wouldn't we reap more benefits by using lower level languages in the event that I/O boundaries improve?

There are unlimited number of potential future requirements that a program might have to meet. You should only code for these if you have a concrete basis for believing these will become real at some point.

If there's a serious chance your sedan will do stock car racing, then you outfit it accordingly. Otherwise, that super-muffler's just an unnecessary expense and something more to break.

Edit: You'll notice that in average car, every part has about the same quality, power and durability. In a sense, engineering is actually about achieving the least cost and the largest number of bottle necks, since any unneeded quality is wasted time and money.

Re: It’s Faster Because It’s C

#47

Post by kunley » Tue, Jul 13, 2010, 4:40 PM UTC

redcheetah wrote: post #37

wheaties wrote: post #18

When I was younger I would have agreed wholeheartedly with this article because he seems more knowledgeable. After a few years experience I would have disagreed with him. Now I'm experienced enough to realize I have no idea if he's right or wrong but he seems to make reasonable points. I've only worked in I/O bound, memory bound, and CPU bound code before (but never at the same time.) My hats off to anyone or group t…

I wonder if there are any startups out there who hire folks with "kernel developer" mentality/experience. I love dynamism and excitement of startup life but unfortunately it often comes with Ruby/JavaScript, which is fine but I prefer lower-level hacking: hardware interrupts, malloc-free environment, etc. I do believe startups who need such skills exist, they just seem to be quieter for some reason. :-(

ksplice.com are hardcore low-level hackers.

Re: It’s Faster Because It’s C

#48

Post by a-priori » Tue, Jul 13, 2010, 4:40 PM UTC

mfukar wrote: post #32

_delirium wrote: post #27

Earlier quoted context omitted.

Compared to C that's true, but bloated libraries aren't exactly absent in the C++ world (one of many reasons that "C/C++" is usually a weird generalization). Nested templates of templates are all over the place, and as for pointers, it's common to wrap those too using one of the various smart-pointer classes. C often leads to bad algorithms, though, for the same reason it often leads to lean code tuned to the specifi…

" much hand-optimized 90s-era C code is now slower than more naive implementations, because the optimizations used to save some instructions often actively harm cache performance. " On the same hardware? That seems unlikely - do you have a specific example in mind?

He means that the hardware has changed. Micro-optimization these days mostly has to do with optimizing cache and memory I/O performance rather than reducing clock cycles as it was in the 90s.

Re: It’s Faster Because It’s C

#49

Post by a-priori » Tue, Jul 13, 2010, 4:41 PM UTC

kunley wrote: post #43

" I’d even argue that the main reason kernel code tends to be efficient is not because it’s written in C but because it’s written with parallelism and reentrancy in mind, by people who understand those issues. A lot of code is faster not because it’s written in C but for the same reasons that it’s written in C. " Brilliant. I'd say that C programs are generally faster because C world has near-zero amount of mediocre…

C world has near-zero amount of mediocre and copy/paste programmers, so coders just know what they're doing.

[Citation needed]

Re: It’s Faster Because It’s C

#50

Post by kunley » Tue, Jul 13, 2010, 4:43 PM UTC

cks wrote: post #12

"I’d even argue that the main reason kernel code tends to be efficient is not because it’s written in C but because it’s written with parallelism and reentrancy in mind, by people who understand those issues." With this arguing, isn't it reasonable to assume that a project Foo written in C or C++ is faster than an equivalent written in Java simply because the author writing project Foo in C/C++ likely understands per…

"With this arguing, isn't it reasonable to assume that a project Foo written in C or C++ is faster than an equivalent written in Java simply because the author writing project Foo in C/C++ likely understands performance by choosing C/C++ in the first place? (I am not saying anything about the performance of a certain language implementation)"

The point is that if someone is able to choose C/C++ means that he's much more smarter than many existing Java programmers.

Sad but true.