1. 14 Mar, 2014 1 commit
  2. 17 Feb, 2014 1 commit
  3. 12 Feb, 2014 1 commit
  4. 11 Feb, 2014 2 commits
  5. 18 Jan, 2014 2 commits
  6. 16 Jan, 2014 1 commit
  7. 14 Jan, 2014 1 commit
  8. 10 Dec, 2013 1 commit
  9. 03 Dec, 2013 1 commit
  10. 19 Nov, 2013 1 commit
  11. 15 Nov, 2013 1 commit
  12. 11 Nov, 2013 1 commit
  13. 10 Nov, 2013 2 commits
  14. 08 Nov, 2013 1 commit
  15. 04 Nov, 2013 1 commit
    • Guillaume Melquiond's avatar
      Avoid pointless closures when hash-consing lists. · 5bb78bd4
      Guillaume Melquiond authored
      Best of three runs on a bench for Gappa transformations:
      - before: 34.98user 0.09system 0:35.13elapsed 99%CPU (0avgtext+0avgdata 241492maxresident)k
      - after:  29.68user 0.08system 0:29.80elapsed 99%CPU (0avgtext+0avgdata 241820maxresident)k
      Speed-up: +18%.
      5bb78bd4
  16. 03 Nov, 2013 1 commit
    • Andrei Paskevich's avatar
      allow printers to produce "urgent output" · c0e146fa
      Andrei Paskevich authored
      this is useful to declare on-the-fly a new sort which replaces
      a complex type. Otherwise, the printer has to traverse any term
      twice: first, to detect complex types, second, to print the term.
      c0e146fa
  17. 02 Nov, 2013 1 commit
    • Andrei Paskevich's avatar
      implement printers as memoizing transformations · 9640fb2b
      Andrei Paskevich authored
      also, avoid the "encoding_sort" transformation, if it can be done
      directly in the printer.
      
      On the same example as in the previous commits, this gives 5x
      acceleration together with some memory usage reduction.
      9640fb2b
  18. 01 Nov, 2013 4 commits
    • Andrei Paskevich's avatar
      Term: simplify t_label_copy · 96b8c672
      Andrei Paskevich authored
      96b8c672
    • Andrei Paskevich's avatar
      Term: remove redundant *_alpha operations · d93cc40f
      Andrei Paskevich authored
      feel free to revert, if you think we might want to make again the
      distinction between t_equal and t_equal_alpha in future or just
      don't feel like breaking the API.
      d93cc40f
    • Andrei Paskevich's avatar
      tidying up · 58ff0109
      Andrei Paskevich authored
      also, ensure that t_label_copy does not lose information
      58ff0109
    • Andrei Paskevich's avatar
      Trans: do not memoize transformations of goals · 3cdc073f
      Andrei Paskevich authored
      the goal declarations are not shared and thus memoizing transformations
      on them is only interesting if we apply the same transformation on the
      same goal (which may happen when we launch several provers of the same
      family on the same goal). On the other hand, goal declarations are big
      (think WP) and numerous (think goal_split), and keeping them in memory
      is a bad idea.
      
      The same example from BWare can now be treated with 1/4 of memory:
      
      why3-replayer : full memoization
      106.81user 7.86system 1:59.32elapsed 96%CPU (0avgtext+0avgdata 1656908maxresident)k
      
      why3-replayer : no memoization on goals (this commit)
      74.14user 4.24system 1:24.93elapsed 92%CPU (0avgtext+0avgdata 429376maxresident)k
      
      why3-replayer : no memoization at all
      217.78user 6.25system 3:43.56elapsed 100%CPU (0avgtext+0avgdata 615204maxresident)k
      
      One side effect of this commit is that polymorphism encoding
      transformations are likely to be memoized only for a short time.
      The transformations that select the type instances to discriminate
      and the types to preserve in encoding are full-task-dependent and
      therefore are not memoized anymore. Thus, as soon the the task that
      contains all the selection metas is GCed, the rest of the chain
      will go, too, and Why3 will have to re-monomorphize the same decls.
      We'll see if this is a problem in practice.
      3cdc073f
  19. 30 Oct, 2013 4 commits
  20. 29 Oct, 2013 1 commit
    • Andrei Paskevich's avatar
      Term: do not store t_vars in terms · 7abeba05
      Andrei Paskevich authored
      we still keep bv_vars in the binders, so calculating the set
      of free variables only has to descend to the topmost binders.
      The difference on an example from BWare is quite striking:
      
      /usr/bin/time why3-replayer : with t_vars
      
      505.14user 15.58system 8:40.45elapsed 100%CPU (0avgtext+0avgdata 3140336maxresident)k
      
      /usr/bin/time why3-replayer : without t_vars
      
      242.96user 12.04system 4:16.31elapsed 99%CPU (0avgtext+0avgdata 2007184maxresident)k
      
      Not only we take 2/3 of memory, but we also gain in speed (less work
      for the GC, most probably).
      
      This patch should be tested on big WhyML examples,
      since src/whyml/mlw_*.ml are big users of t_vars.
      
      Thanks to Guillaume for the suggestion.
      7abeba05
  21. 28 Oct, 2013 2 commits
  22. 27 Oct, 2013 1 commit
  23. 26 Oct, 2013 2 commits
    • Andrei Paskevich's avatar
      Dexpr: stage 2, in progress · 2bd3fdc4
      Andrei Paskevich authored
      2bd3fdc4
    • Andrei Paskevich's avatar
      Pattern: add compile_bare which does not require known_map · 43aeab83
      Andrei Paskevich authored
      In pattern compilation, we only need to know the full list of
      constructors for a given type, whenever
      1. we want to check that a symbol used in a pattern is indeed
         a constructor;
      2. we want to check for non-exhaustive matching and return an
         example of a non-covered pattern, if any.
      Thus, we need to give Pattern.compile access to the current
      known_map whenever we check new declarations in Decl or Mlw_decl.
      However, once we have checked the patterns, we do not need the
      full constructor lists just to compile the match expressions.
      Just knowing the number of constructors (provided in ls_constr)
      is enough to detect non-exhaustive matching during compilation.
      43aeab83
  24. 25 Oct, 2013 1 commit
  25. 24 Oct, 2013 1 commit
  26. 21 Oct, 2013 2 commits
  27. 19 Oct, 2013 2 commits