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

[Luis Antoniosi (CoCoDemus)]

The vtable is per class and not per object. Each object has a pointer to
it's vtable.
 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
>