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

61–70 of 122 posts

Re: It’s Faster Because It’s C

#61

Post by mcantor »

steveklabnik wrote: post #25
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…

> 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. Slightly offtopic, but one of the things I love about software is that it's trained me to recognize patterns in everything. Abstrac…

I think along these lines every time someone mentions the Dunning-Kruger effect, which is frequent these days on Hacker News. It reminds me of a funny aphorism I once heard about higher education:

First you get your Bachelor's Degree, and you think you know everything. Then you get your Master's Degree, and you realize you don't know anything. Finally, you get your Doctorate, and you realize that nobody knows anything.

Finding those patterns between disciplines is always a delight--there is a surprising amount of crossover between many fields of study and human behavior. Programming was where I first found that humility is very positively correlated with competence, and the same principle shows up in a lot of other places.

Re: It’s Faster Because It’s C

#62

Post by silvestrov »

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…

A lot of average C programmers write high-performance linked-lists in C, while they could have used high-performance hashtables in Python/Ruby/Java with the same programming effort.

(and no programs are high-performance if they have a pointer bug that makes the program crash).

"The difference between theory and practice is small in theory and large in practice..."

Re: It’s Faster Because It’s C

#63

Post by btilly »

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…

Moore's law says that CPUs improve faster than I/O. Therefore any program that is I/O bound today is likely to be I/O bound for every future generation of hardware. And programs that are not I/O bound today, may become so down the road.

Incidentally on the final point, there was an interesting test that was run many years ago. Multiple teams were given the same spec, but were each told to optimize for a different characteristics (speed of development, speed of execution, maintainability, memory use, etc). Most of the teams managed to come in #1 on what they were trying to optimize for. The team that optimized for maintainability came in #2 on most other characteristics. The team that optimized for speed of execution came in last on most other characteristics.

The lesson from this is that a consistent focus on maintainable code results in more of everything else you need. Yes, there really are times that you're writing throw-away code and can forget all that. But by default, code well and let the other details take care of themselves.

Re: It’s Faster Because It’s C

#64

Post by petdog »

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

Moore's law says that CPUs improve faster than I/O. Therefore any program that is I/O bound today is likely to be I/O bound for every future generation of hardware. And programs that are not I/O bound today, may become so down the road. Incidentally on the final point, there was an interesting test that was run many years ago. Multiple teams were given the same spec, but were each told to optimize for a different cha…

> there was an interesting test that was run many years ago

Source? I'd really like to read about it.

Re: It’s Faster Because It’s C

#65

Post by ww520 »

Let me see. Here are some of the performance related cases I encountered.

1. A critical process slowed down drastically on certain days and certain times. Narrowed down to Oracle. Turned out another group went behind our back and ran expensive reports on our database server. Solution: Politic, spent half of a year to kick them out.

2. Some distributed processing slowed down steadily over time. Narrowed down to bandwidth throttling on the cross data center fiber optic. Solution: Scheduled emergency migration of processes to the same data center.

3. Site-wide page serving time slowed down. Narrowed down the Regex and XML parsing on pages; yes, this was CPU bounded. Solution: Faster libraries, pre-computation, caching result.

4. Lucene indexing took longer as data volume grew. Narrowed down to database bottleneck. Solution: revamp indexing architecture to use DFS and Hadoop.

5. Linux process spawning drastically slowed own on 64-bit machine. Narrowed down to OS page table copy-on-write overhead. Solution: work around the spawning requirement.

6. File system driver slowed down with more cache. Narrowed down to inefficient sorting algorithm. Solution: replaced bubble sort with heap sort.

In all these cases, language is never the issue.

Re: It’s Faster Because It’s C

#66

Post by stcredzero »

ww520 wrote: post #65

Let me see. Here are some of the performance related cases I encountered. 1. A critical process slowed down drastically on certain days and certain times. Narrowed down to Oracle. Turned out another group went behind our back and ran expensive reports on our database server. Solution: Politic, spent half of a year to kick them out. 2. Some distributed processing slowed down steadily over time. Narrowed down to bandwi…

1. A critical process slowed down drastically on certain days and certain times. Narrowed down to Oracle. Turned out another group went behind our back and ran expensive reports on our database server. Solution: Politic, spent half of a year to kick them out.

Have also experienced this firsthand. Blame is automatically pinned on us, and it's never our fault.

Re: It’s Faster Because It’s C

#67

Post by ww520 »

stcredzero wrote: post #66
ww520 wrote: post #65

Let me see. Here are some of the performance related cases I encountered. 1. A critical process slowed down drastically on certain days and certain times. Narrowed down to Oracle. Turned out another group went behind our back and ran expensive reports on our database server. Solution: Politic, spent half of a year to kick them out. 2. Some distributed processing slowed down steadily over time. Narrowed down to bandwi…

1. A critical process slowed down drastically on certain days and certain times. Narrowed down to Oracle. Turned out another group went behind our back and ran expensive reports on our database server. Solution: Politic, spent half of a year to kick them out. Have also experienced this firsthand. Blame is automatically pinned on us, and it's never our fault.

Oh yeah, it's pure politic. People would demand benchmark and measurement to prove it's their reports causing the problem, and finger pointing your way.

Re: It’s Faster Because It’s C

#68

Post by btilly »

petdog wrote: post #64
btilly wrote: post #63

Earlier quoted context omitted.

Moore's law says that CPUs improve faster than I/O. Therefore any program that is I/O bound today is likely to be I/O bound for every future generation of hardware. And programs that are not I/O bound today, may become so down the road. Incidentally on the final point, there was an interesting test that was run many years ago. Multiple teams were given the same spec, but were each told to optimize for a different cha…

> there was an interesting test that was run many years ago Source? I'd really like to read about it.

I read it in Code Complete. I don't have a copy handy to track down the page though.

Re: It’s Faster Because It’s C

#69

Post by ww520 »

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. :-(

Try Vmware and storage kind of startups. Virtualization is huge.

Re: It’s Faster Because It’s C

#70

Post by ww520 »

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…

I think he missed the point on why kernel code are fast. Kernel code are fast not because it's written in C. It's fast because it doesn't do much. Most system calls into the kernel does very little; they just update some data structure and return. OS kernel is complicate because of its breadth and dependency and side effects. The call path of each call is actually fairly shallow.
Post reply on HN