Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   It's certainly not a good idea to create, resize and destroy 6 vectors
> > at each iteration.

> And in a well-tuned GC system, that's less of a problem, see? :-) 

  You and your obsession. It has nothing to do with GC. I has to do with
memory allocation strategies and optimization. There's nothing inherently
inefficient in non-GC'd allocation nor anything inherently efficient in
GC'd allocation. We are talking about *allocation* here, not deallocation.
There's basically no difference between GC'd and non-GC'd allocation.

  A non-GC'd regular C++ allocator can be made extremely fast (there are
many practical demonstrations of this). For some reason, however, most
compilers prefer the space-optimal allocation scheme to the speed-optimal
one.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> > And in a well-tuned GC system, that's less of a problem, see? :-)

> Somebody uses a C++ feature inefficiently, and that proves GC is better??

  In many (or most) GC'd languages (such as Java) memory allocation
(iow. 'new') is demonstrably faster than in most C++ implementations.
This is not a problem in C++ or an advantage of GC in particular, but
a question of how the allocator used by the compiler works. For some
reason memory allocation speed is not something which has been optimized
to death in C(++) compilers, for whatever reasons (even though most other
things have been). It's not a problem with the language itself, but a
problem with compilers (or, to be more precise, their libraries).

  For some reason Darren wants to think that the faster speed of memory
allocation in most GC'd languages is *because* of GC in particular (as if
those speeds were not possible in non-GC'd languages). This is demonstrably
not true. There's nothing in GC in particular which would make allocation
faster. It's just that GC engines have been more optimized for allocation
than most C(++) memory allocators.

  I have to admit this is a shame to C and C++. OTOH, it cannot be blamed
on the languages, but on the compilers and their libraries.

-- 
                                                          - Warp

Post a reply to this message

Anyway, the C++ version was a port of the C# version... when I get home tonight,
I'm going to write the physics stuff from scratch in C++, and see what effect
that has.

For one thing, I found that I had to design the classes differently in C# than I
would have normally.  There's probably something in there that's hurting
performance.

--
.....Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Warp wrote:

>   In many (or most) GC'd languages (such as Java) memory allocation
> (iow. 'new') is demonstrably faster than in most C++ implementations.
> This is not a problem in C++ or an advantage of GC in particular, but
> a question of how the allocator used by the compiler works. For some
> reason memory allocation speed is not something which has been optimized
> to death in C(++) compilers, for whatever reasons (even though most other
> things have been). It's not a problem with the language itself, but a
> problem with compilers (or, to be more precise, their libraries).

Maybe because allocating memory is a "rare" operation in C / C++ so 
there's not as much need to optimise it?

(Certainly in a language like Java, if you *don't* optimise the 
allocation of memory, the thing will crawl...)

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

Post a reply to this message

Warp wrote:
> reason memory allocation speed is not something which has been optimized
> to death in C(++) compilers, for whatever reasons 

I'm suspecting it's because C and C++ use pointers rather than 
references, and can't carry around enough metadata (generally speaking) 
to allow finding the pointers in a data structure, so they can't compact 
memory. That means that finding free memory is generally a search.

> There's nothing in GC in particular which would make allocation
> faster. 

Generally, yeah, there is. Allocation of a structure in a compacting GC 
implementation is almost always as fast as allocating something on the 
stack in C++. When it isn't, it's because you have to run a compacting 
GC cycle first.

> It's just that GC engines have been more optimized for allocation
> than most C(++) memory allocators.

That's what I said.

>   I have to admit this is a shame to C and C++. OTOH, it cannot be blamed
> on the languages, but on the compilers and their libraries.

I'm not sure that's 100% true.  Often, taking a big program with a 
hand-crafted allocator just for that program, and replacing it with a 
GC'ed memory allocator, will actually run faster.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
> There's basically no difference between GC'd and non-GC'd allocation.

This is incorrect. A GC allocation is adding the size of a structure to 
the pointer, just like allocating something on the stack is. If you 
can't move stuff around after it's allocated, it becomes extremely hard 
to beat this speed.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

> Warp wrote:
>> reason memory allocation speed is not something which has been optimized
>> to death in C(++) compilers, for whatever reasons 
> 
> I'm suspecting it's because C and C++ use pointers rather than 
> references, and can't carry around enough metadata (generally speaking) 
> to allow finding the pointers in a data structure, so they can't compact 
> memory. That means that finding free memory is generally a search.

Well, you can't move objects around in memory to compact, that is true. 
However, nothing stops a memory allocator from keeping lots of metadata 
internally to find free memory quickly.

How do filesystems know what empty blocks are available to save a new 
file? A linear search from the beginning of the disk?

Post a reply to this message

Nicolas Alvarez wrote:
> Well, you can't move objects around in memory to compact, that is true. 
> However, nothing stops a memory allocator from keeping lots of metadata 
> internally to find free memory quickly.

Sure. If you're always willing to (for example) allocate powers of two 
for memory, and you keep a free list for each power of two, then you can 
allocate and free pretty quickly. The problem is this wastes even more 
space than a compacting GC does, and you still have to do some 
management to coalesce adjacent free blocks eventually.

> How do filesystems know what empty blocks are available to save a new 
> file? A linear search from the beginning of the disk?

It's a lot easier when you can fragment your allocations. If all your 
allocations are one page in size, yah, it's also pretty easy to go fast. :-)

Put it this way: there's nothing a "manual" non-compacting allocation 
could do to make allocation faster than you could with a compacting GC 
scheme, or the compacting GC scheme could just use that technique to 
allocate stuff, then do a GC if it ran out of memory.

But don't argue with *me*.  Go look up the research papers on the 
efficiency of manual and automatic memory management. I already posted a 
list once.

The most interesting recent one I found points out that if you take 
typical Java programs, find objects that are allocated but their 
pointers never get passed outside the immediate scope and add bytecodes 
to "manually" free them, it goes even faster and uses even less memory. 
So, basically, if you detect that you *could* stack-allocate it, and 
then do, you get the best of both worlds, with very few "I could have 
stack allocated it but didn't" situations.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

scott wrote:
> But what is the CPU % when your frame rate first drops to 30 from 60?  

> 380   30  25
> 480   10  40
> 515    3  48
> 520    1  50

0   0% 60fps
100 1% 60fps
200 3% 60fps
300 5% 60fps
400 25% 32fps
500 33% 21fps
550 43% 9fps

Doh!  Sitting down to do real timings helps :)

OK, I'll work on the graphics code next.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Darren New wrote:
> Warp wrote:
>> There's basically no difference between GC'd and non-GC'd allocation.
> 
> This is incorrect. A GC allocation is adding the size of a structure to 
> the pointer, just like allocating something on the stack is. If you 
> can't move stuff around after it's allocated, it becomes extremely hard 
> to beat this speed.

Or, to phrase it a different way that might make it more clear...

How fast can you make your malloc() implementation if you know that 
nobody will ever call free()?  Pretty straightforward, given sbrk(), yes?

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message