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

121–127 of 127 posts

Re: The "C is Efficient" Language Fallacy

#121

Post by gaius »

robin_reala wrote: post #97
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.

No-one in the Python world has anything invested in a 100% Python solution to anything PyPy? http://codespeak.net/pypy/dist/pypy/doc/

That's not for production use, tho'.

Re: The "C is Efficient" Language Fallacy

#122

Post by e4m »

wicknicks wrote: post #35

The arguments about language efficiency on a single processor machine are probably outdated today. Most machines have multiple cores. We need good tools which can exploit this CPU architecture. Languages like C/C++ place a large amount of responsibility on the shoulders of a programmer. Effectively, you are writing two programs - one for the task at hand, and the other is memory allocation for it. Control does not al…

Boost has portable threads for C++ right now... in fact, the next C++ release (due out this year) will include threads by default. http://en.wikipedia.org/wiki/C%2B%2B0x#Threading_facilities

Re: The "C is Efficient" Language Fallacy

#123

Post by pohl »

michaelneale wrote: post #55
alecco wrote: post #47

Earlier quoted context omitted.

Time-space trade-off. Meaning Java uses a lot of memory for almost anything. Speed isn't everything.

Sometimes memory can cost speed as well. I find with java essentially you are amortising gains which are payed back with GC at a later date (in many cases I guess it is worth it). Its not one size fits all !

This sounds like it had less to do with Java and more to do with a large number of short-lived allocations in your design. A garbage collector can be abused in any language that has one.

Re: The "C is Efficient" Language Fallacy

#124

Post by jongraehl »

omouse wrote: post #27
tptacek wrote: post #3

This argument is as old as the hills. It's probably true in a lot of niche situations. But the fact is, most C code is faster than higher-level language code, because: * C programmers have more freedom to arrange data in memory to exploit locality * C data structures need less bookkeeping * C programs manage memory manually, and so lack GC overhead * C programs can easily swap in different allocators for different wo…

What about Forth? As far as I know it can do all the stuff that C can do plus some more nifty things.

Forth is ridiculously simple to implement. But there's no reason to use it, beyond that. It's less expressive than C but not faster.

Re: The "C is Efficient" Language Fallacy

#125

Post by viraptor »

tptacek wrote: post #116
viraptor wrote: post #107

Earlier quoted context omitted.

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

Doesn't this paper basically say: * Garbage collection is faster than manual frees when you provide processes with so much memory that collection happens so rarely that its cost is lost in the noise, and * Garbage collection is faster than manual frees when you ignore all the constant factors in both collection and manually freeing, for instance the cost of taking page faults?

Yes - that's true.

But it also gives you additional information: how to check if the cost can be ignored and whether it will be lost in the noise. And that's important, because in serious VMs you can often control the GC parameters. That means you cam make sure that those asymptotes are as close to reality as possible for your exact problem.

It's the same story for hashed collections. You can find big O costs for their operations, but they're amortised costs. Sure - once in a while you have to realloc / rehash / copy the table depending on the implementation - but then you know how to judge if that collection is ok for you. You can modify the starting size exactly in order to lose the rare cost in the noise. The trick is knowing the limits.

Yet somehow many people who love hashmaps hate GC...

You're right about what the paper says, it just didn't spell out the reason why that info is useful ;)

Re: The "C is Efficient" Language Fallacy

#127

Post by boryas »

fauigerzigerk wrote: post #118
makecheck wrote: post #105

Earlier quoted context omitted.

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…

I was referring to this statement: "Well, the script could be slow as dirt, but if it has a few extra weeks to churn through data and produce results, it may be done before the C program is even ready." The comparison of development times and running times simply makes no sense if you assume the script is going to run a 1000 times. I agree that this relationship isn't linear. That's exactly why it's pointless to comp…

Yes, good point. I guess he was referring more to the scientific end of things, where you write a program that runs for days on massive data, and there really isn't a user
Post reply on HN