Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Inline::C on Windows: how to improve performance of compiled code?

by ikegami (Patriarch)
on Jun 15, 2018 at 15:24 UTC ( #1216717=note: print w/replies, xml ) Need Help??


in reply to Inline::C on Windows: how to improve performance of compiled code?

Are both builds threaded?

  • Comment on Re: Inline::C on Windows: how to improve performance of compiled code?

Replies are listed 'Best First'.
Re^2: Inline::C on Windows: how to improve performance of compiled code?
by syphilis (Archbishop) on Jun 16, 2018 at 03:34 UTC
    Are both builds threaded?

    Yes, I wondered about that, too.

    When I ran vr's original code on Ubuntu, with both threaded and unthreaded builds of perl-5.26, the timings didn't alter significantly.
    But I didn't have an unthreaded Windows build to test with.

    I have now built one (perl-5.26) only to discover that one can't install a usable Inline::C because Win32-IPC (more specifically, Win32-Mutex) doesn't compile.
    One can successfully force install Inline::C, but it's unusable.
    Unfortunately, Win32::IPC builds using Module::Build - and I simply cannot stomach any troubleshooting that involves Module::Build.

    It would have been nice to verify whether an unthreaded build on Windows does access Inline::C functions faster.
    Maybe someone else ....

    Cheers,
    Rob
      One can successfully force install Inline::C, but it's unusable

      While that's so for the latest version of Inline::C, it's quite simple to install older versions of Inline::C on the unthreaded Windows (as they don't carry the Win32::IPC baggage that comes with recent versions).
      So, I installed Inline-0.55, though I perhaps didn't need to go that far back.
      Here are the results using vr's original one-liners:

      On threaded perl-5.26.0 with current Inline::C version 0.78:
      >perl -MTime::HiRes=time -MInline=C,"void foo(){}" -wE"$t=time;foo()fo +r 1..1e8;say time-$t" 11.0136189460754 >perl -MTime::HiRes=time -wE"$t=time;sub foo(){}foo()for 1..1e8;say ti +me-$t" 5.39761018753052


      On threaded perl-5.26.0 with Inline::C version 0.55:
      >perl -MTime::HiRes=time -MInline=C,"void foo(){}" -wE"$t=time;foo()fo +r 1..1e8;say time-$t" 10.4052181243896 >perl -MTime::HiRes=time -wE"$t=time;sub foo(){}foo()for 1..1e8;say ti +me-$t" 5.58481001853943


      On unthreaded perl-5.26.0 with Inline::C version 0.55:
      >perl -MTime::HiRes=time -MInline=C,"void foo(){}" -wE"$t=time;foo()fo +r 1..1e8;say time-$t" 4.92960906028748 >perl -MTime::HiRes=time -wE"$t=time;sub foo(){}foo()for 1..1e8;say ti +me-$t" 7.65961289405823
      It therefore appears that reverting to an older version of Inline::C makes very little difference, whereas using Inline::C on an unthreaded Windows perl-5.26.0 markedly improves performance when calling Inline::C subs from perl.
      Unfortunately, it also seems that calling perl subs on an unthreaded Windows perl-5.26.0 takes about 30% longer (as compared to the time it takes on the threaded perl).

      Of course, things might be quite different on the soon-to-be-released perl-5.28.0.
      And things might also be quite different on 32-bit builds of perl.

      Cheers,
      Rob

        ikegami, yes, both Perls are threaded 5.26 (it's in OP).

        syphilis, thanks a lot for your research. I still hope, C code can be compiled into "faster version" i.e. with speed on par with unthreaded or Linux Perls. Core XS modules don't run 2 times slower on Windows.

        Here's a little experiment. The hv_store (Hash::Util) is documented as

        hv_store() is from Array::RefElem, Copyright 2000 Gisle Aas

        (BTW, as an aside, some funny and interesting things can be done with aliases stored as aggregate elements, it seems references overshadowed this feature which has been there for free for decades, no new experimental "refaliasing" required for that (it's not surprising since they are "aggregate elements", not regular variables). But you know all that.)

        So, a couple weeks ago I accidentally found Hash::Util::hv_store is almost exactly 2 times faster than Array::RefElem::hv_store. I thought it strange but didn't investigate it then. Now:

        >perl -MTime::HiRes=time -MHash::Util=hv_store -wE"%h=();$t=time;hv_st +ore(%h,'foo',42) for 1..1e8;say time-$t" 10.8255708217621 >perl -MTime::HiRes=time -MArray::RefElem=hv_store -wE"%h=();$t=time;h +v_store(%h,'foo',42) for 1..1e8;say time-$t" 20.3003470897675 $ perl -MTime::HiRes=time -MHash::Util=hv_store -wE'%h=();$t=time;hv_s +tore(%h,"foo",42) for 1..1e8;say time-$t' 10.5545630455017 $ perl -MTime::HiRes=time -MArray::RefElem=hv_store -wE'%h=();$t=time; +hv_store(%h,"foo",42) for 1..1e8;say time-$t' 12.1946179866791

        The question is whether it's possible to compile anything (Array::RefElem or inline C) to be fast on threaded Win32 Perl. The fact that e.g. Hash::Util exists suggests the answer is "yes". But how? :)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1216717]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2022-08-13 13:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?