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

[vr]

Dual boot (i.e. same hardware), Ubuntu 17.10, Win10, threaded Perl 5.26 both. However, it seems some (default) flags (compiler options?) are set wrong for Inline::C on Windows. Here's output of no-op example for both systems:

$ perl -MTime::HiRes=time -MInline=C,'void foo(){}' -wE'$t=time;foo()f
+or 1..1e8;say time-$t'
5.57836294174194
$ perl -MTime::HiRes=time -wE'$t=time;sub foo(){}foo()for 1..1e8;say t
+ime-$t'
5.003093957901

>perl -MTime::HiRes=time -MInline=C,"void foo(){}" -wE"$t=time;foo()fo
+r 1..1e8;say time-$t"
11.325471162796

>perl -MTime::HiRes=time -wE"$t=time;sub foo(){}foo()for 1..1e8;say ti
+me-$t"
5.04568600654602

The use of Inline::C for particular case, where I noticed that, is exactly for huge number of calls of very simple sub (but not no-op, of course). I understand sub calls in Perl are expensive, I'll live with that, but I don't understand the result above.

To counter "it's because Linux is better", the script was moved from very old 32-bit Windows machine, and I noticed (though can't provide any solid numbers right now), that benchmarks for pure-Perl parts showed perhaps 6-fold speed improvement, while the main part, in C, no more than 2-fold. Therefore I have a suspicion about sub-optimal Inline::C defaults there, and i hope for hints of what could be changed.

[syphilis]

i hope for hints of what could be changed

The first hint that comes to mind is to perform the 1e8 function calls to foo() from inside C space, rather than from Perl space.
On top of the significant reduction in overhead, one then might also get to take advantage of C optimizations that are lost when the C function is called from Perl.
The following script aims at demonstrating the sort of savings you might get. I've changed foo() to be a little bit more than a no-op, in the hopes that it will remove the effect of clever C optimizations. (I don't know if I've been successful.):

use Time::HiRes qw(time);

use Inline C => <<'EOC';

int foo(int x) {return x + 1;}

int foo_bar(int x) {
  int i;
  for(i = 0; i < x; i++){
    foo(i);
  }
  return x + i;
}

EOC

$iterations = 10000000; # 1e7
$t = time;
foo($_) for 1 .. $iterations;
print "# ", time - $t, "\n";

$t = time;
foo_bar($iterations);
print "# ", time - $t, "\n";

# Outputs (on Windows):
# 1.57560181617737
# 0.0026400089263916

On my Ubuntu (16.04) box, running perl-5.26, the same script outputs:

# 1.80176305770874
# 0.0337138175964355

Cheers,
Rob

[vr]

# 18.2613549232483
# 3.09944152832031e-006

# 7.17122101783752
# 0.186490774154663

Those are results of running your example (with 1e8 iterations) on Windows and Linux, respectively. Looks to me, "C from C" on Windows got optimized away, but "C from Perl" gives same picture (lagging behind, W vs L) as in OP. And right now I'm interested in eliminating this lagging. Optimization to try to avoid 1e8 calls is in future plans ;).

[syphilis]

Looks to me, "C from C" on Windows got optimized away

I don't think so. (Could be wrong but.)
A clearer ilustration is (hopefully) this script:

use Time::HiRes qw(time);

use Inline C => Config =>
  #OPTIMIZE => '-O0',
  FORCE_BUILD => 1;

use Inline C => <<'EOC';

void foo() {}

void foo_bar(int x) {
  int i;
  for(i = 0; i < x; i++){
    foo();
  }
}


EOC

$iterations = 10000000;
$t = time;
foo() for 1 .. $iterations;
print "# ", time - $t, "\n";

$t = time;
foo_bar($iterations);
print "# ", time - $t, "\n";

As it stands, with optimization enabled, it outputs (on Windows):

# 1.02960205078125
# 1.00135803222656e-005

Now that second value does look like something was optimized away. I'm thinking the loop is simply doing nothing at each iteration.
When we switch optimization off by including the "OPTIMIZE => '-O0'" line, the output changes to (on Windows):

# 1.10760188102722
# 0.0196361541748047

The "C from C" code now takes 500 times longer to execute - because, I think, this time foo() is actually being called at each iteration. But it's still 50 times quicker than calling "C from Perl".

I've no useful ideas regarding things that can be done to enable Windows to access C subs as quickly as it can access Perl subs - and that's the main reason that I'm avoiding that aspect.

Cheers,
Rob

[BrowserUk]

What output do you get from perl -V:ccflags

[vr]

>perl -V:ccflags
ccflags=' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -D__USE_MINGW_ANSI_STD
+IO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SY
+S -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields';

$ perl -V:ccflags
ccflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe
+ -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D
+_FILE_OFFSET_BITS=64';

[ikegami]

Are both builds threaded?

[syphilis]

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

[syphilis]

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

[sundialsvc4]

We really need more information about what this program is actually doing, and how the C code relates to the Perl code. Your no-op example are precisely this ... no-ops ... and could only possibly be exercising the thunking logic that passes control to the inline environment and back. Could it be that the two Perl interpreters are compiled differently? "C" optimization can't possibly be a factor when the "C" subroutines don't do anything: the difference must be in the two Perl interpreters themselves.

[syphilis]

the difference must be in the two Perl interpreters themselves

Couldn't it alternatively be that the difference is in the way that the 2 different systems (ie Linux and Windows) access functions in external shared libraries ?

Cheers,
Rob

[Marshall]

Interesting question...

I came across a public article about linking and differences between Windows and Unix by Symantec:
Symantec, Dynamic Linking in Linux and Windows, part one
Symantec, Dynamic Linking in Linux and Windows, part two

This is not a "light read" and I did not study it in depth. I'm not sure if this article "jives" with what I heard 20 years ago..that Linux can load a .so faster than Windows can load a .DLL, because Windows has to adjust jump addresses and potentially make another copy of the DLL which takes time, but that once linked, calling (running) with the Windows DLL is faster? I was working on systems around the time that NT was a separate thing from Windows.

Anyway there appears to be a lot of detail for those inclined in the above articles.

I have never used Inline:C or linked to an external C program with Perl. I don't know what difference there may be with that either. BrowserUk does a lot of Windows combined with C stuff and hopefully he can shower some wisdom down upon us.

[sundialsvc4]

So, have we by now established that a one-liner which does absolutely nothing in the loop, as I suggested, does not run in a time comparable to the one that uses the no-op inline function, but runs considerably faster?   That my hypothesis that this does not actually have to with the inline implementation but is endemic to the Perl interpreter version itself, has therefore now been tested and has been proven false?   I wasn’t clear if this idea had been tried – or simply ignored – and what the outcome turned out to be, if it was tried.

[syphilis]

So, have we by now established that a one-liner which does absolutely nothing in the loop, as I suggested, does not run in a time comparable to the one that uses the no-op inline function, but runs considerably faster?

I don't think we have, as it was never really the issue.
The issue was more about some apparent additional overhead in calling XS subs on Windows, and what to do about it.

I do, however, think it is very likely that code that does nothing 10 million times will execute significantly faster than code that calls a no-op 10 million times - and that your suggestion is most likely quite correct.

Cheers,
Rob