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

Re: It’s Faster Because It’s C

#101

Post by _delirium » Wed, Jul 14, 2010, 2:13 AM UTC

JoeAltmaier wrote: post #71

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

Good analysis. I would amend: templates usually improve code efficiency, because the compiler can see through abstractions and generate (larger but) much faster code.

I think that's often true (one common example is stl sort versus C stdlib's qsort(), which is often a big win because of inlining a datatype-specific comparison operator), but I think there are quite a few cases where the object code bloat you get from multiplying the code by the number of types it's instantiated for (vs. using a polymorphic/generic function) kills your cache more than enough make up for any optimization win.

Re: It’s Faster Because It’s C

#102

Post by angusgr » Wed, Jul 14, 2010, 2:47 AM UTC

brazzy wrote: post #5

shin_lao wrote: post #3

C(++) has got a lower memory footprint than Java/C# which is also quite important.

True; Java makes it very easy to become memory-bound needlessly. No JIT in the world can save you if your primary data structure is a TreeMap with a billion entries.

C++ also makes it perfectly possible to build this kind of mess. I know because I've worked on the exact same situation you describe, except in that case the TreeMaps of pointers were hand-rolled, "tested in production", and yet another problem to maintain.(^)

Java might make it easier, and granted the extra object allocations around Longs and Integers will make it scale poorly more rapidly, but bad (or compromised) design and poor use of data structures is always going to lead to problems of some kind or another.

(^) Yes, I know about STL et al. Original programmer clearly did not.

Re: It’s Faster Because It’s C

#103

Post by c00p3r » Wed, Jul 14, 2010, 3:33 AM UTC

It is funny how people who are bounded to an artificial sandbox are trying to view themselves as equal (or even better) than those who created this sandbox. ^_^

JVM is a mere C++ program. Period.

Re: It’s Faster Because It’s C

#104

Post by jbooth » Wed, Jul 14, 2010, 3:42 AM UTC

tptacek wrote: post #76

silvestrov wrote: post #62

Earlier quoted context omitted.

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

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 you need to scan/remove if appropriate? They're optimal for that.

Re: It’s Faster Because It’s C

#105

Post by btilly » Wed, Jul 14, 2010, 3:42 AM UTC

anatoly wrote: post #81

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…

A data point: the first version of memcached was written in perl. It was pretty good perl, with an async epoll-based event loop and everything. It was hopeless, orders of magnitude away from the desired performance.

I'm not saying that there are not good examples where performance matters. In fact I encountered one where I had to move something from stored procedures in a database into C++. Furthermore I can easily believe that memcached is one of them.

But that doesn't change the fact that most of the places that I have seen worry about it have not been among them, even if they thought they were. (I admittedly mostly work in the web world.)

Re: It’s Faster Because It’s C

#106

Post by barrkel » Wed, Jul 14, 2010, 5:22 AM UTC

tptacek wrote: post #84

barrkel wrote: post #80

Earlier quoted context omitted.

That's a complete straw man, and you know it. I'm saying that the specific optimization you mentioned is hard if you don't control all the pieces. The primary advantage of a pooled allocator isn't in allocation - though that's nice - it's that you don't have the cost of iterating through each object to free it. But if you have external libraries, they'll abstract their allocations into handles (say), and now you have…

Nope, I don't think it is. I'm saying that when libraries track their own state and manage their own lifecycles, you're right, you can't make them use pool allocators (unless it's worth it to you to do surgery)... but that doesn't keep you from using pools on your own state . I think people also overestimate the extent to which C programs depend on third-party libraries for their own statekeeping. And again... what a…

Again, I'm not saying that you're advocating writing things in C.

Where I think performance advantages that come out of writing things in C come from is being rarely being able to take shortcuts by relying on provided libraries and primitives which turn out to be not quite tweaked for the problem at hand. That is, C forces you to do so much yourself - largely because it has such poor abstraction tools - that you end up with a more specialized codebase. That specialization can include cache-oriented optimization, but I don't think it's the most important aspect or unique to C such that you can't get 95% of it - to the point where it's no longer a meaningful advantage - in a GC'd language.

Re: It’s Faster Because It’s C

#107

Post by barrkel » Wed, Jul 14, 2010, 5:27 AM UTC

tedunangst wrote: post #87

barrkel wrote: post #74

Earlier quoted context omitted.

You overstate the degree to which large applications written in C have policy discretion over all memory allocations, to take your specific example. Compacting GC, by bringing together memory allocated close together in time, arguably has higher benefits for caching. The bigger problem is avoiding indirection, and that's a place where Java is weak in comparison to e.g. C#, as C# has value types. You can go further wi…

Good luck trying to carefully align your C# arrays so that the length field (at index -1 and read accessed on basically every write) isn't in the same cache line as the 0th element the CPU across the bus is writing to.

The nice thing about using C# is that you don't need to use an array, if this is critical. With unsafe code, you can all but write C.

Re: It’s Faster Because It’s C

#108

Post by ethaneade » Wed, Jul 14, 2010, 5:43 AM 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. :-(

Evolution Robotics (which may or may not qualify as a startup depending on your perspective)

Re: It’s Faster Because It’s C

#109

Post by dededo » Wed, Jul 14, 2010, 6:25 AM UTC

kunley wrote: post #45

joe_the_user wrote: post #42

Earlier quoted context omitted.

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.

They are coming in Perl too ... with Moose leading the way.

Re: It’s Faster Because It’s C

#110

Post by smydhacker » Wed, Jul 14, 2010, 6:28 AM UTC

kunley wrote: post #45

joe_the_user wrote: post #42

Earlier quoted context omitted.

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.

Have you ever coded in C++? C++ can't alleviate the issue of call depth, it can only locally inline, the JVM can (doesn't mean it will) globally optimize common call routes.