Questions about blocks

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions about blocks

Mike Miller
Hi cfe-dev,

Couple questions about support for blocks in clang:

1. How does block support on Linux/FreeBSD compare with that of Mac OS X? Is there a performance difference? If so, has anyone quantified it?

2. What is the status of blocks in C++ code? Can I use a block anywhere (sensible) in a C++ function, and freely reference C++ objects within the block? How does compiler-rt handle capturing the C++ objects?

3. (Somewhat OT for this mailing list) How well does GCD perform on Linux/FreeBSD vs. Mac OS X? Has anyone quantified the differences?

Thanks!
Mike



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Questions about blocks

David Chisnall
On 14 Oct 2010, at 10:49, Mike Miller wrote:

> Hi cfe-dev,
>
> Couple questions about support for blocks in clang:
>
> 1. How does block support on Linux/FreeBSD compare with that of Mac OS X? Is there a performance difference? If so, has anyone quantified it?

They generate the same code, so there should be no difference.

> 2. What is the status of blocks in C++ code? Can I use a block anywhere (sensible) in a C++ function, and freely reference C++ objects within the block? How does compiler-rt handle capturing the C++ objects?

The compiler generates helper functions that call the copy constructors and destructors for __block-qualified C++ objects.  The runtime then calls these functions.

> 3. (Somewhat OT for this mailing list) How well does GCD perform on Linux/FreeBSD vs. Mac OS X? Has anyone quantified the differences?

No idea.  Niels Grewe got libdispatch working with the blocks runtime from libobjc2 and with libkqueue on Linux last week, but I don't think he's done any performance tests.  I don't know if there is a native epoll / timerfd port for Linux underway, but that would probably improve performance.  On FreeBSD-HEAD, the userland code is pretty much identical (modulo the Mach-specific stuff), so the only performance difference is likely to be due to whether the kernel makes good decisions about the number of threads per work queue.

The difference from other threading strategies is likely to be less pronounced because the pthread implementation on Darwin is, quite frankly, an embarrassment and so anything that gets you away from using it for things like synchronisation is likely to be an improvement.  Neither FreeBSD nor glibc have quite such atrocious mutex implementations, for example.

David
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev