Chris Rackauckas 9:52 AM
@yingbo_ma instead of @.. lowering to broadcast, should it actually be building a map! expression?
Yingbo Ma:pusheen_monocle: 9:52 AM
Yeah
We should give up on broadcast. 😛
Chris Rackauckas 9:53 AM
I wonder how much that could help in terms of compile times
well in a lot of cases we aren't actually broadcasting, we're mapping
well I guess the difficulty there is actually the muladd expressions 🤷
Yingbo Ma:pusheen_monocle: 9:53 AM
Not many people are actually using broadcast anyway.
The overhead of broadcast comes from handling [1.0] .+ [1, 2, 3]
Chris Rackauckas 9:54 AM
yeah
we can probably improve timings by just changing it to map!, right?
Yingbo Ma:pusheen_monocle: 9:55 AM
I think so, but we need our custom map!
map! is actually slow, too.
Chris Rackauckas 9:55 AM
and it would be safer, since the things that fail are the things things that fail on @..?
Yingbo Ma:pusheen_monocle: 9:56 AM
Unfortunately, our @.. is limited, make it as fall back wouldn't be any safer.
Oh, I remember the problem now.
Chris Rackauckas 9:56 AM
I mean, it shouldn't be a fallback
we should literally just make it a macro that builds special map! calls
since it can't actually broadcast IIRC
Yingbo Ma:pusheen_monocle: 9:57 AM
Base map! is slow, so we cannot use it, but no one would extend our custom map! .
Chris Rackauckas 9:58 AM
oh...
why would map! be slow?
Yingbo Ma:pusheen_monocle: 9:58 AM
Because how it handles multiple args.
Chris Rackauckas 9:59 AM
fastmap! that falls back to map!?
would that be slower than broadcast?
Yingbo Ma:pusheen_monocle: 9:59 AM
map!((a,b,c,d,e)->..., a, b, c, d, e) vs fastmap!((a,b,c,d,e)->..., (a,b,c,d,e))
Chris Rackauckas 10:00 AM
yeah
then fallback to map! and specialize on Array , Or would that give a performance regression
or fastmap! which falls back to the current @..?
then we can add a few overloads like for Array and StaticArray?
That would cut down on compile times and possibly fix inference issues on StaticArrays?
Yingbo Ma:pusheen_monocle: 10:02 AM
Yeah, I think so.
Chris Rackauckas 9:52 AM
@yingbo_ma instead of @.. lowering to broadcast, should it actually be building a map! expression?
Yingbo Ma:pusheen_monocle: 9:52 AM
Yeah
We should give up on broadcast. 😛
Chris Rackauckas 9:53 AM
I wonder how much that could help in terms of compile times
well in a lot of cases we aren't actually broadcasting, we're mapping
well I guess the difficulty there is actually the muladd expressions 🤷
Yingbo Ma:pusheen_monocle: 9:53 AM
Not many people are actually using broadcast anyway.
The overhead of broadcast comes from handling [1.0] .+ [1, 2, 3]
Chris Rackauckas 9:54 AM
yeah
we can probably improve timings by just changing it to map!, right?
Yingbo Ma:pusheen_monocle: 9:55 AM
I think so, but we need our custom map!
map! is actually slow, too.
Chris Rackauckas 9:55 AM
and it would be safer, since the things that fail are the things things that fail on @..?
Yingbo Ma:pusheen_monocle: 9:56 AM
Unfortunately, our @.. is limited, make it as fall back wouldn't be any safer.
Oh, I remember the problem now.
Chris Rackauckas 9:56 AM
I mean, it shouldn't be a fallback
we should literally just make it a macro that builds special map! calls
since it can't actually broadcast IIRC
Yingbo Ma:pusheen_monocle: 9:57 AM
Base map! is slow, so we cannot use it, but no one would extend our custom map! .
Chris Rackauckas 9:58 AM
oh...
why would map! be slow?
Yingbo Ma:pusheen_monocle: 9:58 AM
Because how it handles multiple args.
Chris Rackauckas 9:59 AM
fastmap! that falls back to map!?
would that be slower than broadcast?
Yingbo Ma:pusheen_monocle: 9:59 AM
map!((a,b,c,d,e)->..., a, b, c, d, e) vs fastmap!((a,b,c,d,e)->..., (a,b,c,d,e))
Chris Rackauckas 10:00 AM
yeah
then fallback to map! and specialize on Array , Or would that give a performance regression
or fastmap! which falls back to the current @..?
then we can add a few overloads like for Array and StaticArray?
That would cut down on compile times and possibly fix inference issues on StaticArrays?
Yingbo Ma:pusheen_monocle: 10:02 AM
Yeah, I think so.