This will be changing soon. Right now ingy dot net and I are working on Inline::Module, which will allow authors to develop an XS extension using Inline and Inline::C (or Inline::CPP), and then with a simple command convert that to an XS distribution, free of the Inline dependency.
This provides the author with the assistance of Inline, and the user with the light-weight-dependencies and characteristics of common XS.
The project is ongoing, but should be pretty much ready to start using within a week or two. After that, additional polish will be applied as needs are discovered. This work is being supported in part by a Perl Foundation Grant. And we have a blog that discusses our progress at http://inline.ouistreet.com. (Sneek preview; the Week #3 report, due out Saturday night, will reveal that we've got all stages working now.)
Work is being done out in the open as much as possible. As we're working, we communicate realtime in #inline on irc.perl.org. Visitors (and possible code contributors) are welcome to drop by. There won't be much action today due to some travel, but when we are working together you'll see ingy coming up with crazy/cool ideas, and me trying to keep up. ;)
| [reply] |
I'm interested in core possibilities for "competitive programming". If I could access lower level language, it could helps me to cope with big-data faster?..and I could switch back to Perl to use it's (slow) magics finally.
And if I learn something using online interpreters like ideone.com, I can't install modules there. | [reply] |
rsFalse,
I suggest you do some benchmarks on what you want to do before declaring Perl to be "slow". I have some Perl "big-data" products that compete very well against similar "C" products. YMMV!
Many times is the mathematical algorithms/techniques/etc. that determines the final performance, and Perl is excellent at allowing you to quickly optimize.
I started out with similar views, but Perl won me over. You may be surprised at the performance of your well-designed "competitive programs".
Regards...Ed
"Well done is better than well said." - Benjamin Franklin
| [reply] |
I agree with this. I have rewritten several C programs in Perl over the last year and a half or so and succeeded to improve very significantly the performances. In part because Perl enabled me to use hashes, having much faster access than scanning sequentially a C array. Of course, if we had a C library offering a behavior similar to Perl's hashes, C would become better. But there no such library that we know of for our version of our OS, so that Perl is the clear winner (admittedly, we could write a fast look-up C library, using indexed array access or a hashing function, but, even assuming we could do that efficiently, that would be a lot of work for very limited benefit). And, at the end of the day, it takes us so much less time to write a Perl program than a C program that, if the Perl program gives enough performance, I don't even wans=t to consider the C alternative.
Having said that, there are of course some cases (e.g. heavy mathematical calculations) where C extensions (with Inline C, XS or some other mechanism) will bring a real advantage (in terms of costs and benefits analysis) over pure Perl. I haven't seen yet a case where this would be the case in our work environment.
| [reply] |