chiselfuse has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Remote host closed the connection]
chiselfuse has joined #ocaml
toastal has joined #ocaml
szkl has joined #ocaml
YuGiOhJCJ has joined #ocaml
mange has joined #ocaml
pi3ce has quit [Ping timeout: 252 seconds]
pi3ce has joined #ocaml
toastal has quit [Ping timeout: 276 seconds]
toastal has joined #ocaml
toastal has left #ocaml [#ocaml]
Frostillicus has joined #ocaml
toastal has joined #ocaml
Frostillicus has quit [Ping timeout: 276 seconds]
Frostillicus has joined #ocaml
Frostillicus has quit [Ping timeout: 252 seconds]
Haudegen has quit [Quit: Bin weg.]
toastal has quit [Ping timeout: 248 seconds]
mange has quit [Quit: Zzz...]
toastal has joined #ocaml
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Frostillicus has joined #ocaml
euphores has quit [Quit: Leaving.]
euphores has joined #ocaml
johnel_ has quit [Ping timeout: 276 seconds]
johnel has joined #ocaml
Frostillicus has quit [Read error: Connection reset by peer]
Frostillicus has joined #ocaml
Frostillicus has quit [Read error: Connection reset by peer]
<discocaml>
<jalsol> is there any good resource I can read on micro-optimizing performance specifically for OCaml?
<discocaml>
<jalsol> looking around the internet, most of the stuff I found are: tail call optimization, unboxed type, polymorphic -> monomorphic argument type, list -> seq
<discocaml>
<jalsol> or straight up adding stubs to C implementations
<discocaml>
<Kali> list -> seq is rarely a "micro-optimization"
<discocaml>
<contificate> omit the -
<discocaml>
<contificate> there's various things to know about the write barrier, old style CPS vs using OCaml 5 cactus stack directly, thread timeslicing, etc. I'm on phone so I can't rattle of more little points
<discocaml>
<octachron> polymorphic to monomorphic argument will not change the performance by itself.
<discocaml>
<contificate> I guess compiler can omit caml_modify call if it knows it's an int
<discocaml>
<deepspacejohn> afaik seq is usually just more efficient than list when it's being used as an intermediary structure between two other data structures, especially if the list also needs additional transformations like `map`. however if you really need performance than using a `fold` function on the original structure is usually the optimal choice.
<discocaml>
<octachron> Avoiding useless allocations, improving data locality (aka not forgetting that arrays exist).
<discocaml>
<octachron> And yes avoiding lists as temporary data structures.
<discocaml>
<jalsol> the "polymorphic types" section seems to suggest there's actually a performance improvement
<discocaml>
<octachron> This is misleading. The issue is not polymorphic types but the polymorphic comparison function.
<discocaml>
<jalsol> I kind of specified that the changes may happen in the function arguments
<discocaml>
<octachron> The example that you linked is only valid for `Stdlib.compare` and for no other functions.
<discocaml>
<octachron> Generally, monomorphising functions can improve performance only if it triggers other optimisations.
<discocaml>
<octachron> If you are not targeting specific optimisations, monomorphising a function will probably do nothing.
<discocaml>
<jalsol> wait you are suggesting it should only be valid for comparison?
<discocaml>
<jalsol> should there be any similar cases where the idea from the example applies?
<discocaml>
<octachron> No the comparison case is pretty specific: compiler primitives (like `Stdlib.compare`, or access to arrays) can be specialized using statistically known type information, but this doesn't apply to ordinary functions.
<discocaml>
<deepspacejohn> those functions use special runtime magic to be polymorphic in ways that pure OCaml functions can't, at the expense of performance.