I'd rather shoot for always fast, always good debug info :-). We're not very far off, we just need to keep upstreaming improvements to LLVM.
On Sun, Nov 23, 2014 at 8:16 AM, Tamas Papp <[email protected]> wrote: > > On Sun, Nov 23 2014, Stefan Karpinski <[email protected]> wrote: > > > On Sun, Nov 23, 2014 at 6:02 AM, Christian Peel <[email protected]> > wrote: > > > >> Milan, > >> > >> Thanks for the comments. I also am confident that info about what line > >> errors occur on will improve. > >> > > > > For some context, the reason traditional dynamic systems like e.g. Matlab > > or Python, don't have this issue is that they use interpreters and > > literally walk through a fairly faithful representation of the code you > > wrote, including line number annotations. Thus, when an error occurs, > it's > > a trivial matter to report the line number you are currently > interpreting – > > the parsed code representation is the exact thing you're operating on > when > > the error occurs. Moreover, to give a full stack trace, you simply need > to > > walk back through the stack data structure that the interpreter maintains > > as it executes the program. > > > > In a JIT system like Julia, things are quite different. By the time your > > code is running, it no longer closely resembles the code you wrote and > > there is no interpreter and the "stack" is the actual stack. All of this > is > > what gives you C-like performance. When an error occurs, the error > message > > and stack trace have to be determined from the machine code that is > > currently executing and the stack trace is derived from *the* stack, not > > some data structure. All this is further complicated by the fact that > > LLVM's JIT does not tend to produce debug data quite as well as the > static > > compilation infrastructure does. People don't seem to use debuggers on > > JITed code or particularly care about backtraces, so we're pushing the > > envelope here, but things are getting better quite steadily. > > I am wondering if the approach used by Common Lisp implementations could > be applicable in Julia. In Common Lisp, one can have various > optimization and debug level settings, eg > > (optimize (speed 3) (safety 0) (debug 0)) > > will produce very fast code (comparable to C on modern implementations > if type info is available), with the trade-off that one has very little > debug information, while > > (optimize (debug 3)) > > does the opposite. Of course, the function needs to be recompiled for > these to take effect, but given that you can always modify the image in > a backtrace (AFAIK you can do the same in Julia), it works fine in > practice. > > Best, > > Tamas >
