Darren New wrote:
> nemesis wrote:
>> Nothing is faster than C, some wise men said. ;)
> 
> Assembler is.
> 

Back in the days before modern processors I'd say absolutely. But 
nowadays that's debatable. Due to multiple pipelines, the criticality of 
cache hits and advances in compiler design, it's very difficult to beat 
C with assembler.

I'd say a mix of C and inline assembly is probably your fastest 
performance bet. You can leverage the optimizations the compiler will 
perform, and use SIMD instructions in ways the compiler won't find.

-- 
~Mike

Post a reply to this message

Stephen wrote:

> I raise you "Machine code" :)

More pain != faster :-P
-- 
~Mike

Post a reply to this message

Invisible wrote:

> That still doesn't explain why I'm the only one having this problem.

You are not the only one by far. Do you know how many times I've been 
"gently corrected" just on here?

You'll see I'm wrong a lot. I draw the ire of the same people you do. 
The difference is I don't dwell on it. I just go on.

OK, so that may be stupid of me, but I do listen from time to time. :)

-- 
~Mike

Post a reply to this message

Jim Henderson wrote:

> That's a good question, Slime.  I've been wondering that myself.

I agree.

But, I find it ironic that one of his admonishments was not to derail 
the thread, only to see there is a large part of this thread that has 
absolutely nothing to do with the original topic. Delightfully hijacked.

-- 
~Mike

Post a reply to this message

>>> Nothing is faster than C, some wise men said. ;)
>>
>> Assembler is.
>>
>
> Back in the days before modern processors I'd say absolutely. But nowadays 
> that's debatable. Due to multiple pipelines, the criticality of cache hits 
> and advances in compiler design, it's very difficult to beat C with 
> assembler.

Well it really depends on how *difficult* it is to match or beat any 
language with assembler.  It's always theoretically possible, but as you say 
with modern CPU and compiler design it is becoming increasingly harder.

If you really know the CPU and system architecture well I would imagine that 
a skilled programmer could write a small section of assembler to run faster 
than a compiler, just because humans are better at that sort of optimisation 
(they can consider a lot more things intelligently that a compiler can't, 
for example changing the algorithm slightly to better match the hardware). 
But humans tend to be very slow at this, a compiler can perform simpler 
optimisations over much larger programs far quicker.

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Nothing is faster than C, some wise men said. ;)

  Someone claimed to me once that fortran has some tricks in its sleeve with
certain types of mathematical programming that allows it to generate much
faster code than C can. In order to get the same speed with C you have to
resort to (obviously non-portable) inline asm.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
> Well it really depends on how *difficult* it is to match or beat any 
> language with assembler.  It's always theoretically possible, but as you 
> say with modern CPU and compiler design it is becoming increasingly harder.

That was exactly my point. You can always disassemble the output of the C 
compiler to get assembler code, so C cannot by definition beat assembler. 
Nor can anything else.

It's merely a question of how much you're willing to pay to scrape out those 
last few cycles, and whether you really need those last few cycles. But the 
same applies to anything else. Could you take Bellcore's database systems 
with hundreds of millions of lines of SQL stored procedures and rewrite it 
entirely in C? Certainly. Is it worthwhile doing it that way to speed it up? 
Of course not.

So saying that one language is faster than a completely different language 
is one of those FUD overgeneralizations. It's true in some cases, and not in 
others. How fast is C at building and analyzing parse trees that are too big 
to fit in memory? You're probably better off abstracting the problem, either 
with a library or a programming language, and the programming language will 
be able to make better global choices than any straightforward library.

I suspect most people using C and C++ and such don't really ever profile 
parts of their applications they didn't write. They don't look for speedups 
in the runtime libraries, or Boost, or pthreads, or whatever else they're 
using. Just like there are few people who actually compare the speed of 
garbage collection against the speed of manual memory management in real 
programs, and just assume that if the programmer's managing it, it must be 
faster. But it isn't always, exactly because the GC engine can do the kind 
of global analysis that the C compiler does for things like register 
allocation.

Of course the holy grail is a programming language that *is* high level and 
easy to use while also being capable of being turned into extremely 
efficient machine code.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Warp wrote:
> nemesis <nam### [at] gmailcom> wrote:
>> Nothing is faster than C, some wise men said. ;)
> 
>   Someone claimed to me once that fortran has some tricks in its sleeve with
> certain types of mathematical programming that allows it to generate much
> faster code than C can. In order to get the same speed with C you have to
> resort to (obviously non-portable) inline asm.

I can't comment on whether that's true, but I know there is a fairly 
large codebase of existing numerical-processing stuff in Fortran...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:
> So saying that one language is faster than a completely different 
> language is one of those FUD overgeneralizations. 

Oh, and as another example, COBOL. It's much faster to do stuff like decimal 
math and print formatting in COBOL (where it's built in) than C, especially 
if your processor has instructions for it.

Plus, many processors these days are built for C and are hard to change. 
Back when people were loading microcode themselves, machines running LISP or 
Smalltalk were quite fast compared to those machines running C with the same 
instruction set. It's more like "modern instruction sets favor C-like 
languages" than anything else.

Stuff like dynamic dispatch in objects could be individual CISC instructions 
and greatly speed things up, for example.

I'm also not sure if some of the Java hardware dosn't run Java faster than 
it would run C.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Warp wrote:
>   Someone claimed to me once that fortran has some tricks in its sleeve with
> certain types of mathematical programming that allows it to generate much
> faster code than C can.

There's two tricks Fortran has...

1) It's OK to do single-precision math on two single-precision values.

2) It's not OK (simplified) to alias two values together and use them in the 
same expression, so the compiler can assume less aliasing and keep more 
stuff in registers over assignments. That makes it much easier to have a 
loop doing B[I] = C[I] + A[I] and vectorize it, knowing B != A != C.

I think the later C standards improved (or tried to) on both these fields.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message