4 ms·

"We find that Typed Racket’s cost of soundness is not tolerable. If applying our method to other gradual type system implementations yields similar results, the

• taylorfausak 11y ago
  > the paper ignores the reason why people kicked and screamed for the functionality to begin with No it doesn't. The explicitly talk about this in section 7: "The acceptance of Typed Racket in the commercial and open-source Racket community suggests that (some) programmers find a way around the performance bottlenecks of sound gradual typing." > Reticulated Python is still an order of magnitude faster than Ruby Are you suggesting that a slower variant of Python is ten times faster than Ruby? That doesn't match my experience. For what it's worth, Ruby outperforms Python in some benchmarks: http://benchmarksgame.alioth.debian.org/u64q/ruby.html http://benchmarksgame.alioth.debian.org/u64q/ruby.html
  • Veedrac 11y ago
    Looking at the first benchmark in the list you gave, just in-lining eval_A in the Python code (as the Ruby code does) makes the Python code competitive with the Ruby. As usual, don't trust the Benchmarks Game; it's not nearly well enough controlled to be a useful data point. (I do agree with your main point, though. CPython ain't that fast.)
    • igouy 11y ago
      As usual, don't trust Joshua Landau: without in-lining eval-A the Ruby code only slows from 102secs to 137secs. As usual, Joshua -- Do the ordinary thing and report specific programs that you think should not be allowed.
      • Veedrac 11y ago
        For those not aware, igouy maintains the Benchmarks Game.
        • igouy 11y ago
          Nothing hidden about that -- http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#history http://benchmarksgame.alioth.debian.org/sometimes-people-jus... How to report specific programs that you think should not be allowed -- http://benchmarksgame.alioth.debian.org/play.html#invalid http://benchmarksgame.alioth.debian.org/play.html#invalid
• sitkack 11y ago
  Are you referring to this paper? http://wphomes.soic.indiana.edu/jsiek/files/2014/08/retic-python-v3.pdf http://wphomes.soic.indiana.edu/jsiek/files/2014/08/retic-py...
  • tacos 11y ago
    As referenced in the paper itself, section 6.1.
    • igouy 11y ago
      For those who have not looked at the referenced paper, the last section is -- "6. Conclusions" "…Reticulated programs perform far worse than their unchecked Python implementation…" p10 "Design and Evaluation of Gradual Typing for Python"
      • sitkack 11y ago
        And I would argue that _use-site checking_ is the easiest and obviously the slowest method to attain the stated goal. Python is already slow, this is just going to make things silly. Using the same inference methods as Shedskin [0] along with type annotations, functional tests and property based testing can get both correctness and performance in a gradual layered manner. This paper doesn't prove that gradual typing is broken, it shows that _use-site checking_ happens to be slow for the version of Python that they used (PyPy could very well elide the checks). [0] Shedskin Thesis http://mark.dufour.googlepages.com/shedskin.pdf http://mark.dufour.googlepages.com/shedskin.pdf Iterative Flow Analysis by Plevyak http://plevyak.com/ifa-submit.pdf http://plevyak.com/ifa-submit.pdf Agesen's Cartesian Product http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.663&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88....
        • igouy 11y ago
          My point was simply that there is no section 6.1 in that paper, and what is in the paper does not support `tacos` claim ;-)
• deleted 11y ago
  [deleted]