Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

tsee (4409)

tsee
  {smueller} {at} {cpan.org}
http://steffen-mueller.net/

You can find most of my Open Source Perl software in my CPAN directory [cpan.org].

+ -

  Comment: Somebody needs to fix the docs (Score 1) on 2010.08.16 2:51

by tsee on 2010.08.16 2:51 (#72318)
Attached to: Class::XSAccessor now even faster'er

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.

Read More 1 comments
Comments: 1
+ -

  Comment: PerlC array conversions (Score 1) on 2010.06.13 1:44

by tsee on 2010.06.13 1:44 (#72048)
Attached to: Magic: too powerful?

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.

Read More 3 comments
Comments: 3
+ -

  Comment: Re:Done. (Score 1) on 2010.06.12 15:42

by tsee on 2010.06.12 15:42 (#72047)
Attached to: ZeroMQ: Fastest. Messaging. Ever.

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.

Read More 4 comments
Comments: 4
+ -

  Comment: Re:Done. (Score 1) on 2010.06.12 15:34

by tsee on 2010.06.12 15:34 (#72046)
Attached to: ZeroMQ: Fastest. Messaging. Ever.

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!

Read More 4 comments
Comments: 4
+ -

  Comment: Done. (Score 1) on 2010.06.12 14:45

by tsee on 2010.06.12 14:45 (#72045)
Attached to: ZeroMQ: Fastest. Messaging. Ever.

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.

Read More 4 comments
Comments: 4
+ -

  Comment: Plain XS? (Score 1) on 2010.06.12 2:56

by tsee on 2010.06.12 2:56 (#72043)
Attached to: ZeroMQ: Fastest. Messaging. Ever.

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)?

Read More 4 comments
Comments: 4
+ -

  Comment: Any of the GUI toolkits (Score 1) on 2010.06.09 11:56

by tsee on 2010.06.09 11:56 (#72034)
Attached to: Strawberry Win32 GUI programming

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.

Read More 9 comments
Comments: 9
+ -

  Comment: Sounds great! (Score 1) on 2010.06.04 2:59

by tsee on 2010.06.04 2:59 (#72017)
Attached to: BCVI 3.0 Hits CPAN

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

Read More 1 comments
Comments: 1
+ -

  Comment: Tiny nit (Score 1) on 2010.05.27 2:55

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/

Read More 6 comments
Comments: 6
+ -

  Comment: Almost damn right! (Score 1) on 2010.04.08 9:00

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

Read More 26 comments
Comments: 26
+ -

  Comment: Re:I gave it a super-quick shot... (Score 1) on 2010.03.25 17:08

by tsee on 2010.03.25 17:08 (#71796)
Attached to: Perl hashes in comparison to C, C++, Python and Ruby

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

Read More 2 comments
Comments: 2
+ -

  Comment: I gave it a super-quick shot... (Score 1) on 2010.03.25 17:05

by tsee on 2010.03.25 17:05 (#71795)
Attached to: Perl hashes in comparison to C, C++, Python and Ruby
Comments: 2
+ -

  Comment: threads ain't slow. (Score 1) on 2010.03.12 11:16

by tsee on 2010.03.12 11:16 (#71775)
Attached to: Making threads suck less in Padre

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

Read More 5 comments
Comments: 5
+ -

  Comment: fork isn't portable (Score 1) on 2010.03.12 11:13

by tsee on 2010.03.12 11:13 (#71774)
Attached to: Making threads suck less in Padre

"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

Read More 5 comments
Comments: 5
+ -

  Comment: Re:Wx loading (Score 1) on 2010.03.12 11:09

by tsee on 2010.03.12 11:09 (#71773)
Attached to: Making threads suck less in Padre

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.

Read More 5 comments
Comments: 5