Closed thautwarm closed 3 years ago
from jit.ll.unbox import to_bit
@c.aware
def f():
c = to_bit(120, 64)
# c is now storing a 64 bit integer constant
c = to_bit(2.0, 64)
# c is now storing a 64 bit float constant
This optimization is feasible and many might be positive to this. However, dynjit is currently a research project developed by the individual, so that, no choice but "defer".
So far, no. Efforts limited. Use numba for numeric computing. We can support calling numba functions in DIO-JIT compiled functions, and we can contact numba team to do the same.
dynjit now robustly brings a >=2.5x speed up, while keeping CPython semantics and doing no unboxing.
The reasons against unboxing:
Unboxing requires introducing new builtin types to describe
int
,double
,char
,string
, etc.There're many one-door decisions to make:
int8
,int16
, ...,int128
or just an unboxedint64
type? The same tofloat
andchar
(unicode, ASCII).to_bit(i: int, n:const[int]) -> int[n]
, could be introduced to make users get literals forint64
,int32
?Unboxing requires extra implementation for those builtin types, specifically, new "shapes" should be introduced for digit-length parameteric types, such as unboxed integer and float types.
Specializers for them are required, on the other hands, new intrinsics should be setup. An example to support for
int +(int, int)
isFrom this we see it's a cumbersome task.
The reasons for boxing: