> What this means is that any programming language that features automatic 
> memory management is instantly many hundred times slower than a language 
> using manual memory management, and there's nothing you can do about it.
>
> I find that sad.

What's sad is if the authors of such languages have not thought about cache 
usage when designing the compiler.

I don't see how it's any different to people using BASIC complaining that 
they can't benefit from the "count down to zero" loop because BASIC won't 
let them remove the extra compare instruction.

As always, if you want complete control over the CPU use assembler, if you 
want a little less control use a language like C.  You use higher level 
languages to make writing the code easier, but you lose direct control of 
the CPU.

Post a reply to this message

scott wrote:

> What's sad is if the authors of such languages have not thought about 
> cache usage when designing the compiler.

What's sad is that a cache need to exist in the first place. It means 
that whole classes of highly efficient algorithms aren't efficient any 
more. It means you have to mutilate your program designs just to keep 
the cache happy.

But still, there's nothing that anybody can ever do about it, so I guess 
there's no point worrying about it...

> As always, if you want complete control over the CPU use assembler, if 
> you want a little less control use a language like C.  You use higher 
> level languages to make writing the code easier, but you lose direct 
> control of the CPU.

I don't *want* low-level control over the CPU - the sad thing is that 
with current designs, it's completely necessary if you want any 
semblance of performance. With current designs, it seems that basically 
any attempt to use any language higher than assembly is doomed to abject 
failure, performance-wise. And this saddens me.

Post a reply to this message

> What's sad is that a cache need to exist in the first place. It means that 
> whole classes of highly efficient algorithms aren't efficient any more. It 
> means you have to mutilate your program designs just to keep the cache 
> happy.

Ermm, caches make things faster and more efficeint to varying degrees, not 
slower.

Post a reply to this message

scott wrote:

> Ermm, caches make things faster and more efficeint to varying degrees, 
> not slower.

Caches make _some_ things faster. Other things stay laughably slow. :-(

Post a reply to this message

>> Ermm, caches make things faster and more efficeint to varying degrees, 
>> not slower.
>
> Caches make _some_ things faster. Other things stay laughably slow. :-(

So what's the problem then?  Some things are faster, others stay the same 
speed.

Unless, of course, you could afford to have 8GB of on-die RAM at the same 
speed as the L1 cache :-)

Caches are just a very cost effective way of speeding most things up, do you 
have a better suggestion?

Post a reply to this message

Invisible wrote:
> What this means is that any programming language that features automatic 
> memory management is instantly many hundred times slower than a language 
> using manual memory management, and there's nothing you can do about it.

Huh? Where did you come up with this factoid? GC can actually help improve 
cache hits, while manual memory management requires you to touch all kinds 
of pages at times when it might not be beneficial. For example, if you need 
to free the root of a large tree on the heap, using manual memory 
management, you now have to run through the whole tree, touching every page 
where there's a leaf, and cleaning it up. If 50 instructions later you free 
another tree, you have to do that all again, even if it's all in the same 
pages as the first tree.

Of course, the higher level the language is, the more opportunity for 
optimizations. For example, the talk on that page about what the .NET system 
does is incorrect. That's the .NET that was around when they wrote that 
sentence. You can (and always could), of course, precompile an entire 
assembly, rather than waiting for JIT - of course the data structure 
libraries don't get recompiled every time you run the program. And later 
compilers will do all kinds of cross-assembly optimizations if you want, in 
a way that would be very difficult for a C compiler to manage (like taking 
unused slots out of a struct to save memory).

> But still, there's nothing that anybody can ever do about it, so I guess there's no
point worrying about it...

Sure there is. Slow your CPU down a whole bunch. Happy now?

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

scott wrote:
> Actually I remember on my 32bit ARM CPU

Woohoo snap :) Genius.

Post a reply to this message

Nicolas Alvarez wrote:
> 
> Einstein already said you can't go faster than c...
> 

LOL, good one in deed :-D

Post a reply to this message

My personal opinion:
As you know I don't know much of programming but for I've seen C (ANSI 
C, C++, C# and al the variants) is the King Language, if it keeps 
evolving in its abstractions/implementations to cover more needs it will 
be there for ever or at least until a better language come along, if so, 
I'm sure will have to be based on C at least conceptually.

C I believe is a reference for the other languages, like the Grandfather 
of programming languages.

FWIW I believe C should have a kind of optimizer/distiller that gives 
the assembler-level optimized (speed and/or size) .exe image, for every 
hardware platform, so the programmer doesn't have to worry about 
low-level tricks and concentrate more in the program abstract idea and 
its implementation. I think the compiler gives optimizations only by 
changing the order of the statements because it's partially optimized 
according to certain statement criteria it recognizes but not fully 
optimized for the assembly language level.

Cheers.

Post a reply to this message