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

It’s Faster Because It’s C

pl.atyp.us

Post reply on HN
Print view View original

51–60 of 122 posts

Re: It’s Faster Because It’s C

#51

Post by jknupp »

btilly wrote: post #44
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…

In all of the performance sensitive systems I've worked on, "flipping logging on" in production is simply not an option for, well, performance reasons (i.e. the reason that it wasn't turned on in the first place). If you're then going to test in a non-production environment, why not just run it through a profiler rather than trying to divine performance problems from log statements?

Re: It’s Faster Because It’s C

#52

Post by eru »

Hoff wrote: post #28

This is the standard performance-tuning discussion, in a different guise. Until you explain what factor(s) you're optimizing for, "It's faster because it's written in (whatever)" is a canard. You can take that discussion in most any direction. Budget. Even free coders and open-source has its costs. Raw speed? Custom hardware? Hand-tweaked assembler? FPGA? Speed, but without the budget for bumming instructions? Archit…

Perhaps they are optimizing for getting coders that rather code C than Java?

Re: It’s Faster Because It’s C

#53

Post by btilly »

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?

Yes. On the same hardware. And I'm sure that a specific example was thought of.

To give one of several likely causes, CPU pipelines have grown much longer. As a result it is more important to avoid stalls these days. Naive code compiled with a modern compiler knows about the importance of this. For instance the compiler will know it can avoid a stall in certain cases by making sure that a read from memory that happens soon after a write obeys something called store to load forwarding restrictions. Doing that can mean extra code which would be slower on an old computer, but it is faster than a modern one.

Re: It’s Faster Because It’s C

#54

Post by btilly »

jknupp wrote: post #51
btilly wrote: post #44

Earlier quoted context omitted.

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…

In all of the performance sensitive systems I've worked on, "flipping logging on" in production is simply not an option for, well, performance reasons (i.e. the reason that it wasn't turned on in the first place). If you're then going to test in a non-production environment, why not just run it through a profiler rather than trying to divine performance problems from log statements?

Depending on your architecture, logging can be turned on selectively. Just log one process/thread/database handle/whatever. Sure that one will be slowed, but the rest of the system still runs at full speed so you're OK. This can be an invaluable tool.

For instance a tool I incorporated into one system would see a parameter to a web request and would issue a command to Oracle telling it to log everything that happened on the database for that connection, and then would turn it off afterwards. So, for instance, we could take a slow web page, add a parameter, and a minute later be studying a log generated by Oracle telling us exactly what that web request did, and where it spent its time.

Having the ability to selectively do this on the live production system against live data with a problematic request while it was being problematic was huge. We were tracking down problems that only showed up in production, under production load, so no amount of profiling in development would have helped. Using the same idea, every day we would just take one random database handle, turn logging on for half an hour, and use it as a canary to look for potential problems. We found a lot of things that way.

Addendum (added later) It is also worth noting that in many horizontally scaled systems you can trivially have a fair amount of logging, even in production, if you're willing to accept a constant factor overhead in inefficiency. This can be utterly invaluable in tracking down latency, bottlenecks, and other larger scalability problems. Every large system that I've seen that was well-run did this to some extent.

Re: It’s Faster Because It’s C

#55

Post by kunley »

a-priori wrote: post #49
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]

Citation is overrated. Today anyone can publish anything and be cited by another anyone.

Live in the industry for 15 years or so and observe for yourself. Carefully.

Re: It’s Faster Because It’s C

#56

Post by a-priori »

kunley wrote: post #55
a-priori wrote: post #49

Earlier quoted context omitted.

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

Citation is overrated. Today anyone can publish anything and be cited by another anyone. Live in the industry for 15 years or so and observe for yourself. Carefully.

What I meant was that you made a very bold claim without any justification. Are programmers who code in C categorically better than programmers who don't? I doubt it.

Re: It’s Faster Because It’s C

#57

Post by mfukar »

btilly wrote: post #53
mfukar wrote: post #32

Earlier quoted context omitted.

" 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?

Yes. On the same hardware. And I'm sure that a specific example was thought of. To give one of several likely causes, CPU pipelines have grown much longer. As a result it is more important to avoid stalls these days. Naive code compiled with a modern compiler knows about the importance of this. For instance the compiler will know it can avoid a stall in certain cases by making sure that a read from memory that happen…

Well, if we're talking about different hardware, this whole discussion is moot - CPU (not C-entral anymore..) architecture changes render "old" optimization techniques only situational today.

At any rate, the same is true for all languages, and _delirium's point is spot on: it's not the language that matters, it's the fact that bad (or slow, or inefficient, call it what you will) code is encountered regardless. It's time we stopped language wars, don't you think?

Re: It’s Faster Because It’s C

#58

Post by skybrian »

joe_the_user wrote: post #46
ramy_d wrote: post #24

Earlier quoted context omitted.

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 outf…

That's not a great analogy. Using cheaper components to cut costs requires more engineering effort; this is a form of optimization. For a prototype, you might just use more expensive components if it's convenient, since the per-unit cost doesn't matter much.

When writing software, there's no direct analogy because usually the components we build our programs out of have hardly any per-unit cost. We don't save any money by using a crappy third-party library over a high-quality one. Using a library with lots of unnecessary features may be cheaper both for prototyping and for the final product.

Re: It’s Faster Because It’s C

#59

Post by redrobot5050 »

preview wrote: post #31
aufreak3 wrote: post #7

Even when IO bound, you might want to spend less of that precious battery when you're not waiting. So even if your perceived speed doesn't change, the battery can tell the difference.

This is a great point. Power usage is growing in importance. I think power management APIs will continue to evolve. In the not too distance future, power will be another axis of optimization.

At the hardware level, it already is. And it seems in the Mobile Space, we are seeing that on the software side.

Re: It’s Faster Because It’s C

#60

Post by kunley »

a-priori wrote: post #56
kunley wrote: post #55

Earlier quoted context omitted.

Citation is overrated. Today anyone can publish anything and be cited by another anyone. Live in the industry for 15 years or so and observe for yourself. Carefully.

What I meant was that you made a very bold claim without any justification. Are programmers who code in C categorically better than programmers who don't? I doubt it.

Yes I know my claim, and I showed you a way to grasp it.

"Categorically": that's what you said. Just observe, instead of trying to apriori-tize the world.

Post reply on HN