Yes, thanks for clarifying that.

An XS author writes XS, which is sorta-C with a lot of Perl framework. This gets compiled down to actual-C, and then to a library (.so, .dll, etc), which is loaded by perl using DynaLoader or XSLoader.

Writing XS can be somewhat of a pain; there's boilerplate, cargo-cult, Perl guts/API stuff, and enough C to give one the impression of knowing what's going on. A module like Inline::C aims to reduce the boilerplate, and automate some of the process. The upcoming Inline::Module will further improve upon Inline by allowing Inline-authored distributions to ship with no Inline dependency.

But Inline:: is really an automation tool to produce the common-case XS with less fuss.




Dave

The easy way is to just copy the modules that make up Inline and Inline::C into your program. For example using PAR::Packer, you can create a one-file distribution that uses these modules. The modules will require some additional configuration, but conveniently, Perl comes with a program that downloads, configures and installs additional modules.

Note that you will also need a C compiler on your target machine.

Also, let me question the wisdom why you think that Inline::C is a solution where you are unable to install other modules.

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




Dave

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.

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

use Inline::C;
[download]

This reminded me of an old node from 2009 with code to wrap external asm directly without Inline. There's another post floating in my head that did similar Dynaloader trickery but Super Search didn't spit anything useful out.

It is really, really crucial that you objectively determine ... do not guess ... exactly where your present, one-language solution (or, solutions) are spending their time.   Most applications follow the 80/20 rule:   80% of the time is spent in 20% of the code.   Also, in most cases an application spends most of its clock-time in the theatre ... “waiting for god-I/O-t.”   You gain no advantage at all if you optimize what the app does not spend most of its time doing.   But if the application does do “something very-computational millions of times,” it creates a hot-spot that might benefit from being recoded in an XS subroutine.   Many of the CPAN packages that you use every day, do have an XS optimization or three ... as well, as, usually, a “pure-Perl” alternative.

Most applications wind up doing exactly the same handful of things ... especially, data-structure manipulation.   This is where Perl and other languages shine.   The “overhead” of having a bytecode-interpreter in the center of everything is small enough that it can be ignored, as can the one-time cost of translating source-code into bytecode, and the logic within the interpreter that does the “heavy lifting” (hashes, lists, memory manager, and such ...) is both thoroughly optimized and thoroughly debugged.   Since it takes a lot less time to use [Perl] to accomplish a result that runs pragmatically “just as fast as” something that you labored days on hand-crafting, Perl wins a lot of hands.   The time that you save, is your own.