Plans to update for Julia 1.0?

[OliverEvans96]

Since there's been no activity in this repo for quite some time, I was just wondering what the roadmap looks like for the project, and whether it has been superceded by another package.

Thanks!
Oliver

[vchuravy]

There has recently been a lot of development around https://github.com/JuliaDebug/Debugger.jl and https://github.com/JuliaDebug/JuliaInterpreter.jl

[ViralBShah]

We should archive this repo and mention clearly that the new repo is Debugger.jl.

[timholy]

Hopefully, some day there will be renewed development here. Despite rapid recent progress with JuliaInterpreter and the associated stack, there's still lots of reason to be interested in interfacing with native-code call stacks. Most importantly, JuliaInterpreter is going to be slow (currently ~1000x slower than native code in hot-loop array iteration tasks). While I think we can obtain further performance improvements, directly messing with CPU instructions is probably the only solution that can avoid any kind of performance hit.

That said, it's a big undertaking. For the forseeable future, JuliaInterpreter is clearly the way to go.

[StefanKarpinski]

I think the right approach is to gradually improve the compiler tech of Debugger.jl then rather than trying to revive Gallium.jl. We need to take an incremental approach, starting from something that works reliably and is useful and gradually improving the performance aspect while preserving the usability and reliability. Ultimately the problem with Gallium was that it tried to take on too much and while it was fast it was unreliable and crashed too much to be anyone's go to debugging solution. So I think the best approach is to keep this around and steal code from it over time as needed.

[timholy]

Exactly, that's why I started down that road---get something reasonable up and running, and then get it widely used. Preserve that usability as you incrementally move forward. Sometimes that makes it a bit harder to do really big rewrites, but in the mean time you've accumulated a serious test suite and you can feel much better about being sure those rewrites aren't breaking lots of stuff.

And there is a path towards improving the compiler tech in JuliaInterpreter (Debugger.jl is a pretty thin shell, the heavy lifting is in JuliaInterpreter). Two key steps:

• Compiled resumers JuliaInterpreter.jl#44 (won't help the debugger, but will help Julia tests don't pass JuliaInterpreter.jl#13 and is potentially some pretty cool technology in its own right, e.g., "run more code in the interpreter" compiler priority)
• Debugger is slow Debugger.jl#19 (comment) (i.e., automatically instrument methods to store the data needed by Debugger.jl, and then compile them)

I'll be shocked if the second of these doesn't buy us at least one order of magnitude, maybe two. It will still be well behind non-instrumented code, but only by one array-store per update to a local variable. I bet that will be at most a 10x hit for the majority of code.

[cossio]

Why is it a big deal that the interpreter is fast? At least for debugging performance doesn't seem like a big issue. You are stepping through the code anyway line by line.

[StefanKarpinski]

Breakpoints can be set in code that is only called deep in a lot of other code.

[timholy]

If you want to appreciate the importance,

• find a calculation that takes ~60seconds to complete
• set a breakpoint at the exit
• run it in the interpreter
• report back in a week 😄

[timholy]

BTW, my latest thoughts on performance are here: JuliaDebug/JuliaInterpreter.jl#204. You'll see there's a pretty clean solution, I think, but a technical problem needs to be addressed first. I suspect that strategy has a chance of quickly getting us to something that's reasonably close to normal performance for most workloads..