![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
> Actually I remember on my 32bit ARM CPU
Woohoo snap :) Genius.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |