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

111–120 of 133 posts

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

#111

Post by stevecooperorg »

haberman wrote: post #100

As someone who doesn't know Fortran, how does Fortran solve the aliasing problem? Even if pointers and arrays are different, how can you ensure two arrays don't alias each other? The only way I can think of to do this is to always copy arrays when they are passed to functions, but this seems expensive. Otherwise I don't see how you can avoid this pseudocode: void f(array1, array2) { /* somehow guaranteed not to alias…

(I don't know if I have this right -- I've not done Fortran in 15 years, but I feel like I've got about 1/3 of an answer and someone more knowledgeable may be able to finish it off. Any code samples guaranteed to be wrong. ;) )

Fortran 77 doesn't allow recursion, and all arrays are fixed in size at compilation time. That means every array in the source code is allocated memory when the program starts; you can never allocate a new array during program run; either by allocating the memory dynamically, or by making a recursive call that has an array local. I don't believe there's a stack -- not the way C/C++ has a stack for locals and return values. So if we declare a main program and a subroutine, like so;

    01  PROGRAM TEST1
    02  REAL  D(10)
    03  REAL  E(10)
    04  CALL  A(D,E)
    05  CALL  A(D,D)
    06  END
  
    07  SUBROUTINE A(F,G)
    08  REAL  F(*)
    09  REAL  G(*)
  C 10 --- Do something with F and G
    11  RETURN
    12  END
Then this program has exactly two arrays -- the ones declared on line 02 and 03. The ones on line 08 and 09 declare the type of the parameter passed on 03 and 04, but it doesn't allocates any memory. This idea is true for all F77 programs -- you can look at a program and say 'This program has exactly nineteen arrays'.

So -- this limitation may explain the aliasing problem. A call which passes an array (line 04, line 05) always calls a particular array -- it's not just 'pass a pointer to an array' but 'pass a pointer to memory location 85349'.

So in

    04 CALL A(D,E)
then we know they are separate arrays, and when we write

    05 CALL A(D,D)
we know they are the same array. We're never confused about whether we are, or are not, aliasing.

There are some notes on Fortram memory allocation and arrays here (http://www.ibiblio.org/pub/languages/fortran/ch2-4.html):

" When the array is declared in the 'outermost' procedure, the compiler allocates memory for it. When you pass the array with a CALL statement, the compiler actually passes the base-address of the same array to the called procedure. When the called procedure operates on the array it works on the same array - uses the same memory storage area, the array is not 'copied' to another memory area (But, it might be in some cases on some Fortran systems)."

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

#112

Post by stephencanon »

I write high-performance numerical software for a living. There are a lot of baseless claims in this post. You can write high performance software in C, C++, Fortran, Assembly, or a whole host of other languages. There are syntactic reasons to prefer one or another, but you should not choose among them for performance reasons.

I choose to write in C and Assembly, for example, and much of the code I write is provably as fast as possible on the targeted architecture. It is literally impossible that it would go faster if I wrote it in Fortran instead. All of these languages are just tools, and if you know your tool, you can do great things with it. The specifics of which tool you choose are often unimportant.

There are some syntactic niceties in fortran which make it more comfortable for people who don't want to think about certain low-level details. However, you cannot write software that runs as fast as possible without considering those details, so a programmer with that goal is forced to think about them no matter what tool he or she chooses.

Fortran does have a (slightly) more relaxed numerics model than standard C, which allows a compiler to make some optimizations that a C or C++ program would need to explicitly license. However, these optimizations are disallowed in standard C and C++ because they are unsafe. The fact that Fortran enables them does not make Fortran a better language for numerical computation (from my perspective as low-level library writer, they make it worse). Performance without correctness is absolutely meaningless.

Write software in the language that is comfortable for you. Use libraries written by experts for performance critical operations. Use a profiler to identify operations that are hotspots in your code. Don't complain about your (or someone else's) tools.

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

#113

Post by [deleted] »

haberman wrote: post #106
scott_s wrote: post #103

Earlier quoted context omitted.

I thought about it, and I realized I didn't know. This is the best discussion I found: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Aliasing-Assumed... Short answer: they don't. What you wrote is an undefined behavior, just like dereferencing a null pointer in C. If the compiler can't tell statically, then it just assumes they're not aliased. I'm basing this conclusion mainly on this statement from that piece on alias…

Interesting, that sounds equivalent to just assuming "restrict" on all function parameters. If that's true, then C and Fortran aren't fundamentally that different in this respect except that C assumes things can be aliased by default and Fortran assumes they can't.

[deleted]

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

#114

Post by stcredzero »

derleth wrote: post #108
wvenable wrote: post #84

Earlier quoted context omitted.

> C lets you allocate blocks of memory It doesn't even let you do that -- those things are external library calls.

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.

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

#115

Post by aaronblohowiak »

jerf wrote: post #60
MichaelSalib wrote: post #53

Earlier quoted context omitted.

So when people say that "C is simple", you think they really mean "C is simple to implement" or maybe "C is simple to specify"? I don't think the grandparent meant either of those things and I don't think either of them are true anyway.

It may not be what was meant, but it is the correct way in which C is simple. C is simple because, like much of UNIX (especially back in the very beginning), anywhere there was a sharp pointy bit that was difficult to handle in the compiler, it was simply relayed up to the user to handle. I mean this descriptively, not as a criticism. It is critical to understanding C and UNIX. It is also worth pointing out that whil…

I'd argue it didn't go far enough in this direction w.r.t. automatic datatype promotion rules (particularly where signedness comes into play.)

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

#117

Post by sampo »

jbooth wrote: post #92
ArbitraryLimits wrote: post #87

Earlier quoted context omitted.

Why would pthreads and SSE instructions not be available in Fortran? Pthreads are just another library which Fortran programs can link to with no problem, and a modern Fortran compiler is perfectly capable of handling inline assembler.

I saw this link claiming that it was difficult/impossible to use threads in fortran due to surprisingly global variables: http://math.arizona.edu/~swig/documentation/pthreads/#fortra... Maybe it's wrong, I'm not knowledgeable about Fortran and certainly not horribly invested in this, go ahead and write a world-conquering BLAS library in Fortran if you want.

The text in your link claims: "it is illegal for a FORTRAN subroutine to call itself recursively, either directly or indirectly". That is not true anymore (for almost 20 years), since Fortran 90 has 'recursive' keyword with which you can declare that a subroutine can be used recursively.

(Also the all-caps spelling, FORTRAN, strongly hints that the link only talks about Fortran 77.)

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

#119

Post by jemfinch »

repsilat wrote: post #105
pjmlp wrote: post #90

Earlier quoted context omitted.

If len is big enough your f() call will crash with a stack overflow.

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.

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

#120

Post by aaronblohowiak »

kabdib wrote: post #45
buff-a wrote: post #5

Earlier quoted context omitted.

And then there are SIMD compiler intrinsics. Not technically part of the C standard, but if you want them, C/C++ is where you find'em. Failing that there's inline assembly.

Ding. It's amazing what you can do with a decent set of vector operations. Honestly, if you want balls-out performance, you probably need specialized hardware. In days of yore that meant you bought a vector box for your computer, or a Cray. These days you can just load up a PC with a bunch of high-end GPUs. A cow-orker of mine down the hall has a machine with six of them installed -- he's so giddy, it's kind of irrit…

if you use the Accelerate Framework on OSX or iOS, you have a very easy-to-use interface to vector ops (pass in pointers to your array..)
Post reply on HN