# Congrats for Julia 1.13!

**URL:** <https://discourse.julialang.org/t/congrats-for-julia-1-13/139343>\
**Category:** Community\
**Created:** [September 10, 2026, 4:19pm UTC](https://discourse.julialang.org/t/congrats-for-julia-1-13/139343 "2026-09-10T16:19:27Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [September 14, 2026, 5:17pm UTC](https://discourse.julialang.org/t/congrats-for-julia-1-13/139343/21 "2026-09-14T17:17:35Z")

</div>

More succinctly, it’s not cool to brigade into other communities whether they have detection algorithms or not. I know the intent wasn’t to brigade and artificially influence HN, but that can sometimes be the impact.

---

<div class="post-metadata">

**Author:** ![sob](https://avatars.discourse-cdn.com/v4/letter/s/65b543/32.png) [@sob](https://discourse.julialang.org/u/sob)\
**Post date:** [September 14, 2026, 6:02pm UTC](https://discourse.julialang.org/t/congrats-for-julia-1-13/139343/22 "2026-09-14T18:02:50Z")

</div>

Congrats on the release!

---

<div class="post-metadata">

**Author:** ![MDSW](https://avatars.discourse-cdn.com/v4/letter/m/94ad74/32.png) [@MDSW](https://discourse.julialang.org/u/MDSW)\
**Post date:** [September 14, 2026, 8:19pm UTC](https://discourse.julialang.org/t/congrats-for-julia-1-13/139343/23 "2026-09-14T20:19:17Z")

</div>

I removed the link as requested, but seriously, this wasn’t even close to [brigading by definition](https://feedguardians.com/glossary/brigading). Moreover, the 20 or so click-throughs this link would have gotten from this forum wouldn’t have come close to triggering any sort of protection.

> More succinctly, it’s not cool to brigade into other communities whether they have detection algorithms or not. I know the intent wasn’t to brigade and artificially influence HN, but that can sometimes be the impact

I know your intent wasn’t to be pejorative, but following up this way _after_ the overly precautious suggestion was nonetheless taken, kinda feels that way. If we care so much about not linking to a specific site, we should put that in the guidelines. The web was built on linking, so… sad comment on where we find ourselves.

---

<div class="post-metadata">

**Author:** ![ianshmean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ianshmean/32/216042_2.png) [@ianshmean](https://discourse.julialang.org/u/ianshmean)\
**Post date:** [September 15, 2026, 12:18am UTC](https://discourse.julialang.org/t/congrats-for-julia-1-13/139343/24 "2026-09-15T00:18:35Z")

</div>

@Palli I got claude to look into this and filed an issue

> <https://github.com/JuliaLang/julia/issues/63165>
>
> Investigating the slowdown reported https://discourse.julialang.org/t/congrats-f…or-julia-1-13/139343/19
> 
> Claude:
> 
> \---
> 
> The Benchmarks Game \`spectralnorm\` Julia #4 program runs about 25% slower on 1.13 than on 1.12, single-threaded and steady-state, so this is not compile cost. Reported on Discourse in https://discourse.julialang.org/t/congrats-for-julia-1-13/139343/19 (that report mixes in compile overhead and a warm nightly object cache; the numbers below isolate the runtime part).
> 
> Reduced kernel, no threading:
> 
> \`\`\`julia
> A(i, j) = (i + j - 2) \* (i + j - 1) / 2 + i
> function row!(f, v, out, i, n)
> x1 = x2 = 0.0
> @inbounds for j=1:2:n
> x1 += v\[j\] / f(Float64(i), Float64(j))
> x2 += v\[j+1\] / f(Float64(i), Float64(j+1))
> end
> @inbounds out\[i\] = x1 + x2
> end
> v = ones(5500); out = similar(v)
> @time for i in 1:5500; row!(A, v, out, i, 5500); end
> \`\`\`
> 
> Apple M5 Pro, \`-t1\`, min of 5:
> 
> | julia | LLVM | time |
> |---|---|---|
> | 1.11.9 | 16 | 9.9 ms |
> | 1.12.7 | 18 | 10.0 ms |
> | 1.13.0 | 20 | 13.3 ms |
> | 1.14.0-DEV.3171 | 22 | 12.2 ms |
> 
> The full program (\`main(5500)\`) goes from 385 ms on 1.12 to 487 ms on 1.13 at one thread, and 87 ms to 106 ms at five threads.
> 
> \`@code\_llvm\` shows why. On 1.12 the \`1:2:n\` loop stays scalar and SLP vectorizes the \`x1\`/\`x2\` pair into a single \`\<2 x double\>\` accumulator: one vector \`fdiv\` and one vector \`fadd\` per iteration. On 1.13 LoopVectorize takes the loop instead (VF=2, interleave 4). Since the accumulations are not reassociable it emits in-order \`llvm.vector.reduce.fadd\` chains for both accumulators, plus \`\<4 x double\>\` loads with strided shuffles to de-interleave \`v\[j\]\` and \`v\[j+1\]\`. The vector body is about three times as many instructions and the serial reduction chain is the same length as before, so nothing is gained.
> 
> I have not checked whether x86 makes the same choice; the Discourse report is from an x86 machine with \`--cpu-target=ivybridge\`, so the runtime part of that slowdown may or may not be this.
> 
> Unrelated but in the same report: \`Base.should\_use\_main\_entrypoint\` is recompiled in every script that defines \`main\`, because inference folds \`isdefined(Main, :main)\` against the binding partition at sysimage build time. \`invokelatest(isdefined, Main, :main)\` avoids that invalidation; I can open that separately.

[Previous page](https://discourse.julialang.org/t/congrats-for-julia-1-13/139343.md?page=1)