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

91–100 of 122 posts

Re: It’s Faster Because It’s C

#91

Post by scott_s »

th0ma5 wrote: post #89
tptacek wrote: post #86

Earlier quoted context omitted.

The side-discussion we're having now is also why and are a pain to use, and why Stroustrop's examples tend to use . Storing things in contiguous memory and incurring occasional copies is usually a better plan than forcing every read to follow a chain of pointers.

these kinds of varying opinions that seem like wide schisms, or maybe just ultimately are different problem areas, often come up when i'm reading about C, and that makes me think "i'll learn it more when people figure out how to use it" ... is that fair?

Only if you're comfortable never learning it.

Re: It’s Faster Because It’s C

#92

Post by Ralith »

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?

Profiling would be far more informative than even the most spammily verbose of loggers, too.

Re: It’s Faster Because It’s C

#93

Post by jacquesm »

th0ma5 wrote: post #89
tptacek wrote: post #86

Earlier quoted context omitted.

The side-discussion we're having now is also why and are a pain to use, and why Stroustrop's examples tend to use . Storing things in contiguous memory and incurring occasional copies is usually a better plan than forcing every read to follow a chain of pointers.

these kinds of varying opinions that seem like wide schisms, or maybe just ultimately are different problem areas, often come up when i'm reading about C, and that makes me think "i'll learn it more when people figure out how to use it" ... is that fair?

> "i'll learn it more when people figure out how to use it" ... is that fair?

No, because you could be learning that today and get a head start on your own future that way. It's not that hard to understand and once you've seen how the clock ticks from the inside it becomes a lot easier to build other clocks.

Lists vs resize-able arrays is a very old debate, both have their places, it all depends on the problem you're trying to solve which one is the most appropriate. If you code your stuff in a not too stupid way (say using a macro for your accesses) it's trivial to replace one approach with the other in case you're not sure which one will perform better.

Lists work well when they're short and you use a an array of pointers to the beginnings of your lists and maintain a 'tail' pointer for fast insertion in case inserts are frequent. If you use resize-able arrays you probably want to allocate a bunch of entries in one go, roughly doubling the size of your array every time you need to increase the size. That seems to waste a lot of memory, but since it is heap memory (allocated using brk) it (usually) won't be mapped to real memory until you use it, so the overhead is smaller than it seems.

I hope that's correct and clear :)

Re: It’s Faster Because It’s C

#94

Post by tptacek »

scott_s wrote: post #90
tptacek wrote: post #85

Earlier quoted context omitted.

My resume isn't too hard to find. There's even some C code out there with my name on it if you look hard enough. Performant C code doesn't use linked lists. Linked lists shred caches and allocators. Your go-to data structure for storing resizeable arrays is... wait for it... the resizeable array. I call mine "vector.h". (That performant code often doesn't want a hash table is also why I backported STLport's red-black…

The kinds of lists that barrkel are talking about are what I call hooked-in lists as opposed to the container style lists seen in the STL. That is, objects that already existed are linked together through fields inside the object themselves. Since you're probably already operating on the object, it's not quite as bad for cache performance as the container style lists. Further, since the objects already exist, the mem…

I get that void* lists are even worse, but randomly malloc'ing a bunch of struct-foo's and linking them with pointers is worse than keeping a pool of memory chunks of struct-foo size and maintaining a length counter, since hopping from foo to foo isn't likely to hop from page to page.

Re: It’s Faster Because It’s C

#95

Post by scott_s »

tptacek wrote: post #94
scott_s wrote: post #90

Earlier quoted context omitted.

The kinds of lists that barrkel are talking about are what I call hooked-in lists as opposed to the container style lists seen in the STL. That is, objects that already existed are linked together through fields inside the object themselves. Since you're probably already operating on the object, it's not quite as bad for cache performance as the container style lists. Further, since the objects already exist, the mem…

I get that void* lists are even worse, but randomly malloc'ing a bunch of struct-foo's and linking them with pointers is worse than keeping a pool of memory chunks of struct-foo size and maintaining a length counter, since hopping from foo to foo isn't likely to hop from page to page.

With hooked-in lists, you rarely need to navigate through the whole list. You usually just need to get the next one. Having implemented hooked-in lists, the backing for them was a fixed size of memory chunks, but that was one level of abstraction lower. The Linux kernel does something similar.

(Felt I should clarify that it's nothing about hooked-in lists that prevent you from navigating the whole list. It's just the algorithms you end up using to solve the problems that pop-up at that level of systems programming.)

Re: It’s Faster Because It’s C

#96

Post by _cbsz »

btmorex wrote: post #19
j_baker wrote: post #15

Earlier quoted context omitted.

"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?" No, not at all. First of all, don't assume that someone knows what they're doing just by choosing C or C++ over Java. There are plenty of dumb C/C++ programmers…

"Secondly, remember that Java programs may actually be faster than C/C++ programs. Programs written in C/C++ require more time and knowledge to performance tune. Writing something in Java (or other high-level language) allows the author to spend more time focusing on the big picture issues rather than having to deal with a lot of lower-level issues." I'm not against Java and I'll even admit that theoretically I could…

> for those that don't know, utorrent is written in c++ and pretty much better than azureus in every way

The Azureus/Vuze DHT is a lot nicer than the Mainline DHT (which uTorrent supports), it's just not documented, there are no other implementations, and this statement probably does not apply to code quality.

Re: It’s Faster Because It’s C

#97

Post by mturmon »

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…

I felt that article had a point, but overstated it.

There are lots of domains -- simulation, computer vision, robotic control, machine learning -- which are CPU bound and will remain so for the next decade. In fact, one of the cutting edges of these domains is always CPU bound, practically by definition (sensor densities also increase quickly with time).

Re: It’s Faster Because It’s C

#98

Post by paulbaumgart »

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

One I came across:

http://fastsoft.com/kernel-developer/

Re: It’s Faster Because It’s C

#99

Post by statictype »

jrockway wrote: post #29
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…

But higher-level languages can write the machine code that "exploits caching in general and optimizes for locality in particular" for you . You teach the computer how to do that once, and then you get it for free from then on. You can program your problem domain instead of the solution domain. Most people using C for high-performance computing are just using it to glue together the high-performance libraries, anyway.…

But higher-level languages can write the machine code that "exploits caching in general and optimizes for locality in particular" for you

Are there any in existence that do this particularly well (ie, at least as good or better than a reasonably experienced C programmer might)?

Re: It’s Faster Because It’s C

#100

Post by tsally »

barrkel wrote: post #83
tptacek wrote: post #76

Earlier quoted context omitted.

Who writes high-performance code using linked lists? Linked lists are awful for performance. Every --- every --- large C project I've been involved in has a good generic hash table and a vector-style resizeable array.

If that really is true, it sounds like you don't have much experience in C, to be frank. C apps abound in fixed-size statically allocated arrays and linked lists with next pointers (often multiple pointers, if the objects are part of different lists) embedded in the objects themselves. The hash tables often aren't broken out until the poor performance shows up as a bottleneck.

Err... why does the existence of shitty "C apps abound" have anything to do with how performant C programs are written?
Post reply on HN