On Sat, May 7, 2016 at 8:46 AM, Cedric St-Jean <cedric.stj...@gmail.com> wrote:
>> mostly due to various technical reason
In arbitrary order, the ones I can think of now.
1. We collect backtrace
There are many cases where we don't actually need this info, but
we need better code analysis to be able to figure that out.
2. We don't have zero cost exception frame so we need to spill many registers.
It's hard for us to have zero cost exception frame unless all the
C libraries are compiled with unwind info. Also note that zero cost
exception frame means even more expensive exception throwing since the
registers are not explicitly saved and we need to unwind the call
stack to restore them. This is a trade off after all.
3. Preserving local variables across an exception requires spilling it
to stack and this adds some hidden cost.
It's a little hard to say how much cost this have, probably not
THAT much unless you have a lot of variables that is modified in try
and used after the exception is caught. Very likely strongly depending
on the code pattern.
4. The GC frame allocation is global (well, per-function) instead of
control flow local.
This cause allocation in not-taken branch to affect the
performance on the taken branch. This is not specific to exceptions
but is particularly bad for exceptions since throwing one sometimes
requires allocation that otherwise doesn't exist in the function (e.g.
`ArgumentError("My error message with $variable spliced in")`) and
these branches are meant to be not taken most of the time (if the
error can happen most of the time, you'd be better off with a error
code return, since exceptions are not designed for that).
>
> Could you please go into those? I'd like to understand why unwinding the
> stack is costlier than returning from a function.
>
> On Saturday, May 7, 2016 at 8:38:03 AM UTC-4, Yichao Yu wrote:
>>
>> On Sat, May 7, 2016 at 6:58 AM, Ben Ward <axolotl...@gmail.com> wrote:
>> > Hi,
>> >
>> > I have a question which may be laughable to CS people (be gentle, I'm a
>> > Biologist), but we know from guidelines that Julia performs best, when a
>> > method always returns the same type of value.
>> > So the Julia type inference knows - ok, use this method with an Int, it
>> > will
>> > always return a bool say. How does throws fit into this? To my mind this
>> > means the method used with an Int may return a bool, but it also may
>> > result
>> > in a type of (e.g.) ArgumentError getting thrown. So how do throws in
>> > functions affect performance and julian's ability to infer types and
>> > optimise code (if at all?)?
>>
>> While throwing or catching an error itself is slow (mostly due to
>> various technical reason) they shouldn't affect type stability.
>>
>> The type inference currently do not reason about what type of
>> exception can be thrown and even if it does, this won't affect what we
>> usually call the type stability of a function since it is only about
>> the **return type** of a function and throwing an error is not return
>> (in the sense that `a = cond ? error() : 1`, if the next statement is
>> executed, a is always a `Int`).
>>
>> >
>> > Thanks,
>> > Ben W.
