Boost logo

Boost :

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Tom Brinkman (reportbase2007_at_[hidden])
Date: 2010-03-23 21:22:36


>> 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.

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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk