The "C is Efficient" Language Fallacy (2006) • Hacker News Board

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

#131

Post by stephencanon » Tue, Jan 10, 2012, 9:50 PM UTC

emillon wrote: post #130

quotemstr wrote: post #127

Earlier quoted context omitted.

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 ?

You would keep a frame pointer, which would tell you where to find the caller's stack frame. Most systems already do this, to aid debugging and tracing tools, to support variable-length stack allocations, or for any number of other reasons.

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

#132

Post by exDM69 » Wed, Jan 11, 2012, 11:09 AM UTC

emillon wrote: post #130

quotemstr wrote: post #127

Earlier quoted context omitted.

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 ?

The stack is only contiguous in the virtual address space. The physical address space is a different beast. The operating system allocates a big chunk of virtual address space for the stack but doesn't allocate the physical memory to fill that. When an app wants to read or write from the unallocated part of the stack, a page fault interrupt is generated and the operating system allocates physical memory frames and assigns them to the virtual memory addresses of the stack. When the thread/process is interrupted for servicing, the operating system checks the value of the stack pointer register (rsp in x86_64) and frees the physical memory corresponding to the virtual addresses above that in the stack.

So having a large stack will only consume virtual address space which we have plenty of (2^48 bytes in most x86_64's) but will not consume physical memory, which is a more limited resource.

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

#133

Post by groby_b » Thu, Jan 12, 2012, 2:16 AM UTC

hyperbovine wrote: post #65

nickolai wrote: post #9

Umm, yes C/C++ will not parallelize your code for you, whereas Language XYZ will. Im not sure how this is an argument against C/C++ being effective. C/C++ will not parallelize your code by design. It's was never meant to. I'd never blame my stick-shift car for not changing gears by itself - thats the first reason I didnt buy an automatic in the first place! If your matrix manupuilation code performance becomes an iss…

For the record, you should never be paying someone to tinker with and/or parallelize low-level matrix routines. The numerical linear algebra folks spend their entire careers thinking about this stuff and writing (FOSS) software to wring every last bit of performance out of the hardware. There are specialized suites for multicore, distributed and even GPU setups.

... unless you have a very specialized use cases. The linalg guys are great, but they write for the generalized case. They have to.

And so, generations of game developers write matrix multiplication code. With quite nice performance results.

It'd be nice to see if some of that performance intensive code would benefit from being written in fortran. Anybody up for porting box2d as a small test case? ;)