# Blog post: Loop fusion and vectorization in Julia 0.6

**URL:** <https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634>\
**Category:** Internals & Design\
**Tags:** announcement, broadcast\
**Created:** [January 22, 2017, 3:23am UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634 "2017-01-22T03:23:48Z")\
**Posts on this page:** 9\
**Page:** 2

<div class="post-metadata">

**Author:** ![Stephen\_Vavasis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stephen_vavasis/32/3389_2.png) [@Stephen\_Vavasis](https://discourse.julialang.org/u/Stephen_Vavasis)\
**Post date:** [January 26, 2017, 5:54pm UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/21 "2017-01-26T17:54:36Z")

</div>

Steven, I certainly agree that it is much better to allocate many small temporary objects on the heap rather than many large temporary objects. The new broadcast operations go a long way to eliminate heap temporaries. The lazy-operation/smart-getindex trick apparently can further boost the new syntax so that it is possible to replace large allocations for temporaries with small ones in some use cases. But it would be even better to eliminate heap allocations for temporaries. Performance is one reason. Another reason to eliminate heap allocations, even small ones, is that a user trying to find the cause of a large memory allocation would have an easier job if there aren’t many small allocations acting as distractions.

Since the core developers are already apparently putting some effort into finding cases when it is safe to allocate temporaries on the stack instead of the heap, I am suggesting that this is one case (a small temporary whose purpose is to support a smart getindex operation inside a broadcast) that deserves attention.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 26, 2017, 6:51pm UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/22 "2017-01-26T18:51:27Z")

</div>

> [@Stephen\_Vavasis](#):
>
> Since the core developers are already apparently putting some effort into finding cases when it is safe to allocate temporaries on the stack instead of the heap, I am suggesting that this is one case (a small temporary whose purpose is to support a smart getindex operation inside a broadcast) that deserves attention.

We want to have a generic solution for allocating small temporary objects on the stack ([https://github.com/JuliaLang/julia/pull/12205](https://github.com/JuliaLang/julia/pull/12205)). On the one hand, that means that the eventual solution should fix your particular problem. On the other hand, I don’t think we’ll want to implement any special-case solution _just_ for this particular problem in the short term.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 30, 2017, 6:38am UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/23 "2017-01-30T06:38:21Z")

</div>

> [@StefanKarpinski](#):
>
> Let’s see how it plays out, but I’ve seen a lot of examples (but they’re just examples!) where literally everything gets dotted. In cases where some things get dotted and others don’t I’m perfectly happy with spelling it out. Of course, there could be some syntax in @. for undotted calls, but that certainly seems like getting ahead of ourselves.

I’ve just pushed a PR to implement `@.` ([https://github.com/JuliaLang/julia/pull/20321](https://github.com/JuliaLang/julia/pull/20321)). Undotted calls are supported via `$` splicing syntax.

---

<div class="post-metadata">

**Author:** ![jgreener64](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jgreener64/32/2483_2.png) [@jgreener64](https://discourse.julialang.org/u/jgreener64)\
**Post date:** [February 2, 2017, 1:29pm UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/24 "2017-02-02T13:29:50Z")

</div>

Nice!

The section “broadcast vs. map” is useful. But I’m wondering if there are any easy rules for performance of `broadcast` vs. `map`? e.g. if your array/function is of a particular complexity then use one or the other to get the fastest-running code.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 2, 2017, 1:38pm UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/25 "2017-02-02T13:38:45Z")

</div>

> [@jgreener64](#):
>
> easy rules for performance of broadcast vs. map?

In the cases where they do the same thing, e.g. `abs.(x)` vs `map(abs, x)`, the performance should be essentially the same.

---

<div class="post-metadata">

**Author:** ![bobportmann](https://avatars.discourse-cdn.com/v4/letter/b/a88e57/32.png) [@bobportmann](https://discourse.julialang.org/u/bobportmann)\
**Post date:** [April 11, 2017, 2:57pm UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/26 "2017-04-11T14:57:14Z")

</div>

Nice blog post and I agree this is killer feature. In the “Broadcast vs. Map” section and it says, “map requires all arguments to have the same length” but I noticed in the 0.6-beta REPL

```julia
julia> map(+, (1,2), 3)
1-element Array{Int64,1}:
 4

julia> length((1,2))
2

julia> length(3)
1

```

which violates this rule. Is this expected or a bug?

Thanks,  
Bob

PS In case it matters:

```julia

julia> versioninfo()
Julia Version 0.6.0-pre.beta.0
Commit bd84fa1bad (2017-03-31 12:58 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, haswell)

```

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [April 11, 2017, 3:29pm UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/27 "2017-04-11T15:29:30Z")

</div>

> [@bobportmann](#):
>
> Is this expected or a bug?

This stems from the fallback method:

```julia
map(f, iters...) = collect(Generator(f, iters...))

```

and the `Generator` type allows iterators to have unequal lengths. I think this was designed to allow infinite iterators to be combined with finite ones, but the silent truncation seems undesirable to me when all the iterators have lengths.

Closely related to the discussion at [Do not truncate zip inputs · Issue #20499 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/20499)

---

<div class="post-metadata">

**Author:** ![benninkrs](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/benninkrs/32/3191_2.png) [@benninkrs](https://discourse.julialang.org/u/benninkrs)\
**Post date:** [May 4, 2017, 2:18am UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/28 "2017-05-04T02:18:56Z")

</div>

@stevengj Just came across your blog post. It is very clear and enlightening. Thank you!

---

<div class="post-metadata">

**Author:** ![purplishrock](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/purplishrock/32/13451_2.png) [@purplishrock](https://discourse.julialang.org/u/purplishrock)\
**Post date:** [May 4, 2017, 5:39am UTC](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634/29 "2017-05-04T05:39:52Z")

</div>

Just saw this today. Many people on the list probably saw it too…

> **[Exploiting Vector Instructions with Generalized Stream Fusion](https://cacm.acm.org/magazines/2017/5/216312-exploiting-vector-instructions-with-generalized-stream-fusion/abstract)**
>
> Programmers should not have to sacrifice code clarity or good software engineering practices to obtain performance. This work shows how to attain this goal for high-level Haskell in the domain of sequence-processing functions.

[Previous page](https://discourse.julialang.org/t/blog-post-loop-fusion-and-vectorization-in-julia-0-6/1634.md?page=1)