Expand documentation on Val{T}

[timholy]

An alternative to #15725.

[eschnett]

Thank you.

[KristofferC]

"knows" I think.

[vtjnash]

I think I would rather use this example as a demonstration of why you shouldn't make a type that depends on a value since it leads to further complication of the API later. But I agree there are a number of optimizations missing for NTuple that need to be addressed.

[timholy]

Meaning, Array{T,N} should become Array{T}? Refs:
JuliaLang/LinearAlgebra.jl#42
#11339

It's a hard road, though, because so much depends on knowing the dimensionality. Almost all of our indexing rules, for example. Which happen to be extraordinarily performance-sensitive.

[alyst]

Never understood what kind of "these ideas" are being referred to. I guess many people who just followed the _man-val-trick link have the same experience.
Also, I find it a little bit confusing that Val{T} is introduced as some sort of Julia type system quirk, whereas in fact it's just an empty immutable, and the same effect could be achieved with any user-defined type. Maybe it's worth clarifying.

[alyst]

Based on my experience of reading this section I would suggest a few things.

• Maybe the title could be changed from "Val{} trick" into something like "Converting run-time parameters into compile-time ones"
• The discussion of the example is nice, but since it's a mixture of do-s and don't-s, a summary of recommendations would be highly beneficial:
  • Why one might want to convert runtime parameter into compile-time (type stability, staged functions?)
  • When such conversion should be done (as early as possible in the call tree, absolutely not in the loop?)
• Is foo(Val{:bar}) really that slow? I thought, once compiled, it should be as fast as bar(). If it's really slow, maybe it's worth explaining why or providing the link to the relevant discussion of the dispatch mechanism.

[vtjnash]

Converting run-time parameters into compile-time ones

that's not really meaningful. there is a ordering of events such that runtime occurs after compile-time

foo(Val{:bar})

it's not particularly slow, but foobar() would be equivalent and more readable. b = :bar; foo(Val{b}) otoh, will be on the order of hundreds to thousands of times slower – so the performance cliff here is very bad and may be fairly unpredictable.

Why one might want to convert runtime parameter into compile-time (type stability, staged functions?)
When such conversion should be done (as early as possible in the call tree, absolutely not in the loop?)

design the api so it isn't necessary

[eschnett]

On Sat, Apr 2, 2016 at 12:28 PM, Jameson Nash [email protected]
wrote:

Converting run-time parameters into compile-time ones

that's not really meaningful. there is a ordering of events such that
runtime occurs after compile-time

The compiler's optimizer can optimize based on compile-time constants, but
not run-time constants. A function taking a Val argument can be orders of
magnitudes faster than with a run-time parameter.

foo(Val{:bar})

it's not particularly slow, but foobar() would be equivalent and more
readable. b = :bar; foo(Val{b}) otoh, will be on the order of hundreds to
thousands of times slower – so the performance cliff here is very bad and
may be fairly unpredictable.

Why one might want to convert runtime parameter into compile-time (type
stability, staged functions?)
When such conversion should be done (as early as possible in the call
tree, absolutely not in the loop?)

design the api so it isn't necessary

This isn't an API question; functionally, passing Val{x} and x are
equivalent. The point here is performance.

One of the reasons I'm using Julia (and not CUDA, C++, and Python) is that
I can control exactly how the code for my performance-critical loops looks.
What compilers produce by default is usually just not good enough. I'm
currently using Mathematica (another Lispy language) to generate C++ or
CUDA code, then maybe another optimizer for memory access patterns, and
then a regular compiler that is basically reduced to a register allocator
and instruction selector. I wish this all worked automatically with a
clever compiler, but it doesn't. And I understand the reasons why it
doesn't work, and why one can't expect that the next round of compiler
optimizations will cure this.

Originally I came to Julia for the macros, because they are much easier to
use than generating C++ code in Mathematica. Then I found out about
generated functions, which are even more convenient to use. Val is just
one other important ingredient. Tongue in cheek: I don't care if it takes
an hour to compile the function that takes a Val argument, and to create
the Val type object, and do the dynamic dispatch; that's still on par
with the development cycle for Mathematica, C++, and ahead-of-time
compiling.

-erik

Erik Schnetter [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

[alyst]

This isn't an API question; functionally, passing Val{x} and x are
equivalent. The point here is performance.

Actually, in many cases, after using Val{T}, I later realized that it would make perfect sense to embed T into an already existing type or convey the same information by subtyping. Using "normal" types somewhat reduces the chances that Julia dispatch would be abused.
So, I would say, if one is about to use "Val{T} trick", s/he has to double check whether a more conventional approach would be possible.

[timholy]

Thanks for the review comments, everyone. Very helpful. I'll merge unless additional concerns are raised.