Re: [boost] 5 Observations - My experience with the boost libraries

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: David Bergman (David.Bergman_at_[hidden])
Date: 2010-03-23 21:38:23

On Mar 23, 2010, at 9:22 PM, Tom Brinkman wrote:

>>> but does that force us to constantly send that raw pointer around?
> 
> Yes, and it also has to be aligned.  The buffer must be carefully crafted
> with considerable attention to caching issues.
> 
> I kid you not, but I have seen some wild stuff.
> 
> I've worked on the Larabee platform, which is the next generation discrete
> graphics card from intel.  It has a 512K buffer, which means that you will
> be able to simultaneously process 16 floats.  When you combine this with the
> parallelism possibilities on the next Nahalem processor (8 cores, 16
> threads), you will be able to achieve processing speeds thousands of times
> faster then non-hardware optimized code.
> 
> Unfortunately, to take advantage of this, you will need to manage the memory
> yourself, which requires lots of old fashioned straight "C" style coding.

Really? One can do a lot of C++-neat things with POD's. And, just ridding the virtual table goes pretty far.

As someone else pointed out, with C++ and proper meta-programming tricks, one can even achieve optimal structure alignments for differing platforms with *one* codebase, which is pretty hard to do in C.

Well, this is definitely leading away from the initial problem, where you think that (at least certain) Boost libraries should have a C interface. Would be cool to get back on topic (partly my bad...) and see what libraries you want to change to a more Cish appearance and how that would look. We have heard about (s)printf, but that function already exists to a C++ developer ;-)

/David

> 
> 
> 
> On Tue, Mar 23, 2010 at 4:54 PM, David Bergman <
> David.Bergman_at_[hidden]> wrote:
> 
>> On Mar 23, 2010, at 7:40 PM, Tom Brinkman wrote:
>> 
>>>>> To you.  There are many graphics shops that make extensive use of c++
>>> *and* boost.
>>> 
>>> Not true.  Sure, we use C++ around the edges.  The actual graphics code
>> is
>>> all done in C.  There are no popular C++ graphics libraries.  Sorry.  Its
>>> not possible, graphics libraries require hardware acceleartion.
>> 
>> I never understood this idea that some libraries were not possible to build
>> in C++. And, specifically, what graphics hardware acceleration has to do
>> with C++(-specific) constructs. Are there intrinsic inefficiencies of C++
>> constructs (beside one indirection by virtual functions where they are
>> used)? Is it something else? Yes, most low-level API's require a pointer to
>> a memory area in the end, but does that force us to constantly send that raw
>> pointer around?
>> 
>> /David
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost