On Thu, Jun 4, 2015 at 9:07 AM, Yichao Yu <[email protected]> wrote: > On Thu, Jun 4, 2015 at 8:57 AM, Stefan Karpinski <[email protected]> wrote: >> Are you asking about the task approach or the manual iteration approach? >> Manual iteration, yes (otherwise all iteration would be slow); tasks, I'm >> not sure how inlining would be possible. > > Sorry I was trying to come up with a short description of what I am > thinking of (but apparently failed). > > I was talking about a "wrapper" approach. i.e. wrap the iterator state > in a type and define a "indexless" iterator on the wrapper type. > > This is what I meant by "fast" and but relying on type stablity of the > original type. If the wrapper type is parametrized, it would probably > be as fast as manual iteration, but it will error out if the > underlaying iter methods is not type stable. If the wrapper type is > not parametrized, there will probably be a lot of boxing/unboxing and > runtime dispatch since typeinf cannot infer the type of the field > (which store the iteration index etc) > > So by "inlining the type" I mean sth like > > ``` > type A > a > end > > @inline get(a::A) = a.a > @inline set(a::A, b) = (a.a = b) > > function f1(c) > a = A() > set(a, c) > get(a) > end > > function f2(c) > a = c > a > end > ``` > > Can `f1` be made as fast as `f2` by realising `A` is not leaked > anywhere outside the function and can be treated as a bundle of local > variables?
I guess type inference has to be run twice for this to work. But before that, my question is, does type inference has enough info to figure that (that A is only used locally) out? > >> >> On Thu, Jun 4, 2015 at 8:52 AM, Yichao Yu <[email protected]> wrote: >>> >>> On Wed, Jun 3, 2015 at 3:16 PM, Stefan Karpinski >>> <[email protected]> wrote: >>> > You could use a task, but the performance would be much less good than >>> > explicitly manipulating the iteration state for many things. >>> > >>> >>> Manually iterating is not that bad so I think I would prefer a >>> solution that yield similar performance. >>> >>> Actually, can(/is it reasonable to make) type inference inline the >>> type as well if all use of it are inlined? >>> >>> > >>> >> On Jun 2, 2015, at 6:45 PM, Yichao Yu <[email protected]> wrote: >>> >> >>> >> I'm wondering what is the best way to do the equivalant with the >>> >> following in python. >>> >> >>> >> ``` >>> >> In [1]: a = range(20) >>> >> >>> >> In [2]: it = iter(a) >>> >> >>> >> In [3]: for i in it: >>> >> if i == 10: >>> >> break >>> >> ...: >>> >> >>> >> In [4]: for i in it: >>> >> ...: print(i) >>> >> ...: >>> >> 11 >>> >> 12 >>> >> 13 >>> >> 14 >>> >> 15 >>> >> 16 >>> >> 17 >>> >> 18 >>> >> 19 >>> >> ``` >>> >> >>> >> I know that I can call `start`, `next` and `done` manually but it >>> >> would be nice if I can avoid that. >>> >> >>> >> I could also wrap the returned value of next in a type but I don't >>> >> know how to make it both generic and fast, e.g. I want the typeinf to >>> >> infer the type as easy as if I call the `start`.... methods manually >>> >> and I don't want to rely on `next` being type stable (and AFAICT, the >>> >> `next` for Any array is not). >>> >> >>> >> >>> >> The exact format doesn't have to be the same with the python version >>> >> but I do want to use `for` loop instead of `while`. >> >>
