Skip to content
esc edited this page Dec 7, 2022 · 1 revision

Numba Meeting: 2022-12-06

Attendees: Val, Guilherme, Graham Markall, Stuart, Jim Pivarski, Andre Masella, Siu Kwan Lam, Todd Anderson, Matthew Murray, Brandon Willard FPOC (last week): Guilherme FPOC (incoming): Val

NOTE: All communication is subject to the Numba Code of Conduct.

Please refer to this calendar for the next meeting date.

0. Discussion

  • Closing shop in 2 weeks

    • Numba maintainers will be away from Dec 17 - Jan 6
    • No FPOC rota.
    • No public meetings in this period.
    • Siu: make discourse post RE no meetings. ✔️
    • Consider pinned issue on github. Slower response times etc. ✔️
  • Py3.11 update

    • Just 8 failing tests! (one is a duplicate, one is a llvmlite warning)
    • Having the feature branch has been useful, we should do this again.
  • LLVM 14 update

    • It theoretically works, need to work through some issues in vectorization. Maybe refop-pruner related.
  • NumPy 1.24 update (discuss removing older versions)

    • Up to RC2 now - tests still pass with Numba main from 2022-12-06
    • https://github.com/numba/numba/pull/8620
    • Based on NEP-029, 0.57 will have the baseline of 1.21.
    • Does anyone see a problem with not having support for 1.20, 1.19 and 1.18?
  • pycc deprecation

    • make into a PendingDeprecationWarning and reassure users that it won't be removed until a replacement is available.
    • will be happy to no longer support this
    • We do need to carry on supporting AOT (Ahead of Time compilation) in future
  • [Done in triage] Dynamic exception PR update (Guilherme)

    • Siu suggestion of storing a pointer to a function into the exception struct was excelent: Store runtime values + a function to convert those values into PyObjects* in excinfo_t.
    • Single failure in the test suite. Test failure happens at the LLVM side when it is parsing LLVM IR metadata.
    • Failure is not deterministic but when it happens, it is always in the same place: LLVM parsing IR metadata.
  • Stuart: Domains for the Type System

    • spliced the concept of a domain (negative) into the type system
    • this allows exclusion of entire branches, if we know that a number will never be negative
    • Will this need to be an inferred type, w/o exposing to the user level
    • The Numba IR loses information very quickly, types become less specific very quickly
    • Region based type inference may help: better performance, types are more specific, less combinations need to be investigated, i.e. a stable point
    • [jim] mentions a crazy project he once worked on
    • Here's a link to the middle of the type system implementation, Numbers with min and max: https://github.com/diana-hep/femtocode/blob/bfde538a99f35345eec8b5a0db670f29f83e1cc5/lang/femtocode/typesystem.py#L626
    • Jim was inspired by the concept of a Total Functional language, which isn't Turing complete and can prevent all runtime errors and infinite loops. There's not much written on Total Functional languages, mostly about how they'll handle recursion and the Ackermann function.
    • This is generally about how coarse-grained or fine-grained the type system is, and there are pros & cons on both ends of the spectrum. For instance, Numba has already made a decision about the granularity of array types: Numba arrays know ndim at compile-time, but not shape. JAX knows shape at compile-time. Some systems consider ndim to be runtime. (In a sense, NumPy is a runtime ndim system.) What we're talking about here is a level of granularity between knowing the exact shape at compile-time, like JAX, and just knowing some things about the shape, like whether a dimension is empty or not.
    • Static analysis "Value Range Analysis" that does something similar. It can infer a range for certain variables at compile-time. https://homepages.dcc.ufmg.br/~fernando/classes/dcc888/ementa/slides/RangeAnalysis.pdf
    • The least complex stuff you generate is the stuff that stands the most chance to be well optimized
    • Goal is not to make Numba more error prone ("error prone" means showing the user more errors rather than falling back on less-good output), but to transparently improve performance, if it compiles, you may get extra speed. I.e. no changes to the public contract / interface.
  • Siu: mentions JAX and tagless final form

    • Don't need a fancy type system
    • Information can feed back into the compiler as metadata
  • Stuart: suppose we manage to split up typing and lowering

    • This will mean you can run type inference without compiling anything
    • Who and what kind of users would care about this
    • Numba Developers will care, since this will allow compiling things in parallel, or in the background
    • [Brandon] for Aesara stuff, when we transpile this doesn't really matter, but it would be a nice feature. If we could settle on a slightly more general type system in the context of arrays, that woudl be nice.
    • The difficulty is that we have to spell this out and it will be all Numba based

New "Ready for Review" PRs

1. New Issues

  • #8629 - Reminder to revert changes to CI before merging py3.11 branch
  • #8631 - Gitdiff testing does not include cuda tests
    • need to check that CUDA Simulator tests are running somewhere
  • #8632 - Range Checking for Numpy Arrays
  • #8635 - CUDA: test_ptds is prone to hanging on Windows
  • #8637 - Feature Request: Supporting unboxing list(optional(concrete_type))
  • #8640 - setattr on an optional type doesn't redirect to the inner type
  • #8642 - _jump_if_none fix up in py3.11 branch
  • #8643 - py3.11 cleanup task: Make these register names match those that are generated for < 3.11.
  • llvmlite#894 - SVML fails to produce Haswell-friendly code with LLVM 14 patch

Closed Issues

  • #8627 - Process hangs with a specific sequence of add/removes on a set
  • #8628 - CUDA fail on main: type numpy.float32 doesn't define __trunc__ method
  • #8638 - CudaSupportError: Error at driver init: Call to cuInit results in CUDA_ERROR_UNKNOWN (999):
  • #8641 - typed.List lowering error when appending None followed by a concrete type
  • llvmlite#891 - Python 3.7 support removal

2. New PRs

  • #8626 - [unicode-PERF]: use optmized BM algorithm to replace the brute-force finder
  • #8633 - DOC: Convert vectorize and guvectorize examples to doctests
  • #8634 - Add new method is_fp16_supported
  • #8644 - Fix bare reraise support
  • #8645 - PR #8232 continued

Closed PRs

  • merged - #8630 - Fix #8628: Don't test math.trunc with non-float64 NumPy scalars
  • merged - #8636 - CUDA: Skip test_ptds on Windows
  • merged - #8639 - Python 3.11 - fix majority of remaining test failures.
  • merged - llvmlite#892 - Bump minimum supported Python version to 3.8
  • merged - llvmlite#893 - Upgrade to ubuntu-20.04 for azure pipeline CI

3. Next Release: Version 0.57.0/0.40.0, RC Jan 2023

Clone this wiki locally