Does C::Blocks really require the perl keyword API to work?
It would be nice if there was a version that could work with
perl 5.10.x.
--Chris
On 8/4/2015 17:33, David Mertens wrote:
Hey Chris,
I wish I could say something more precise and causal about why PDL is
slowing down, but it's hard without measurements. I think the JIT has
some promise both in producing context-optimized code, but more
importantly for playing around with the internals.
The keyword API was introduced in v5.12. Also, I just found a way to
get lexical variable insertion working for Perls earlier than 5.18,
although I have not yet pushed it to CPAN.
David
On Tue, Aug 4, 2015 at 4:33 PM, Chris Marshall <[email protected]
<mailto:[email protected]>> wrote:
Neat, David. I'm looking forward to trying...
What version of perl is required to support the keyword API?
Regarding the latency comparison, the C::Blocks implementation
is arguably close to optimal latency to issue a perl operation.
The motivation for JIT compiling for PDL3 is precisely to address
the problems of latency and extra memory motion (cache thrash).
Your timings indicate that this approach for JIT has promise for
some significant performance improvements.
--Chris
On Tue, Aug 4, 2015 at 1:35 PM, David Mertens
<[email protected] <mailto:[email protected]>> wrote:
Hello everyone,
While this is not strictly a PDL announcement, it is something
that will undoubtedly be of interest to PDL users, and may
even be of interest to PDL developers.
Yesterday I pushed the first "alpha" release of C::Blocks
<https://metacpan.org/pod/C::Blocks>, a module designed to
make it much easier to write and share C code and data
structures among your Perl code.
How does this work? C::Blocks uses Perl's keyword API to add
the "cblock" keyword
<https://metacpan.org/pod/C::Blocks#Procedural-Blocks> (among
a couple
<https://metacpan.org/pod/C::Blocks#Private-C-Declarations> of
<https://metacpan.org/pod/C::Blocks#Shared-C-Declarations>
others <https://metacpan.org/pod/C::Blocks#csub-name-code>).
This keyword expects a curly-bracket-delimited block of C code
that gets executed in-place. It achieves this by jit-compiling
the block of C code and inserting an OP in place of the block
of code during Perl parse time.
There are two technical problem that I had to solve to get
C::Blocks to be computationally effective. First, C::Blocks is
built on my own fork of the Tiny C Compiler
<https://github.com/run4flat/tinycc> that makes it possible to
make a copy of a compilation unit's symbol table. This makes
it possible to declare a struct definition, write a function,
or #include a set of header files in one (clex or cshare)
block, and have other blocks use that information without
having to recompile any of it. Second, this extended symbol
table information can be cached and quickly loaded from disk,
something that I use to rapidly load Perl's C API
<https://metacpan.org/pod/C::Blocks::PerlAPI>.
In this case, "alpha" means that it passes its test suite on
at least one of the operating systems I have access to
(Linux), and it compiles and passes at least some tests on all
operating systems that I have access to (Mac and Windows). In
other words, it looks like it'll fly, but it's still quite
fragile. The goal for the alpha release series is to iron out
the bugs and get it to compile and pass all of its tests on
all major platforms.
I have worked on a few benchmarks
<https://metacpan.org/source/DCMERTENS/C-Blocks-0.01/bench>
for C::Blocks and have been quite surprised by the results. So
surprised, in fact, that I had to double-check that my Perl
had been compiled with decent optimization (it had).
Benchmarks on my Linux laptop indicate that for simple
operations (i.e. sum) on small arrays (N < 3000), PDL's method
setup and teardown are so costly that they dominate the
calculation, and C::Blocks code wins handily. PDL gets the
upper hand near N = 10,000, but only beats C::Blocks by a
factor of 2. A more interesting benchmark was for the
operation "sqrt(sum($pdl_data*$pdl_data))", an N-dimensional
Euclidean distance. For this, the C::Blocks equivalent code
was comparable except in the vicinity of N = 100,000, where
PDL beat it by a factor of 2. The method setup and teardown
dominated PDL performance for small N, and for large N the
memory allocations and re-allocations degraded PDL's
performance to the point that they both performed the
calculation at essentially the same rate.
You can learn more about C::Blocks at the CPAN page:
https://metacpan.org/pod/C::Blocks.
David
--
"Debugging is twice as hard as writing the code in the first
place.
Therefore, if you write the code as cleverly as possible,
you are,
by definition, not smart enough to debug it." -- Brian Kernighan
------------------------------------------------------------------------------
_______________________________________________
pdl-general mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/pdl-general
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
------------------------------------------------------------------------------
_______________________________________________
pdl-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-general
