0.12.1 - biñs

[serge-sans-paille]

@rgommers / @jeanlaroche / @hroncok / @drew-parsons

This is a candidate release for pythran, could you give it a try?

[jeanlaroche]

Oh wow!!! Awesome! I"ll get on it! Thanks Serge

J

On 1/7/2023 10:48 AM, serge-sans-paille wrote:

@rgommers https://github.com/rgommers / @jeanlaroche https://github.com/jeanlaroche / @hroncok https://github.com/hroncok / @drew-parsons https://github.com/drew-parsons

This is a candidate release for pythran, could you give it a try?

— Reply to this email directly, view it on GitHub https://github.com/serge-sans-paille/pythran/pull/2065#issuecomment-1374572126, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGUBEPPRKHUM6LOKEHGJLG3WRG27FANCNFSM6AAAAAATRZFSJA. You are receiving this because you were mentioned.Message ID: @.***>

[rgommers]

This works as advertised with xsimd 10.0.0 on Linux locally. And the SciPy Windows CI job seems happy too (no xsimd there): https://github.com/rgommers/scipy/pull/142.

Pip 23.1 may not be all that far off (not sure, we're at 22.3.1 now), so you may want to tackle this deprecation warning sometime soon:

DEPRECATION: pythran is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559

[jeanlaroche]

So far all good for me for the main projects (all 6 of them)

Trying my secondary projects now.

On 1/7/23 10:48 AM, serge-sans-paille wrote:

@rgommers https://github.com/rgommers / @jeanlaroche https://github.com/jeanlaroche / @hroncok https://github.com/hroncok / @drew-parsons https://github.com/drew-parsons

This is a candidate release for pythran, could you give it a try?

— Reply to this email directly, view it on GitHub https://github.com/serge-sans-paille/pythran/pull/2065#issuecomment-1374572126, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGUBEPPRKHUM6LOKEHGJLG3WRG27FANCNFSM6AAAAAATRZFSJA. You are receiving this because you were mentioned.Message ID: @.***>

[drew-parsons]

Inconsistent results on debian unstable. The package builds fine and passes test_base.py. But after installing the deb package and running debian/tests (autopkgtest), the tests fail:

cc1plus: error: command-line option ‘-Wno-absolute-value’ is valid for C/ObjC but not for C++ [-Werror]

I'm not sure why the behaviour is different between build-time and run-time tests.

Incidentally, it occurs to me I don't actually know how to activate XSIMD in the context of running pytest. The documentation only indicates -DUSE_XSIMD at the pythran command line or in .pythranrc. But it's not really appropriate to managing packing for the generic case via a .pythranrc. How should -DUSE_XSIMD be invoked without .pythranrc when running python or pytest?

[jeanlaroche]

OK all good on my side.

On 1/7/2023 10:48 AM, serge-sans-paille wrote:

@rgommers https://github.com/rgommers / @jeanlaroche https://github.com/jeanlaroche / @hroncok https://github.com/hroncok / @drew-parsons https://github.com/drew-parsons

This is a candidate release for pythran, could you give it a try?

— Reply to this email directly, view it on GitHub https://github.com/serge-sans-paille/pythran/pull/2065#issuecomment-1374572126, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGUBEPPRKHUM6LOKEHGJLG3WRG27FANCNFSM6AAAAAATRZFSJA. You are receiving this because you were mentioned.Message ID: @.***>

[serge-sans-paille]

https://github.com/pypa/pip/issues/8559

Looks like just installing the wheel package is also an acceptable alternative. Tested locally and it works like a charm (in that case it uses the bdist_wheel) method.

[serge-sans-paille]

@drew-parsons:

can you try the extra following patch?

diff --git a/pythran/tests/__init__.py b/pythran/tests/__init__.py
index b9424a3b4..badc9859f 100644
--- a/pythran/tests/__init__.py
+++ b/pythran/tests/__init__.py
@@ -77,7 +77,6 @@ class TestEnv(unittest.TestCase):
                          '-Wno-int-in-bool-context',
                          '-Wno-unknown-warning-option',
                          '-Wno-unused-local-typedefs',
-                         '-Wno-absolute-value',
                          '-Wno-missing-braces',
                          '-Wno-unknown-pragmas',
                         ] if sys.platform != "win32" else []

[serge-sans-paille]

@drew-parsons: you can export CXXFLAGS=-DUSE_XSIMD to activate xsimd during specific runs, that should work.

[drew-parsons]

Ah, thanks for the patch. I see now we do already have it, but autopkgtest is inconsistent in applying it. Tests pass fine once I make sure it's applied.

Tests continue to pass too when I inject '-DUSE_XSIMD' into the set of flags in that patch, with both xsimd 8.1.0 and 10.0.0.

What's a good way of confirming that XSIMD was in fact used?

edit: pytest -s is one way to check it. Shows the compile flags, -DUSE_XSIMD among them.

[serge-sans-paille]

@drew-parsons : I've included the patch in the release then, less work for the packager is always a good thing.

I've just run the following:

CXXFLAGS=-DFOBAR py.test pythran/test_cases.py
# in another shell
psux | grep FOBAR

And it's indeed use.

edit: I wasn't aware of pytest -s, thanks!

[hroncok]

On it.

[hroncok]

Build for all arches: https://koji.fedoraproject.org/koji/taskinfo?taskID=95927590 Dependent packages on x86_64: https://copr.fedorainfracloud.org/coprs/churchyard/pythran-0.12.1/builds/

[hroncok]

A new build after the recent force-push: https://koji.fedoraproject.org/koji/taskinfo?taskID=95936261

The dependent packages were all built successfully.

[hroncok]

All :unicorn: and :rainbow:

[serge-sans-paille]

Thank you all. Without anymore remarks, I'll do the release this week end.

[drew-parsons]

pythran 0.12.1 is building successfully in debian experimental, build logs at https://buildd.debian.org/status/package.php?p=pythran&suite=experimental . The historical build logs can be found clicking on the "old" Logs links.

For the 0.12.1 builds, I activated XSIMD support for tests on supported architectures (amd64, arm64, i386), using CXXFLAGS=-DUSE_XSIMD as discussed above. amd64 seems to get a noticeable speed-up (comparing 0.11 to 0.12 build-time tests), while tests on arm64 seem to take twice as long in 0.12 with XSIMD activated. By contrast the 0.12 tests run twice as fast as 0.11 on armhf (without XSIMD). This observation doesn't control strictly for the specific arm64 build machine, though the trend is repeated across three 0.12 builds on 3 different machines. This is with XSIMD 8.1.0 though, I didn't mandate building with XSIMD 10.0.

I'll launch some CI tests to see if the poor arm64 XSIMD performance can be observed in run-time tests with XSIMD 10.0.