Minutes_2020_11_10
Valentin Haenel edited this page Dec 2, 2020
·
2 revisions
Attendees: Val, Graham, JimP, Luk, Ryan Chien, stuart, Todd, Siu, Juan, Guilherme
- 0.52 RC status
- Current is RC2, in public testing.
- RC3 needed:
- Fixes issue with refcount stealing in ndarray C code.
- In general, be aware that NRT_Decref is the only accepted way to decrease a ref count.
- Performance whack-a-mole to address performance regression introduced in RC2 causing RC1 benchmark to be invalid. Actual changes is deciding what LLVM optimization passes to use at the pre-optimization phase.
- 0.53 Plans
- Previously mentioned: https://github.com/numba/numba/wiki/Minutes_2020_10_20
- Stuart leading work on piping more information into dipatch (e.g.
@overload). For example, implementation can pick up onfastmath=True.- JimP feedbacks on error message to be futher grouped together.
- Rough API is intention, long term goal is to get this into user feedback.
- Updates on actions/items from previous public meetings:
- The "extra"s (name pending) repo for exploration/experimental ideas.
- Poll on the name, please do vote for your favourite name.
- Hope to get this started for 0.53.
- Ryan: were the community to contribute, what is of interest?
- Siu: There's some general rules, and a bit of a description here: https://numba.discourse.group/t/a-new-repo-for-extra-features/229
- Siu: features which don't touch the C extensions and are largely additive are most likely to be accepted. Things which change how types/type inference works is much harder to accomodate.
- Ryan: What's the admin structure/ownership going to look like?
- Siu: Need to work on this, but want to make it more open and make it easier to contribute. Perhaps looking for major community contributors to help manage the repo.
- Siu: Do you have something in mind?
- Ryan: Depends on org and if community finds it useful. SciPy stats things, cephes etc.
- Siu: there's a
numba-scipyrepo for this already - Ryan: it's mainly distributions that are in use.
- Type annotations:
- Thread coordinating efforts is https://numba.discourse.group/t/coordinating-type-annotations/219
- Siu: has found it useful, particularly with runtime checks enabled. https://github.com/numba/numba/pull/6458
- Siu: anticipate quite a bit of iteration to ensure that the type annotations are all correct.
- Siu: could help with large scale refactoring.
- The "extra"s (name pending) repo for exploration/experimental ideas.
- Floor open to discussion/questions:
- Siu: Luk has a proposal about function subtyping...
- Luk: Trying to express the semantics of first class functions (ideally) such that the behaviour is clear and consistent. Related doc: https://numba.discourse.group/t/semantics-of-first-class-functions/323
- The proposal and the forum thread
- Luk: Elevator pitch... first class functions at present have a signature at present, which means its possible to have a degree of flexibility. Important to differentiate between dispatchers (thing the @jit produces) and first class functions. If a function can be compiled into many signatures, it makes it hard to work out the type of the function, and this makes the properties of first class functions not work. First class functions at present are limited essentially as dispatchers that work for one precise signature. The proposal involves the use of intersection types, which describes the semantics of combining first class functions with signatures. This might be a long elevator :)
- Jim P: There's a whole theory on this, covariant and contravariant etc. One direction makes more sense for arguements, another is for the return values. This seems to be for the args, which seems like the specialisation over args can narrow.
- Luk: Didn't touch so much on accepting narrower types.
- Jim P: covers enumerated types.
- Luk: Hard because of unknowns.
- Siu: What should this accept, how does type inference works.
- Luk: might not be possible.
- Siu: OCaml would likely require it spelling.
- Luk: Type inference would be limited to already existing signatures. e.g. already compiled for 3 sigs, these are the ones that are considered. The unknown part is already part implemented by the "UndefinedFunction" Type. If there's a function that takes
(int, float, str)and another that takes(int, float), if there's a list of these then it could/should!? end up as a list[function(int, float)]. This is the required degree of subtyping. Problems also exist if there's multiple calls in the code to the same first class function (passed as an argument) but with different types. - Siu: What happens with the dispatcher?
- Luk: dispatcher type kept, essentially as an alias of a bunch of signatures. It's when there's a concrete first class requirement needed it needs to be concreted as a first class func type.
- Siu: Let's say you can have a list of two functions, one float->float, one int->int, what happens at run time for operating on the list?
- Luk: example used as a way to cut down dyanamism of types, the list has to become much more concrete and the DoF reduces. If the list is ctor'd with two functions as above, it becomes a list of
<intersection type>(int->int, float->float). In the case of containers, the return type of functions is available for the list constructions without requiring dispatch. - Jim P: What motivated this, it's a large problem, there's certain subsets which are immediately useful. e.g. funcs which accept another func as an argument but doesn't return a new function. Enables map, reduce etc.
- Luk: Much over specialisation based on dispatchers, so you get a lot of compilation perhaps for no gain. This is motivation for it at present. If a single sig is given to a function then it creates this behaviour, but also locks the function so no recompilation is possible. Want to retain ability to recompile but also use as first class function.
- Jim P: If a user has a problem where a function can accept a function but sig has to be exact. If the user wants a list of functions like float->float type narrowing makes sense. But for organisational purposes does just splitting it help? Write a wrapper as a lambda?
- Luk: One thing that might help is writing a load of example/sample code as it motivates discussion and enumerates what works/does not work.
- Stu: caching worked as a side effect.
- Luk: Working on inversion of control to get nearer polymorphic behaviours and with no classes functions help with this a load.
- Siu: Does any inspiration for this come from C++ multimethods etc?
- Luk: Mainly typescript, scala and the pearce book on types.
- Siu: Additional theoretical thing, ML style typing goes for most general type for polymorphic, Numba goes for most specialised for performance. Numba does cartesian product alg (with extra bits, original is CPA paper) to get the super specialisation. These are conflicting worlds!
- Luk: Specialisation drives performance, perhaps in limited cases, users can select the tradeoff.
<long discussion about maps>- Stu... thought... map reduce already implemented, but dispatchery
- Stu... thought... does region based typing sort this out?
- Long discussion about CPA vs ML and region based typing and various benefits/costs.
-
#6461 - argument X: Cannot type list element of <class 'dict'>
- user question regarding dictionary
- #6459 - ByteArray doesn't support boxing or slicing
-
#6456 - stencil kernel performance not scaling in njit(parallel=True)
- serial loop faster than parallel stencil
- Parfor problem... needs Todd's attention
- #6451 - Vectorization/inline in body of single function failing
-
#6449 -
asfarrayincorrectly handles the default kwarg- dtype handling error
- has PR
- #6448 - CUDA: Add accessors for function attributes beyond just register use per thread
-
#6444 - 0.52.0rc2 regression: invalid array data if used after print
- bad internal refcount semantic from before the new pruner
- #6443 - Pin llvmlite for RC3... Final of 0.52.0
- #6452 - Type inference with int size error
- #6460 - Added bytearray boxing [WIP]
- #6458 - Enable typeguard in CI
- #6457 - Link to read the docs instead of numba homepage
-
#6455 - Fix refprune on obfuscated refs and stabilize optimisation WRT wrappers.
- TODO: move llvmlite packages to main to allow CI to work here
- #6454 - FIX: Fixes for literals
-
#6453 - Keep original variable names in metadata to improve diagnostics
- suggestion notes: make it clear that it is a parfor specific metadata
- #6450 - Fix asfarray kwarg default handling.
- #6447 - CUDA: Add get_regs_per_thread method to Dispatcher
- #6446 - Fix #6444: pruner issues with reference stealing functions
- #6445 - option nogil=True not required for ufuncs and gufuncs