# How I learned to stop worrying about being fastest and love microbenchmarks

**URL:** <https://discourse.julialang.org/t/how-i-learned-to-stop-worrying-about-being-fastest-and-love-microbenchmarks/105268>\
**Category:** Community\
**Created:** [October 21, 2023, 2:29pm UTC](https://discourse.julialang.org/t/how-i-learned-to-stop-worrying-about-being-fastest-and-love-microbenchmarks/105268 "2023-10-21T14:29:27Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![user664303](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/user664303/32/37843_2.png) [@user664303](https://discourse.julialang.org/u/user664303)\
**Post date:** [October 27, 2023, 10:45am UTC](https://discourse.julialang.org/t/how-i-learned-to-stop-worrying-about-being-fastest-and-love-microbenchmarks/105268/21 "2023-10-27T10:45:57Z")

</div>

> [@kevbonham](#):
>
> I think quite the opposite - the **developers** of the ecosystem need to be experts, not the users.

If you believe that the developers of the ecosystem are users of Julia then we agree. I only meant some users - the developers of the algorithms.

> [@kevbonham](#):
>
> experts in the _algorithms_ don’t need to be experts in the _language_

It depends on what their goal is. If it’s to publish a proof of concept algorithm, I agree. But if it’s to produce something that other users want to use, then it would need to have some benefits over the alternatives. Performance is a common one. And I’ve used Julia enough to have reached the conclusion that you do need to be well versed in the language to write performant code.

---

<div class="post-metadata">

**Author:** ![jakobnissen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakobnissen/32/13477_2.png) [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)\
**Post date:** [November 3, 2023, 7:55am UTC](https://discourse.julialang.org/t/how-i-learned-to-stop-worrying-about-being-fastest-and-love-microbenchmarks/105268/22 "2023-11-03T07:55:07Z")

</div>

Having looked more into it, I’m pretty sure it’s not possible to express the x86 intrinsic `vpshufb` using LLVM. There are two important aspects to `vpshufb` which is not preserved in LLVM’s `shufflevector`:

- The mask vector for `shufflevector` must be a constant, whereas in my algorithm I need it to be a runtime value (in my algorithm, the mask is the input value and the “arguments” are compile time constants)
- In `vpshufb`, if the top bit of a byte in the mask is set, the resulting output element will be zero. This is not the semantics of `shufflevector`, but that property is needed for a subset of the functionality in ScanByte.jl.

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [November 3, 2023, 10:05am UTC](https://discourse.julialang.org/t/how-i-learned-to-stop-worrying-about-being-fastest-and-love-microbenchmarks/105268/23 "2023-11-03T10:05:10Z")

</div>

That’s a pity ☹

It seems I was too optimistic on that, sorry.

Unfortunate that llvm doesn’t offer the language to describe your algorithm in a way that could also compile on e.g. arm.

[Previous page](https://discourse.julialang.org/t/how-i-learned-to-stop-worrying-about-being-fastest-and-love-microbenchmarks/105268.md?page=1)