Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linking is slow when there are functions with large arities #5933

Closed
vicuna opened this issue Feb 25, 2013 · 6 comments
Closed

Linking is slow when there are functions with large arities #5933

vicuna opened this issue Feb 25, 2013 · 6 comments
Assignees

Comments

@vicuna
Copy link

@vicuna vicuna commented Feb 25, 2013

Original bug ID: 5933
Reporter: @sliquister
Assigned to: @gasche
Status: closed (set by @xavierleroy on 2015-12-11T18:24:02Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.00.1
Category: back end (clambda to assembly)
Related to: #4077
Child of: #5287
Monitored by: @lefessan @hcarty

Bug description

A file containing only a function of arity 67 takes roughly 9s to link (see attached file, which also contains what I used to test). Most of the time is spent compiling the caml_curryX_Y_app functions.

I provide a patch that replaces the uses of caml_curryX_Y_app by caml_curryX_Y when the arity is higher than 15, because the optimization doesn't seem to too useful past this point. I am not familiar with this part of the compiler but I think the behaviour should be the same as before the "_app" functions were introduced. The patch also specializes a couple of Pervasives.compare that showed up during profiling.

On the function of arity 67, linking time goes from 8.5s to 0.2s.
On a real example (linking jane street's core and core_extended), the time goes from 8.5s to 1s.

File attachments

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 25, 2013

Comment author: @jhjourdan

This issue appeared quite recently in the OCaml compiler (4.0 or so). It is interesting to avoid quadratic behavior with respect to arities in the case of Coq extracted code : it is not rare to have inductive types with dozens of constructors, and the induction predicates for those types have a big arity.

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 25, 2013

Comment author: @gasche

I see that the patch actually does two different thing:

  1. the _app business
  2. turning polymorphic compare into specialized int comparisons

The first change is subtle and needs careful review. The second seems easy to merge, provided there is evidence that it actually helps. Could you report changes in compilation times due only to the second change, on realistic programs?

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 25, 2013

Comment author: @sliquister

I don't remember measuring the second specialization by itself, but if I remember right, the first specialization made the linking of core and core_extended take 5s instead of 8.5s.
The impact of the specialization should be less noticeable if the rest of the patch is applied though.

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 25, 2013

Comment author: @xavierleroy

I guess this is a consequence of the change proposed first in #5287. I agree we must avoid code size quadratic in the arity of a curried function, at all costs.

@vicuna
Copy link
Author

@vicuna vicuna commented Mar 19, 2013

Comment author: @sliquister

Turns out the previous patch was not quite right.
I attached a better one which mirrors the patch that introduced the _app functions in the first place: in the few places where the initial
patch added 'if some condition then apply optimization else do normal stuff', it now becomes 'if same condition and arity is not too big then ... else ...'.
I checked that when the optimization is always deactivated (max_optimized_arity = 0), the compiler bootstraps (instead of segfaulting with my first patch).

@vicuna
Copy link
Author

@vicuna vicuna commented Mar 19, 2013

Comment author: @gasche

I reviewed this later patch and trust it is correct. I applied it in the SVN trunk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants