… | |
… | |
255 | first are two memory accesses and a predictable function call of an empty |
255 | first are two memory accesses and a predictable function call of an empty |
256 | function. |
256 | function. |
257 | |
257 | |
258 | Of course, the overhead is much higher when these functions actually |
258 | Of course, the overhead is much higher when these functions actually |
259 | implement anything useful, but you always get what you pay for. |
259 | implement anything useful, but you always get what you pay for. |
|
|
260 | |
|
|
261 | With L<Coro::Multicore>, every release/acquire involves two pthread |
|
|
262 | switches, two coro thread switches, a bunch of syscalls, and sometimes |
|
|
263 | interacting with the event loop. |
|
|
264 | |
|
|
265 | A dedicated thread pool such as the one L<IO::AIO> uses could reduce |
|
|
266 | these overheads, and would also reduce the dependencies (L<AnyEvent> is a |
|
|
267 | smaller and more portable dependency than L<Coro>), but it would require a |
|
|
268 | lot more work on the side of the module author wanting to support it than |
|
|
269 | this solution. |
260 | |
270 | |
261 | =item Low Code and Data Size Overhead |
271 | =item Low Code and Data Size Overhead |
262 | |
272 | |
263 | On a 64 bit system, F<perlmulticore.h> uses exactly C<8> octets (one |
273 | On a 64 bit system, F<perlmulticore.h> uses exactly C<8> octets (one |
264 | pointer) of your data segment, to store the C<perl_multicore_api> |
274 | pointer) of your data segment, to store the C<perl_multicore_api> |