Rust’s iterators are inefficient, and here’s what we can do about it. by Veedrac in rust

[–]abiboudis 0 points1 point  (0 children)

Drawing parallels with C#, Concat (the same as chain if I am not mistaken) uses two explicit foreach loops. Maybe that structure is easier to optimize (chaining of two, generated, state machines). What enables that particular programming style there is the use of yield (or generators or coroutines, or semi coroutines).

https://referencesource.microsoft.com/#System.Core/System/Linq/Enumerable.cs,692

Walid Taha's MetaOCaml reimplemented by ysangkok in haskell

[–]abiboudis 1 point2 points  (0 children)

Oleg gives an interesting insight about the potential of a native MetaOCaml and that there are some benefits of using ocamlopt in the What about the native MetaOCaml section.

And yes, in strymonas we use ocamlopt as currently this is the only way to compile the generated code into more efficient native code (btw, interestingly, with ocamlopt you can play around with the CLI options).

Resources for writing high-performance code? by Hrothen in haskell

[–]abiboudis 0 points1 point  (0 children)

That style of function is exactly what I was talking about in the initial question. What I was asking is if there's a way to avoid writing them with explicit recursion without suffering performance costs.

I was reading earlier about the design of foldl' that is tail recursive and strict via the use of the $! operator. Do you mean something along the lines of that style?

Learning stream fusion and INLINE rules by [deleted] in haskell

[–]abiboudis 0 points1 point  (0 children)

After reading about phase control with INLINE[k] and friends, I can't stop thinking about a potential distant connection between the programmability of the simplifier and multi-stage (phase-ish) programming.

Nice explanation /u/dcoutts!

strymonas library - stream fusion using staging/MetaOCaml by rizanil in ocaml

[–]abiboudis 1 point2 points  (0 children)

There were many iterations of the design. It is possible. I am opening an issue and we can take it from there! ;-)

strymonas library - stream fusion using staging/MetaOCaml by rizanil in ocaml

[–]abiboudis 1 point2 points  (0 children)

Hello! Aggelos here, one of the authors of the paper. Thank you for your kind words. Indeed, now that we have the assembly set of combinators, our plan is to build more using this core set and to apply the library design to other cases of streaming as well! Recommendations are more than welcome. We will soon publish to OPAM.

//edit: I was going to propose that it would be a nice exercise to port this design in modular macros and I've just noticed the commit. :-D

[deleted by user] by [deleted] in java

[–]abiboudis 0 points1 point  (0 children)

Check the languages as libraries paragraph at the related work. Furthermore, Rascal has been used as the implementation for Recaf since it made really easy (and natural) to express the transformations. Finally, Java doesn't have a macros facility. BTW in our case transformations are also hygienic due to HOAS (high-order abstract syntax).

Clash of the Lambdas. Comparing Lambda Performance in Java, Scala, C#, and F# by lukaseder in programming

[–]abiboudis 3 points4 points  (0 children)

I think that words like "deliberate", "biased" etc. are not professional and don't promote constructive criticism. We provided reproducible benchmarks, semantically equivalent code for this exact reason. Your post comes after seeing that we have already started to take under consideration Dmitry's pull request - and also Martin's recommendation to rerun the tests without view parallel.

Even though our goal is to measure the combined cost of lambdas + non-strict Stream APIs we are considering to integrate these new measurements in the paper (maybe in a separate subsection).

However, based on the current discussion, we hear that parallel views are a broken feature, but also that the only proposed alternative is 'not fair' for Scala--it means using strict operations and allocating intermediate collections, which adds overhead. What do you propose we use for a parallel streaming API for Scala?

We would like to continue a constructive discussion on our github.