[LLVMdev] Should LLVM JIT default to lazy or non-lazy?

[Evan Cheng]

On Oct 28, 2009, at 12:41 PM, Chandler Carruth wrote:

> On Wed, Oct 28, 2009 at 12:21 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>> On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote:
>>> From where I sit, this boils down to a very simple question (modulo
>>> Chris's point): Either choice will surprise some users. Which surprise
>>> is worse? Personally, I'd always prefer correct but slow behavior by
>>> default, and explicitly enabling dangerous (but in some cases fast)
>>> behavior.
>> 
>> The behavior is only dangerous because people are using it in new and different ways.
> 
> The fact that an interface, when used in new ways, exposes bugs this
> severe and subtle indicates that it is a poor interface. Your argument
> doesn't lend much weight, because the same can be said of computed
> goto, the fork() system call, etc. Surviving new and different uses
> *is* the purpose of a good interface.

And your point is? We are talking about changing the default. That fixes the interface?

I'd like to see some concrete proposal rather than flipping default behaviors. That does actually fix the problem. That just hides the problem. There won't be a consensus since we are lots of users with different needs. LLVM community has always let people who are doing to work make design decisions. Let's stick with that policy. Whoever is signed on to tackle the thread safety issue can decide what to do.

Evan

> 
>>> I would also point out that it seems that most of the people new to
>>> the JIT are surprised by the current behavior, where as those who
>>> would be surprised by needing to enable lazy JIT are those long
>>> familiar with past behavior. In the OSS world, I always favor easing
>>> adoption over maintaining the status quo.
>> 
>> This argues for better documentation. I'd prefer for EE to abort if user is asking for a known dangerous configuration (multi-threaded and lazy).
> 
> I do not think you can guarantee that the abort occurs if multiple
> threads are present. I would also much rather a speed limit sign than
> a dashboard full of speeding tickets to teach me how to drive. (Even
> if in that case I opt for both.... ;])
> 
>> The biggest argument I have for staying with lazy is llvm JIT is not a light weight JIT. It's designed to do all the codegen optimizations a normal static compiler would do. Non-lazy JIT is too slow.
> 
> The JIT doesn't get faster by being lazy, its slowness is just
> amortized over the runtime. As several have pointed out, that's not
> always desirable, and in some cases is outright terrible. We always
> take the same amount of time to actually JIT the code.
> 
> At best, the lazy JIT simply sees less code, but for most dynamic
> languages, the only code ever given to the JIT is what is already
> known to be needed.
> 
>> I'd prefer not to change the behavior. If we want to start using it in new and interesting ways, we should just design a new JIT.
> 
> We clearly do want use it in new and interesting ways, there is no
> 'if'. I'm not sure what you mean by 'design a new JIT'...
> 
> -Chandler