[MLton-user] Why is recursion slower than C?
Wesley W. Terpstra
wesley at terpstra.ca
Wed Apr 25 09:40:22 PDT 2007
On Apr 25, 2007, at 5:44 PM, Neal Glew wrote:
> Intel hardware (probably AMD as well) has a return address stack as
> part of the branch prediction logic. This stack stores the most
> recent n (for some n) addresses pushed by call instructions. At a ret
> instruction the top of this stack is used to predict where the return
> will return to (and the stack is popped). Not using these
> instructions means not using this part of the branch prediction logic
> and generally results in very poor branch prediction for returns, and
> thus much stalling. I suspect that this accounts for most of the
> performance difference you are experiencing.
Yeah. It sounds like we're all in agreement about why C is faster
here. It's a shame because one would really like SML to be fast at
recursion. As long as
>> Also, it seems MLton is using %ebp for the stack pointer, instead
>> of %esp. Why is this? I gather this is why call/return are out
> In a MLton compiled program, there are effectively two stacks: the
> system C stack and the ML stack (allocated in the ML heap, which in
> turn is allocated in the system C heap).
this remains true, it seems unlikely that MLton will ever be able to
compete with C on recursion with two non-tail branches.
More information about the MLton-user
mailing list