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

The "C is Efficient" Language Fallacy

scienceblogs.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: The "C is Efficient" Language Fallacy

#101

Post by anamax »

tptacek wrote: post #14
baguasquirrel wrote: post #8

Earlier quoted context omitted.

I have a friend at Intel who works on their realtime raytracing efforts and he swears by C/C++. Indeed, his arguments mirrors yours and go even farther. There's all sorts of magic you can play when you've got access to the actual bits and bytes. For starters, they do things like stash data in the low-precision bits of floats and the lower three bits of pointers. I wholeheartedly concur with his opinion that in raw pe…

"Premature optimization" is another hoary old argument that gets dragged into this debate every time it comes up. But I don't think it's valid. C programs start up faster than HLL programs. They run faster. They consume less memory. They tend to be more responsive. From "looking up an object by its string name" to "splitting a string on the comma character" to "running the following functions on a 10hz timer", simple…

> C programs start up faster than HLL programs. They run faster. They consume less memory. They tend to be more responsive.

That's working C programs vs working HLL programs. And, by those metrics, assembly language programs are better still.

> Hey --- I write most of my code in Ruby.

Which suggests that performance of working programs is not the only important factor.

Yes, "premature optimization" is arguably the wrong term for making that suggestion, but it is quite valid.

Re: The "C is Efficient" Language Fallacy

#102

Post by 10ren »

russell wrote: post #22
10ren wrote: post #15

Earlier quoted context omitted.

The standard approach I heard was to code in a very high level language (like python) to get the algorithms right, then rewrite in C for performance. Python then becomes a sort drawing board as part of the design stage, instead of "coding".

Rewrite only those pieces that are consuming a lot of time or memory, leave the rest in Python, which is particularly good at integration with C/C++. Many programs are a lot of setup, error handling, and edge cases where performance is not an issue. but LOC is.

I thought about including the idea of only rewriting the hotspots, but left it out as detracting from the main point and it seemed tedious to iterate the details. But then there are 3 replies pointing this out, and which seem to be more valued than mine by the community (according to their votes.)

Ask HN: Does this mean that HN would prefer I wrote comments that do cover all the cases, instead of just sticking to the key point? Or is it just that there seemed to be a gap in my comment, which people naturally wanted to cover?

Note: the replies add more than just "rewrite only hotspots" (like the above one detailing setup, errors, edge cases), and I certainly appreciate extra details being filled in. Is the valuable extra detail the reason for the extra votes? I just feel kind of annoyed that the replies seem to suggest I was stupid in not mentioning the hotspot idea. This has happened to me a few times now. Am I taking it too personally? Is it just a question of different opinions on what is important? Or is it just that I failed to communicate my decision, and then get annoyed when people point out the other branch of the decision?

There is a issue of preference here: I prefer to keep all the code in one language. One factor in this is that my projects are small, and for these, the overhead of switching languages and managing the different source isn't worth it. I'm not running up against efficiency problems either. I'm sure it's different for larger projects, especially multi-person ones, and particularly if the project covers different kinds of activities (for which different languages are suitable), and even more so if there's need to integrate with or reuse existing assets in different languages.

Thanks for any clarifications you may have. :-)

Re: The "C is Efficient" Language Fallacy

#103

Post by tptacek »

stcredzero wrote: post #99
sfphotoarts wrote: post #72

Earlier quoted context omitted.

I'd like to see the c code to support this, it's very hard to imagine anything you could do this wrong in something like a block cipher that would ever make it as slow as smalltalk. I'm sorry, I just don't buy this...

The C DLL was one of RSA Data Securities reference implementations from about a decade back. The Smalltalk guy could ask the VM implementor for goodies -- like 32 bit and 64 bit bit-arrays and various primitive operations on them. So long as you keep an entire algorithm in one method, and restrict yourself to certain optimized operations, the resulting JIT-ed code will look like it was produced by an unoptimized C co…

I'm not saying Smalltalk is slow, but I've worked with rsaref since the mid-90s, and I don't remember a block cipher routine in it that was horribly slow due to allocation.

Re: The "C is Efficient" Language Fallacy

#104

Post by tptacek »

JulianMorrison wrote: post #90
tptacek wrote: post #76

Earlier quoted context omitted.

You too are committing the fallacy of assuming that "managing memory manually" means using malloc() and free(). Fast programs don't use malloc() directly. Hell, even apr programs have standardized on this optimization. Many GC schemes are probably faster than malloc. But it's a much less credible argument to say that you have a GC that is faster than a custom allocator tuned to a workset. You probably don't.

Naive use of the GC is probably faster than any off-the-shelf manual memory management strategy. How many programmer hours are you prepared to pay for to get the last 1% of speed?

How many programmer hours do you think it takes to allocate 12-byte objects out a pool of a round number of 12-byte objects with a freelist or a bitmap?

GC faster than off-the-shelf allocator? Probably.

GC faster than off-the-shelf strategy? Doubtful.

And "remaining 1% of performance"? How disingenuous is that? Allocator optimizations have sped up commercial software I've shipped by over 200% in the past. Not sped up the allocator; sped up the program.

Re: The "C is Efficient" Language Fallacy

#105

Post by makecheck »

fauigerzigerk wrote: post #93
boryas wrote: post #79

Earlier quoted context omitted.

Also, thought I would mention the fact that if you take a day to write a slow program that takes a week to run, that's cheaper than spending a week writing a fast program that finishes in a day. After all, your time is much more expensive than the computer's!

You're both making a pretty odd assumption here, which is that a program typically runs exactly once and that I am the only user of my own program. Users' time is also much more expensive than the computer's. That's why we write software in the first place.

No, I expect my scripts to run for a long time with many users. This doesn't preclude optimization; some of it is automatic (new hardware, interpreter library improvements), some of it is well established (using SWIG and C to replace only a tiny piece of the program that must be faster).

In some respects, having long-lived software with lots of users makes speed the least of my concerns, because they're always asking for new features, and those are relatively easy to add to scripts.

And the relationship between software speed and productivity isn't linear, because people multitask. If a program takes 10 seconds to run, I might sit and wait for it to complete, without doing anything else. Whereas, if the program takes a minute, I may decide to switch to another quick task, and then return to see results. In this case, both tasks needed to be done, one took longer but it ate up the "slow" runtime of the program, and was only parallelized because of that long runtime.

Re: The "C is Efficient" Language Fallacy

#106

Post by brl »

wlievens wrote: post #95
gaius wrote: post #85

Earlier quoted context omitted.

That is a false dilemma tho'. No-one in the Python world has anything invested in a 100% Python solution to anything. Doing the compute-intensive bits in C is in fact expected and encouraged! The same is true in the Tcl camp. Maybe some HLL communities (Java?) like to be "pure" but I've not ever encountered that.

Java communities typically favor portability (and easy deployment) over what you can gain in terms of speed. A lot of libraries/frameworks actually even advertise themselves as "100% pure java", whereas one might expect "expensive bits optimized in C" as attractive as well (but you rarely see it).

> whereas one might expect "expensive bits optimized in C"

There is no important difference in performance between C and Java according to http://shootout.alioth.debian.org/

Re: The "C is Efficient" Language Fallacy

#107

Post by viraptor »

tptacek wrote: post #75
viraptor wrote: post #68

Earlier quoted context omitted.

Actually firefox is a large hll program. It's a javascript / xul engine in a large part. The frontend of firefox is actually javascript AFAIK. Maybe someone has more precise information? 1 and 2 were already commented on, so I'll just add that, there was a proof that a copying gc with enough memory can be faster than manual allocation. http://www.cs.umass.edu/~emery/pubs/04-17.pdf

The paper you're citing doesn't contain the evidence you claim it has, and in GC vs. "manual" studies, you have to make sure they're not comparing GC to malloc(). Malloc has design goals other than speed. Performant code very often replaces malloc.

You're right - I made a stupid copy&paste mistake with both documents open :/

This is the link I was thinking about: http://www.cs.ucsb.edu/~grze/papers/gc/appel87garbage.pdf

Re: The "C is Efficient" Language Fallacy

#108

Post by barrkel »

lacker wrote: post #59
barrkel wrote: post #32

Earlier quoted context omitted.

For me, this argument in favour of C is really missing the point. In the long run, maintenance costs dominate, and unsafe languages like C lead to programs that take more and more programmer time to maintain, and it becomes harder and harder to see the high-level structure and optimize that through refactoring, rather than the low-level bottlenecks that show up in profilers.

Maintenance costs do not always dominate. If you are working on code that will run on many thousands of machines, then hardware and running-the-cluster costs dominate. Performance improvements that are small in terms of % can still be worth many programmer-months of effort, and it becomes optimal to use C or C++.

Of course it depends. If your code is going to last for 20+ years, though (like the code I work on), I can guarantee you that it becomes very difficult to see the forest for the trees.

Re: The "C is Efficient" Language Fallacy

#109

Post by stcredzero »

tptacek wrote: post #103
stcredzero wrote: post #99

Earlier quoted context omitted.

The C DLL was one of RSA Data Securities reference implementations from about a decade back. The Smalltalk guy could ask the VM implementor for goodies -- like 32 bit and 64 bit bit-arrays and various primitive operations on them. So long as you keep an entire algorithm in one method, and restrict yourself to certain optimized operations, the resulting JIT-ed code will look like it was produced by an unoptimized C co…

I'm not saying Smalltalk is slow, but I've worked with rsaref since the mid-90s, and I don't remember a block cipher routine in it that was horribly slow due to allocation.

So instead of Highly Optimized Smalltalk (with VM implementor help) = Horrible C, we have Highly Optimized Smalltalk (with VM implementor help) = Average C.

I can live with that.

Re: The "C is Efficient" Language Fallacy

#110

Post by brl »

viraptor wrote: post #107
tptacek wrote: post #75

Earlier quoted context omitted.

The paper you're citing doesn't contain the evidence you claim it has, and in GC vs. "manual" studies, you have to make sure they're not comparing GC to malloc(). Malloc has design goals other than speed. Performant code very often replaces malloc.

You're right - I made a stupid copy&paste mistake with both documents open :/ This is the link I was thinking about: http://www.cs.ucsb.edu/~grze/papers/gc/appel87garbage.pdf

Just from the title alone, I can tell I'm going to like this paper :)
Post reply on HN