8000 Quaddtype gives core dump on linux · Issue #105 · numpy/numpy-user-dtypes · GitHub
[go: up one dir, main page]
Skip to content

Quaddtype gives core dump on linux #105

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
mhvk opened this issue Feb 27, 2025 · 4 comments
Closed

Quaddtype gives core dump on linux #105

mhvk opened this issue Feb 27, 2025 · 4 comments

Comments

@mhvk
Copy link
Contributor
mhvk commented Feb 27, 2025

When trying to follow the basic instructions on the README, I get a core dump the moment I try to do any calculation:

from numpy_quaddtype import QuadPrecDType
import numpy as np
a = np.array([1,2,3], dtype=QuadPrecDType())
a
array([QuadPrecision('1.0e+000', backend='sleef'),
       QuadPrecision('2.0e+000', backend='sleef'),
       QuadPrecision('3.0e+000', backend='sleef')],
      dtype=QuadPrecDType(backend='sleef')
b = a+a
Illegal instruction (core dumped)

Things do seem to work with the longdouble backend.

I tried to install the source code (i.e., also compile sleef on my machine), but that gives the same error.

In case it helps, my numpy runtime:

import numpy; numpy.show_runtime()
[{'numpy_version': '2.1.0',
  'python': '3.11.2 (main, Nov 30 2024, 21:22:50) [GCC 12.2.0]',
  'uname': uname_result(system='Linux', node='swan.astro.utoronto.ca', release='6.1.0-30-amd64', version='#1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12)', machine='x86_64')},
 {'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
                      'found': ['SSSE3', 'SSE41', 'POPCNT', 'SSE42', 'AVX'],
                      'not_found': ['F16C',
                                    'FMA3',
                                    'AVX2',
                                    'AVX512F',
                                    'AVX512CD',
                                    'AVX512_KNL',
                                    'AVX512_KNM',
                                    'AVX512_SKX',
                                    'AVX512_CLX',
                                    'AVX512_CNL',
                                    'AVX512_ICL']}},
 {'architecture': 'Sandybridge',
  'filepath': '/data/mhvk/packages/numpy-user-dtypes/quaddtype/temp/lib/python3.11/site-packages/numpy.libs/libscipy_openblas64_-ff651d7f.so',
  'internal_api': 'openblas',
  'num_threads': 4,
  'prefix': 'libscipy_openblas',
  'threading_layer': 'pthreads',
  'user_api': 'blas',
  'version': '0.3.27'}]
@mhvk mhvk mentioned this issue Feb 27, 2025
Open
@SwayamInSync
Copy link
Contributor

Thank you for reporting this issue! I can see why you're encountering a core dump when using the SLEEF backend on your Sandybridge architecture.

My instinct says it is happening because SLEEF's quad precision implementation is likely compiled with AVX2 or AVX512 instructions, but your Sandybridge CPU only supports up to AVX (not the newer AVX2+ instruction sets). When the code tries to execute those unsupported instructions, you get the "Illegal instruction" error and core dump.

Looking at the SLEEF README, I see this is a known limitation with their SIMD implementation. SLEEF is designed to use various vector extensions (SSE2, SSE4, AVX, AVX2, AVX512F) on x86_64, but it appears the runtime CPU detection might not be properly preventing execution of incompatible code paths on your Sandybridge CPU.

If you want to use the SLEEF backend, you'll might need to recompile SLEEF with flags to disable higher SIMD instructions:

cmake -S . -B build -DSLEEF_BUILD_QUAD=ON \
  -DSLEEF_BUILD_SHARED_LIBS=ON \
  -DCMAKE_POSITION_INDEPENDENT_CODE=ON \
  -DSLEEF_DISABLE_AVX2=ON \
  -DSLEEF_DISABLE_AVX512=ON

Thanks for bringing this to my attention - I hadn't tested on older x86_64 architectures like Sandybridge.

@mhvk
Copy link
Contributor Author
mhvk commented Mar 2, 2025

Ah, interesting. I actually tried on my much newer laptop too, but the package could not be found. I now looked closer and it is simply that on that laptop I have python 3.13, so there are no wheels available for it. When I compile from source, things work.

@SwayamInSync
Copy link
Contributor

Ah, interesting. I actually tried on my much newer laptop too, but the package could not be found. I now looked closer and it is simply that on that laptop I have python 3.13, so there are no wheels available for it. When I compile from source, things work.

Awesome, do give it a try and would love your feedback
Also feel free to close this issue :)

@mhvk
Copy link
Contributor Author
mhvk commented Mar 2, 2025

OK, best to close indeed since this is a known upstream issue

@mhvk mhvk closed this as completed Mar 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mhvk @SwayamInSync
0