Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backport of changes in #17057 that don't require new worlds #18679

Merged
merged 9 commits into from
Oct 4, 2016

Conversation

vtjnash
Copy link
Sponsor Member

@vtjnash vtjnash commented Sep 26, 2016

Fixes some method definition orderings, and other @generated functions, that will be broken by PR #17057

end
end
for f in fs
for m in _methods_by_ftype(Tuple{typeof(f), Vararg{Any}}, 10)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this 10 be given a name?

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's just a random round-ish number

by < 0 && T <: Unsigned && return false
ry = rationalize(T,by,tol=0)
ry < by ? :(x <= $ry) : :(x < $ry)
@pure function rationalize{T<:Integer}(::Type{T}, x::Irrational)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this causes a method overwrite warning, why is it needed?

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for the same reason the other method overwrite warning happens in searchsorted

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any horizon for not needing that?

Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The one in this case might not be needed --- calling a kwarg function with no keyword arguments is fast. The problem in searchsorted was that computing the keyword arg default values required dynamic dispatch.

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, the problem in this case is actually just that lowering won't apply @pure to the kwargs functions, and that's quite fixable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add a TODO comment saying to fix pure for kwargs so the no-kwargs method can be deleted then?

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

original issue should be corrected by 3f2213f now

After that, for this example, the expression returned from the generated
function on the first invocation was re-used as the method body.
The actual caching behavior is an implementation-defined performance optimization,
so it is invalid to depend to closely on this behavior, however.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"too closely"

don't end a sentence with ", however." - just delete that


The example generated function ``foo`` above did not do anything a normal
function ``foo(x)=x*x`` could not do, except printing the type on the
first invocation (and incurring a higher compile-time cost). However, the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the rewording from "compile-time cost" to "overhead" ? is this not strictly a compile time difference?

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, it's adds overhead in many places

function ``foo(x) = x * x`` could not do (except printing the type on the
first invocation, and incurring higher overhead).
However, the power of a generated function lies in its ability to compute
different quoted expression depending on the types passed to it:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

different quoted expressions

It's easiest to illustrate this with an example. We can declare a generated
function ``foo`` as

.. doctest::

julia> @generated function foo(x)
println(x)
return :(x*x)
Core.println(x)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this is not pure. This is mentioned way later, but coming after the new point "4." this is just odd. Maybe state that doing println is ok?

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

println isn't OK, it's just a convenient function for showing how they work (and along the way demonstrating why it isn't OK)


3. Instead of calculating something or performing some action, you return
a *quoted expression* which, when evaluated, does what you want.

4. The function must not have any side-effects or examine any non-constant
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To go with the later "they"s, start with "4. Generated functions must not..."

ordinary functions:

1. You annotate the function declaration with the ``@generated`` macro.
This adds some information to the AST that lets the compiler know that
this is a generated function.

2. In the body of the generated function you only have access to the
*types* of the arguments, not their values.
*types* of the arguments -- not their values -- and any function that
was defined *before* the definition of generated function.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"was defined before the definition of the generated function."

@@ -1028,12 +1037,40 @@ copy them*, for the following reasons:
* the ``foo`` function has side-effects, and it is undefined exactly when,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As @mauro3 suggested in https://github.com/JuliaLang/julia/pull/18679/files#r80905058, perhaps also mention the issues immediately alongside the corresponding examples?

This condition is relaxed for incrementally-loaded precompiled modules to
allow calling any function in the module.

Alright, now that we have a better understanding for how generated functions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for -> of ("now that we have a better understanding of how generated functions work").

@@ -1034,7 +1034,7 @@ These examples are hopefully helpful to illustrate how generated functions
work, both in the definition end and at the call site; however, *don't
copy them*, for the following reasons:

* the ``foo`` function has side-effects, and it is undefined exactly when,
* the ``foo`` function has side-effects (the call to `Core.println`), and it is undefined exactly when,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rst, so double backticks

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Oct 3, 2016

rebased to squash (previous head was 8f4d569) and added 94be098 to fix a pre-existing bug, for backporting (not all of these commits need to be backported, but can review that later)

@jrevels
Copy link
Member

jrevels commented Oct 3, 2016

@nanosoldier runbenchmarks(ALL, vs=":master")

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Oct 3, 2016

nanosoldier says, "merge"?

@@ -829,7 +829,7 @@ static jl_method_instance_t *jl_mt_assoc_by_type(jl_methtable_t *mt, jl_datatype
sig = join_tsig(tt, entry->sig);
jl_method_instance_t *nf;
if (!cache) {
nf = jl_get_specialized(m, sig, env); // TODO: should be jl_specializations_get_linfo
nf = jl_specializations_get_linfo(m, sig, env);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just FYI, this change doesn't fix the ASAN issue I mentioned.

@vtjnash vtjnash merged commit fe29cb5 into master Oct 4, 2016
@vtjnash vtjnash deleted the jn/backports265.1 branch October 4, 2016 18:12
@KristofferC
Copy link
Sponsor Member

I'm excited for the new worlds to come.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants