Minutes_2020_12_08

Public Numba Meeting: 2020-12-08

Attendees: Stu, Siu, Jim, Ryan, Michael, Todd, Luk, Val, Guilherme

0. Feature Discussion

• Siu: opening remarks about https://numba.discourse.group/t/extending-numba-with-a-convertible-to-type/338 and how Numba is quite heavily attached to NumPy with a huge amount depending on the "NumPy Types". Lot of changes required for reusable array impl, let's discuss... Todd opened a PR and has some slides to present (on support for NumPy subclasses).
• Todd: PR 6148, initial support for NumPy classes
  • Defer to slides. Q & A will be captured here.
  • Val: Does this mean I could swap in JEMalloc and use that instead of a system allocator?
  • Todd: yep, anything that matches the standard interface.
  • Val: Default allocator gets value NULL, could this get something different to keep nullptr out of the code.
  • Todd: If its present then it points to a valid structure, could have an enum for "is an external allocator in use" which could work instead of nullptr to indicate not.
  • Val: performance impact of a pointer chase for an alloc?
  • Todd: small bit of memory pressure for this, branch pred. as null maybe? __builtin_expect could help.
  • Siu: lets focus more on the higher level concepts, details can go into code review.
  • Siu: one thing with __array_ufunc__ protocol, this doesn't feel like what it should be doing, it seems like Numba typing logic is happening in the logic, and this function should return a ufunc.
  • Todd: the __array_ufunc__ in the subclass itself does the NumPy expected thing, but the one on the type does it in the type domain.
  • Todd: Jim, what happens if/when you mix AwkwardArray with something else?
  • Jim: hopeful that this would solve a problem where AwkwardArray's inside the JIT context can get typed as NumPy arrays, so as to take advantage of existing implementations. AwkwardArrays unfortunately cannot be a NumPy subclass.
  • Jim: there's an abstract type in Numba "ArrayCompatible" which might be workable, AwkwardArrays could inherit from this and then provide a method to convert from AwkwardArrays to NumPy arrays where applicable. Where in the scope of ArrayCompatible is the way to register lowering for this?
  • Luk: Q. for Todd. Been subclassing RecordArray and wanted to attach specific overloads to them. From the presentation, it seems like the subclass type "doesn't like" certain things, e.g. allocator, ufuncs. Is the problem inverse easier? i.e. Nothing shared and opt-in, opposed to inherit all and opt-out.
  • Todd: assumption was that the amount of stuff that is wanted for reuse is far greater than the amount wanted to change.
  • Luk: What's the memory model like? Is it reusable?
  • Todd: yes, its exactly the same in our case. If everything is being reused this makes sense but if doing something different this may not be the case.
  • Luk: is there a way to make it easier to share all these things?
  • Siu: it would be great if there was a system where you can pick "array features" from "the shelf" and build up from there. This is the thing I think of following from the discussion on discourse, it's a huge amount of work to restructure to achieve that. What Todd has in the PR is the closest/quickest way to get a custom allocator and a way to explain the types to return. In Jim's AwkwardArray case there's certain selective methods which are unique to AwkwardArray but want to borrow some parts. This is more complicated and needs more involved restructuring to achieve this.
  • Jim: both these have use at different times, case of subclasses, its an array/buffer, other case its not and can't be coerced as one, so both abilities are needed, "subclassing" and "array compatible". This PR handles the former but not the latter.
  • Siu: if the "convertible" isn't sufficient to solve the problem, is there anything that could help?
  • Jim: @lower_cast could be the thing that helps with this.
  • Siu: this involves writing a __array__ for the type which permit asarray to work with/on it.
  • Stuart: np.asarray needs to be called at the start in many NumPy functions.
  • Stuart: one reason that isn't done historically is that it has performance impact---generic vs specialization.
  • Jim: implicit converters can be written for example, but this can be a mixed blessing, e.g. in Scala as you don't know necessarily how your code is being compiled. ArrayCompatible might be ok for this as a compromise choice.
  • Stuart: how much of this is made more challenging because of historic reason? If Numba has implemented the protocols, would it have made it easier.
  • Siu: Should have done some of these already, but e.g NumPy array protocols might be too hard, more tailored protocols could perhaps work more easily.
  • Todd: sense is we'd like to make it easy to add new types etc, but everything is spread all over the place, and it's all quite case specific. It could may be easier but figuring it out is the challenge.
  • Siu: Going back to something higher level, Jim and Todd both want to extend NumPy's implementation, does anyone else have concerns, e.g. wanting to extend integers, are there other similar use cases.
  • Luk: issue with @overloads, cannot make them sufficiently granular, has to be done on the type abstraction. Cannot just add @overloads, wanted certain recarrays to have certain overloads. Wanted to just "add" more but had to change type to make it dispatch to it. Was adding methods to an array, for domain specific stuff, only makes sense if the record is of a certain type, e.g. Array(SpecificRecordType)->method(), a bit like subclassing, can't do @overload_method on a subtype.
  • Siu: This goes beyond what the record dtype does, it's building a DSL :)
  • Luk: doing it on the recordarray class. NamedTuple suffer from the same issue. It has to be defined all at once.
  • Siu: for, e.g. namedtuple this is basically wanting to create a new type.
  • Siu: Focussing purely on arrays, we probably need define a load of protocols/interfaces that are not even in NumPy to actually do all the things we want. e.g. Clifford might replace all the math, but could do with a ufunc mech on top. Then there's other things where we want to change allocators. Perhaps not focus on NumPy and work out what feature sets there are and look at how they abstract and combine. Reminds me of applied category theory.
  • Stuart: Would be good to define this sort of structure in a general python way and then try and reuse our existing mechanisms for extension to do the work, e.g. abstract the allocator and then replace it.
  • Luk: Perhaps take a look at a Julia?
  • Jim: lacks classes... quick discussion... turns out it has types
  • Siu: Numba tries to borrow some of these ideas, the issues are a) its not obvious to a user what to overload to change the implementation b) a lot of legacy code doesn't use this and so its much harder to deal with. Perhaps implementing protocols that users can customize via @overload helps, but the issue will be where to draw the line? Fine grained vs. just wanting to swap the allocator. Need feedback from contributors/community.
  • Luk: one of the characteristics from the Julia type system is that there can only be one concrete class and everything is abstract (only the leaves of the type tree can be concrete). Functions can then be defined to operate at any node in the tree. Array is e.g. abstract so you can operate specifically on that.
  • Siu: You can do this in Numba too.
  • Luk: But this can be done on type class not type instance.
  • Siu: You can do this.
  • Luk: it's @overload_method that's restricted like this.
  • Stuart: there's a way to do this, its just not plumbed in yet.
  • Siu: Let's wrap up and continue on discourse, thanks for the input, last meeting of the year, see you all next year!

1. New Issues

• #6555 - Cannot create datetime inside njit
  • feq; not hard
• #6554 - NotImplementedError: bounds checking is not supported for CUDA
• #6553 - PR 6343 issues
• #6551 - Cannot unify array(float64, 1d, C) and Literalint
• #6550 - Array comprehension fails against multidimensional array with nopython and typed List
• #6549 - CUDA: Allow dynamic allocation of local arrays
• #6548 - Support literal_unroll without type unification on loop body variables
  • map_tuple is the best way
• #6547 - Performance regression on 0.52.0 wrt bitshifts
• #6546 - np.linalg.eigval wrong results when using np.float32
• #6543 - Operation "element in set" never returns
  • problematic !!! needs looking !!!
  • Val is intrigued
• #6542 - libSVML.so load causing segfaults on some linuxes
• #6541 - Dead branch (optional argument test) not being pruned before type inference
• #6540 - Typed List preinitialization not working
• #6537 - Launch CUDA kernels from cfuncs
• #6536 - Inspect_cfg doc needs updating
• #6535 - Unable to assign 0 as NULL to void** local
• #6534 - bytecode analysis failure with BUILD_TUPLE_UNPACK.
• #6533 - Support prefer_literal option for intrinsic decorator
• #6532 - CUDA functions do not support tuple expansion

Closed Issues

• #6539 - ImportError: cannot import name 'jitclass' from 'numba' (/databricks/python/lib/python3.7/site-packages/numba/init.py)

• #6538 - Pypi wheels fail to install on Windows

  • perhaps a script to verify all the wheels have arrived

2. New PRs

• #6552 - Added numba support for np.heaviside
• #6545 - Refactoring ParforDiagnostics

Closed PRs

• #6544 - Minor typo / grammar fixes to 5 minute guide
• #6531 - Update canonical URL.
• #6530 - Update llvmlite dependency
• #6529 - Preparing 0.52.0 final
• #6528 - Update changelog for 0.52.0 final
• #6527 - setup.py: fix py version guard

3. Next Release: Version 0.53.0, RC=Q1 2021

• Relase branch: mid-Jan

4. Upcoming tasks

• 0.53.0 https://hackmd.io/oKJblGCQRv-CcgMYR4k6Ag