-
Notifications
You must be signed in to change notification settings - Fork 35
use our own struct for the local method table instead of TypeMapEntry #313
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -53,6 +53,12 @@ function breakpointchar(bps::BreakpointState) | |
return bps.condition === falsecondition ? ' ' : 'd' # no breakpoint : disabled | ||
end | ||
|
||
mutable struct DispatchableMethod | ||
next::Union{Nothing,DispatchableMethod} # linked-list representation | ||
frameinstance::Any # really a FrameInstance but we have a cyclic dependency | ||
sig::Type # for speed of matching, this is a *concrete* signature. `sig <: frameinstance.framecode.scope.sig` | ||
end | ||
|
||
""" | ||
`FrameCode` holds static information about a method or toplevel code. | ||
One `FrameCode` can be shared by many calling `Frame`s. | ||
|
@@ -68,7 +74,7 @@ Important fields: | |
struct FrameCode | ||
scope::Union{Method,Module} | ||
src::CodeInfo | ||
methodtables::Vector{Union{Compiled,TypeMapEntry}} # line-by-line method tables for generic-function :call Exprs | ||
methodtables::Vector{Union{Compiled,DispatchableMethod}} # line-by-line method tables for generic-function :call Exprs | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see how this prevents There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It prevents it because There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The reason I still want to have |
||
breakpoints::Vector{BreakpointState} | ||
used::BitSet | ||
generator::Bool # true if this is for the expression-generator of a @generated function | ||
|
@@ -80,7 +86,7 @@ function FrameCode(scope, src::CodeInfo; generator=false, optimize=true) | |
src, methodtables = optimize!(copy_codeinfo(src), scope) | ||
else | ||
src = replace_coretypes!(copy_codeinfo(src)) | ||
methodtables = Vector{Union{Compiled,TypeMapEntry}}(undef, length(src.code)) | ||
methodtables = Vector{Union{Compiled,DispatchableMethod}}(undef, length(src.code)) | ||
end | ||
breakpoints = Vector{BreakpointState}(undef, length(src.code)) | ||
for (i, pc_expr) in enumerate(src.code) | ||
|
@@ -331,7 +337,7 @@ struct BreakpointSignature <: AbstractBreakpoint | |
enabled::Ref{Bool} | ||
instances::Vector{BreakpointRef} | ||
end | ||
same_location(bp2::BreakpointSignature, bp::BreakpointSignature) = | ||
same_location(bp2::BreakpointSignature, bp::BreakpointSignature) = | ||
bp2.f == bp.f && bp2.sig == bp.sig && bp2.line == bp.line | ||
function Base.show(io::IO, bp::BreakpointSignature) | ||
print(io, bp.f) | ||
|
@@ -369,7 +375,7 @@ struct BreakpointFileLocation <: AbstractBreakpoint | |
enabled::Ref{Bool} | ||
instances::Vector{BreakpointRef} | ||
end | ||
same_location(bp2::BreakpointFileLocation, bp::BreakpointFileLocation) = | ||
same_location(bp2::BreakpointFileLocation, bp::BreakpointFileLocation) = | ||
bp2.path == bp.path && bp2.abspath == bp.abspath && bp2.line == bp.line | ||
function Base.show(io::IO, bp::BreakpointFileLocation) | ||
print(io, bp.path, ':', bp.line) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're doing this, can you implement the
compiled
idea too? With this diffand the following test code
I think you'll see what I'm worried about. (Note that the
Int
method ofbar
is recursively interpreted and theFloat64
one inCompiled
mode.) If you inspectframe.framecode.methodtables
you'll see thatCompiled
methods can't exploit the local method tables.In the longer run we want to store the
MethodInstance
, and then use accall
to skip thejl_lookup_generic
fromjl_apply_generic
. That would basically mean DLLEXPORTing this. That will eliminate the runtime dispatch on compiled dispatch from the interpreter.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correction: there's already this, so we don't have to modify Julia at all.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added caching for Compiled calls as well.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not quite sure I get what
foo
is, but if you're testingjl_invoke
against run-time dispatch keep in mind that the timings are rather dependent on how many methods there are.convert
might be in a different category 😄.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, had a typo,
foo
should have beenjl_invoke
. Just wanted to show that usingjl_invoke
with a MethodInstance was indeed faster :)