Stefan, Thank you for the explanation of the issues with line numbers and LLVM, and how it compares with Matlab and Julia.
In your recent papers and on http://julialang.org/benchmarks/ we can see that Julia is among the fastest languages to *run*. I'd be very interested to see the speed with which a language can detect a syntax error. In an informal test a minute ago using similar 500-line functions in both languages, Matlab was able to detect my syntax error in under a second. Julia took around 11 seconds. So Matlab has an edit-test cycle; it's very quick. Julia has what feels very much like an edit-compile-test cycle; the compile step is very visible. Matlab allows me to make thousands of edits per day and quickly develop high-level code; Julia development feels slower overall, even with faster runtime. Tamas made a suggestion above which I interpreted as asking for a flag that would allow one to have faster syntax error checking at the expense of slower runtime. I agree with you that it would be ideal to have 'always fast debug info'; if for some reason you can't get the syntax error checking down; I would support a flag such as Tamas suggests. Thanks for your work! Chris On Sunday, November 23, 2014 5:44:32 AM UTC-8, Stefan Karpinski wrote: > > 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] > <javascript:>> wrote: > >> >> On Sun, Nov 23 2014, Stefan Karpinski <[email protected] <javascript:>> >> wrote: >> >> > On Sun, Nov 23, 2014 at 6:02 AM, Christian Peel <[email protected] >> <javascript:>> 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 >> > >
