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

The "C is Efficient" Language Fallacy (2006)

scienceblogs.com

Post reply on HN
Print view View original

121–130 of 133 posts

Re: The "C is Efficient" Language Fallacy (2006)

#121

Post by tlb »

CountHackulus wrote: post #31
unwind wrote: post #2

This is old (2006), and seems to base its argument around the problems with unrestricted pointers in C, that cause aliasing. As of C99, of course, C has the "restrict" keyword which allows pointers to explicitly be declared to not alias, thus enabling all these optimizations in C, too.

In addition to that, if you're using the Intel compiler, then you can say #pragma ivdep Which tells the compiler that the loop you're writing doesn't have any vector dependencies. Or -fno-fnalias to say that none of the arguments you're passing to a function are aliased. Seems like pretty reasonable ways around the problem. Not to mention things like OpenMP.

Pragmas suck. What I want is to explicitly assert the condition:

  assert(a+n
(saying that a[0..n] and b[0..m] don't alias) and have the compiler generate code that first tests the condition and generates optimized code given the assumption.

Re: The "C is Efficient" Language Fallacy (2006)

#122

Post by jemfinch »

MichaelSalib wrote: post #37
microtonal wrote: post #35

Earlier quoted context omitted.

Except that there are fine high-level matrix libraries, optimization libraries, etc. for C/C++. I needed an parameter estimator for maximum entropy models that was efficient for training rankers (e.g. for parse disambiguation, fluency ranking, etc.), that also had good support for feature selection. I just used an off-the-shelf optimizer (liblbfgs), implemented calculation of the objective and gradients, plus various…

C is a very simple language. It is? Out of curiosity, did you know about all the undefined behaviors described at http://blog.llvm.org/2011/05/what-every-c-programmer-should-... and did you understand how your C compiler takes advantage of them before you wrote that statement?

It's not the strings that aren't in the language that make it simple; it's the strings that are in the language. "Undefined behavior" is caused by strings that aren't in the language, and is irrelevant to the complexity of the actual language.

Re: The "C is Efficient" Language Fallacy (2006)

#123

Post by lukesandberg »

AshleysBrain wrote: post #54
lukesandberg wrote: post #41

Earlier quoted context omitted.

Well maybe the reason performance improved only slightly is because not a lot of effort has gone into optimizing situations involving restrict pointers because it is so rare. If it is common in fortran it would make sense that a lot of effort has gone into special optimizations for that case, the same effort would not have been spent in c compilers because it is so rare.

I'm not sure it's as rare as you make it out to be - AFAIK most compilers that support restrict declare malloc() and new to return restrict pointers, so int *x = malloc(100), *y = malloc(100); followed by some loop should be able to spot that x and y are not aliased. It should also be able to propagate the restrict as pointers are passed around, at least to some extent.

would the c compiler actually pull that restrict annotation forward without declaring the locals as restrict?

Re: The "C is Efficient" Language Fallacy (2006)

#124

Post by ternaryoperator »

jpdoctor wrote: post #33

> Modern architectures have reached the point where people can't code effectively in assembler anymore Someone should inform the guys over at ffmpeg that the jig is up.

The statement is overbroad but not wholly incorrect. The biggest challenge to writing good (I don't know about "effective") assembly language is indeed the complexity of processors and architectures which can greatly magnify the effects of imperfect instruction choices or instruction sequencing. Obviously, some people can code effectively within those constraints, but it's a very much more specialized skill than it used to be.

Re: The "C is Efficient" Language Fallacy (2006)

#125

Post by losethos »

God gave us free will. Some women really like dead babies. Kinda sick. Not liking C? Bad childhood? Homos -- everybody is a homo.

God says... C:\LoseThos\www.losethos.com\text\BIBLE.TXT

s of Heman: Bukkiah, Mattaniah, Uzziel, Shebuel, and Jerimoth, Hananiah, Hanani, Eliathah, Giddalti, and Romamtiezer, Joshbekashah, Mallothi, Hothir, and Mahazioth: 25:5 All these were the sons of Heman the king's seer in the words of God, to lift up the horn. And God gave to Heman fourteen sons and three daughters.

25:6 All these were under the hands of their father for song in the house of the LORD, with cymbals, psalteries, and harps, for the service of the house of God, according to the king's

Re: The "C is Efficient" Language Fallacy (2006)

#126

Post by dextorious »

jpdoctor wrote: post #33

> Modern architectures have reached the point where people can't code effectively in assembler anymore Someone should inform the guys over at ffmpeg that the jig is up.

Someone should inform you about generic statements and exceptions that prove a rule.

Re: The "C is Efficient" Language Fallacy (2006)

#127

Post by quotemstr »

jemfinch wrote: post #119
repsilat wrote: post #105

Earlier quoted context omitted.

I don't understand why stacks are still so small. On nice operating systems memory is only needed when it's touched, not when it's asked for, so making the stack large doesn't cost anything unless you need a large stack. On 64-bit systems you could make the stack a billion gigabytes and still have 95% of your process' virtual address space available for the heap. On Windows the stack is one megabyte by default. We li…

Stacks are small because every thread in the system has to have one, it's that simple.

Who said stacks had to be contiguous and allocated ahead of time?

Re: The "C is Efficient" Language Fallacy (2006)

#128

Post by losethos »

"God made free will. Some women love dead babies."

My point was, "Now that I think about it, why do you care so much?"

Why is it so many women support abortion?

Why do people hate C and want to stop others?

Live and let live.

People who crusade against C. What if it's a conspiracy?

God says... C:\LoseThos\www.losethos.com\text\QUIX.TXT

r when it comes to the promise of the island we must count from the day your worship promised it to me to this present hour we are at now."

"Well, how long is it, Sancho, since I promised it to you?" said Don Quixote.

"If I remember rightly," said Sancho, "it must be over twenty years, three days more or less."

Don Quixote gave himself a great slap on the forehead and began to laugh heartily, and said he, "Why, I have not been wandering, either in the Sierra Morena or in the whole course of

Re: The "C is Efficient" Language Fallacy (2006)

#129

Post by derleth »

stcredzero wrote: post #114
derleth wrote: post #108

Earlier quoted context omitted.

They're standardized, so they are part of the language. They don't have special syntax, but, then, neither does practically anything you do in Common Lisp, and that's standardized as well.

They're standardized, so they are part of the language. "Language" has slightly different meanings in different contexts. Perhaps he's talking about something in a theoretic context, as opposed to practice? Smalltalk has no special syntax for allocation (creating new objects) either.

> Perhaps he's talking about something in a theoretic context, as opposed to practice?

Then he's still wrong. A standardized part of the language is a part of the language.

Re: The "C is Efficient" Language Fallacy (2006)

#130

Post by emillon »

quotemstr wrote: post #127
jemfinch wrote: post #119

Earlier quoted context omitted.

Stacks are small because every thread in the system has to have one, it's that simple.

Who said stacks had to be contiguous and allocated ahead of time?

How would you manage non-contiguous stacks ? ie, how would you know (upon return) where is the caller's stack frame is ?
Post reply on HN