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

111–120 of 122 posts

Re: It’s Faster Because It’s C

#111

Post by draegtun »

dededo wrote: post #109
kunley wrote: post #45

Earlier quoted context omitted.

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.

Life is full of trade offs and I'm happy to compromise if it gets me a powerful self-hosting OO & meta-circular MOP.

Re: It’s Faster Because It’s C

#112

Post by cdavid »

mturmon wrote: post #97
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…

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

I sincerly doubt that machine learning is CPU bound. Many things related to numerical computing are memory bound

Re: It’s Faster Because It’s C

#113

Post by mad »

tptacek wrote: post #75
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…

I don't understand your argument. In terms of effort vs. reward, the one-line change of swapping malloc() with a pool allocator is probably the most effective optimization available to any software in any language. The idea that C# (or for that matter any GC'd language) is going to beat an allocator in which alloc is amortized to a single load, constant add, and store seems... I don't know, fill in the blank. You see…

Do you think that is true even for modern allocators like Hoard?

In other words, I'm curious what are the underlying malloc() implementations that pool allocation so outperforms.

Re: It’s Faster Because It’s C

#114

Post by AlisdairO »

kevingadd wrote: post #73
lemming wrote: post #13

There are a couple of excellent mailing list posts discussing the relative speed of JGit and Git, which are excellent reading: http://article.gmane.org/gmane.comp.version-control.git/1180... http://article.gmane.org/gmane.comp.version-control.git/1180... That said, there are probably very few applications that have been this heavily hand-optimised, and probably equally few where you actually need it. Where C really s…

I find those posts particularly interesting because they are not the typical criticisms levelled at high level languages; for the most part those posts read as a detailed list of design mistakes in Java: no unsigned types, no 'struct'-style types, reliance on boxing for generic containers, no way to 'reinterpret' blocks of memory C-style, etc. When people complain about using java to write software you often hear the…

I find the lack of struct types, and the lack of unsigned integers especially frustrating.

Re: It’s Faster Because It’s C

#115

Post by lemming »

kevingadd wrote: post #73
lemming wrote: post #13

There are a couple of excellent mailing list posts discussing the relative speed of JGit and Git, which are excellent reading: http://article.gmane.org/gmane.comp.version-control.git/1180... http://article.gmane.org/gmane.comp.version-control.git/1180... That said, there are probably very few applications that have been this heavily hand-optimised, and probably equally few where you actually need it. Where C really s…

I find those posts particularly interesting because they are not the typical criticisms levelled at high level languages; for the most part those posts read as a detailed list of design mistakes in Java: no unsigned types, no 'struct'-style types, reliance on boxing for generic containers, no way to 'reinterpret' blocks of memory C-style, etc. When people complain about using java to write software you often hear the…

I agree that the criticisms are not typical, but I don't agree that they're necessarily design flaws - just things that make Java less suitable for certain tasks that require fine memory management or low-level bit twiddling. I write Java in some fairly high-performance scenarios and this is rarely a real problem (except maybe memory layout - having every object reference be a pointer does kill us occasionally, but again in specific circumstances). For the vast majority of applications it's a non-issue.

Re: It’s Faster Because It’s C

#116

Post by JoeAltmaier »

_delirium wrote: post #101
JoeAltmaier wrote: post #71

Earlier quoted context omitted.

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

Sure; but it certainly depends upon the frequency of use of each instance etc. But in general, shorter code is a good choice of optimization

Re: It’s Faster Because It’s C

#117

Post by omarin »

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.

Slow?. That comment is so 90's. Plz upgrade http://shootout.alioth.debian.org

Re: It’s Faster Because It’s C

#118

Post by jrockway »

statictype wrote: post #99
jrockway wrote: post #29

Earlier quoted context omitted.

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

Sure, lots. They use the same C libraries that the reasonable experienced C programmer would.

(Also, take a look at some of the ghc on llvm benchmarks, it's very competitive with C, and doesn't require you to jump through any hoops. I'd link you, but Google is blocked at work due to incompetent firewall rules. Sigh.)

Re: It’s Faster Because It’s C

#119

Post by jrockway »

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.

Even I agree with this. You can't just do whatever you want in C and still get good performance, you have to have a clue, just like with higher-level languages.

I think the original article should add, "performance tends to depend on the programmer, not the language".

Re: It’s Faster Because It’s C

#120

Post by kunley »

omarin wrote: post #117
kunley wrote: post #45

Earlier quoted context omitted.

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.

Slow?. That comment is so 90's. Plz upgrade http://shootout.alioth.debian.org

Yeah microbenchmarks are cool to stare on when your farm of those jboss instances for another very important project is crawling. Very motivating.

Wake up, this is reality.

Post reply on HN