use Perl

Now that I read your post, I realized that the Class::XSAccessor docs still claim it's 2-3 times faster than a hand-optimized pure-Perl accessor (sub foo {$_[0]->{foo}}). According to Chocolateboy's benchmark run as well as yours, this would now be 3-4 times.

I wouldn't mind if anybody beat me to twiddling the bits in the documentation in Alias' open repository.

I don't have those sitting on my hard drive, but if C++ were a start, you could have a look at

http://cpansearch.perl.org/src/SMUELLER/SOOT-0.09/src/CPerlTypeConversion.h

and

http://cpansearch.perl.org/src/SMUELLER/SOOT-0.09/src/PerlCTypeConversion.h

No claim about the code not leaking, being efficient, elegant or correct.

PS: the message size and roundtrip count are arbitrary. Even for small messages, the Perl wrapper isn't that much slower.

Furthemore, Perl server + Perl client comes in at 48.237 [us] latency, which is seems to indicate that wrapping 0MQ with Perl incurs a penalty of 8us each way. Not bad, could be better.

A Message size of 1 instead of the 10k yields 30us latency for Perl vs Perl.

Also did some quick timing.

The basic latency test looks promising. For the native C version from 0MQ (running on the client and server on the same dual-core machine via tcp), I get:

message size: 10000 [B]
roundtrip count: 20000
average latency: 32.631 [us]

With my Perl client (C server), I get:

message size: 10000 [B]
roundtrip count: 20000
average latency: 40.767 [us]

I'd say that's pretty damn awesome!

Not using FFI, as noted in my previous reply.

See http://github.com/tsee/ZeroMQ-Perl

Documentation doesn't exist yet. My time for this is pretty much exhausted, so people will have to go by the C++ docs of 0MQ2 itself. If somebody was willing to write a little documentation and maybe write some more tests, we could a) release to CPAN and b) advertise this to 0MQ as a Perl interface for inclusion in their list. I think the documentation should be doable in 1-2 hours.

Isn't wrapping it in plain XS the easier and faster route for anything that goes beyond simple types (which are easy to do with FFI)?

Any of the GUI toolkits that are available from CPAN?

- Wx
- Tk
- Win32::GUI ...

Should all work either out of the box or after a simple "cpan" invocation. I haven't used the latter toolkit, though.

Thanks for writing about bcvi. I'll give it a shot and it really sounds like something that'll be a great replacement for a whole bunch of crappy scripts I have accumulated over the years.

--Steffen

I should file this as a bug or fix it in SVN myself, but there's a small typo in the synopsis of 0.90: s/\$wormhole/\$aspect/

... and this is why strictures will be the default in Perl. Modules have no business mucking with your namespace, as you say. Perl does.

Note that warnings won't be the default for various reasons.

Oh, hasn't appeared yet (moderation?). Below is the text of my comment. In a nutshell, for the cases benchmarked, perl is somewhat faster than python (and a lot faster than Ruby) and uses about as much memory as Ruby, which is somewhat less than Python.

I did a quick-and-dirty implementation for Perl-hashes. Take the results with a grain of salt. I made a coding mistake with the deletion benchmark, so I didn't include it. I also skipped the integer benchmarks because Perl doesn't have an integer hashmap. You can insert integers, but they'll be converted to strings anyway, so you get the same performance as with strings. Results: http://steffen-mueller.net/hashbench/charts.html Code: http://steffen-mueller.net/hashbench/perl_hash.c Makefile: http://steffen-mueller.net/hashbench/Makefile

http://incise.org/hash-table-benchmarks.html#comment-41586779

PS: ithreads aren't slow per se. It's just the communication between them that sucks. Just like communication between processes...

"And if we can drop this further to around 5 meg, we get close to the memory cost of a forking/process model, which is the only other parallelism model available in the short term that supports many cores transparently."

Yes, but it's not really available because it's not portable to win32. Besides: A lot of the memory you save with the fork() copy-on-write may eventually be copied when accessed by Perl. Pseudo-code:


my $foo = 1.;
fork();
# $foo SV shared
if ($foo == 1) {}
# $foo SV likely not shared any more => integer conversion modified the SV


Well, it was actually a bit different. I implemented the SlaveDriver bit because it's a precursor to being able to use the wx-threading-only branch. I got sidetracked fixing the problems the new approach created for Padre. (Andrew Bramble did a lot of the fixing, actually!) Then, I got sucked into other work.