[Coco] Somewhat OT: The life of a systems programmer

[Steven Hirsch]

On Sat, 16 Nov 2013, Luis Antoniosi (CoCoDemus) wrote:

> The vtable is per class and not per object. Each object has a pointer to
> it's vtable.

That's exactly what I said:  Defining a class as virtual ensures that 
every object of that class carries the overhead of an extra pointer to 
that v-table.  What's often overlooked is the effect of call dispatch 
through that table.  In extremely large datasets this results in 
additional TLB and cache thrashing.  That "doesn't matter" - unless it 
does.  Which is usually when you have to do it a billion times or so.

We were able to quantify this quite clearly in a recent project. 
Different architectures (Intel, Sparc, Power, etc.) have varying levels of 
ability to gracefully handle a high volume of TLB flushes.


> On 2013-11-16 10:02 AM, "Steven Hirsch" <snhirsch at gmail.com> wrote:
>
>> On Fri, 15 Nov 2013, Rich Carreiro wrote:
>>
>>  If you're done any low-level programming, and even if you
>>> haven't, you have got to read this absolutely hilarious piece
>>> from Usenix's ;login: logout magazine:
>>>
>>> http://research.microsoft.com/en-us/people/mickens/thenightwatch.pdf
>>>
>>
>> I got a chuckle out of that.  It's a bit reminiscent of the Unix Haters
>> Handbook by Jamie Zawinski.  That being said, C++ is really the only answer
>> for a lot of scientific and engineering problems.  The important thing is
>> not to get too carried away with arcane language features, use templates
>> sparingly, etc.  And, if you want high performance NEVER use virtual
>> classes to define data objects that are going to exist in extremely large
>> numbers.  In my world, you can end up with many billions of objects and the
>> V-table pointer adds eight bytes (assuming 64-bit architecture) to every
>> one of them.  If you are calling virtual methods an extremely large number
>> of times, the extra indirection through the V-table will also adversely
>> affect performance.
>>
>> Modern CS courses go on about "..don't sweat the small details, just
>> concentrate on the algorithm", but trust me - the small details can really
>> bite you in the butt when you are dealing with extremely large data sets.
>> How large?  A typical in-memory problem in the VLSI verification field can
>> be 4-500GB.  Some are larger - there's always a waiting list to get on one
>> of the few terabyte boxes.
>>
>> But, this has nothing to do with Cocos.  The thought of a Coco C++
>> compiler is hilarious.
>>
>> Steve
>>
>>
>> --
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

--