Open rrnewton opened 9 years ago
"we could go the other direction": took me a moment to figure out what you meant here (this is the contract slide)
for/sum
do?Liked the motivation and introductory examples
CEK machine slide rides the bottom of the slide closely -- it looks like a bit was cut off on our projector and you may have the same problem on other projectors.
All of these slides, I think, with single words in the middle, should go away.
The CEK machine code is... lengthy. I don't think the full reduction semantics adds a ton.
my 2 cents: I personally don't mind the one word slides... reminds of Matt Might's (and Lawrence Lessig's) minimal style.
Also, Steve Jobs.
Yeah, Jobs was my thought.
E: Spenser should just get a turtleneck?
Some of the larger words seemed to cast a shadow behind them. If it's an artifact of the projector, then c'est la vie. If it's an on-purpose thing, then less shadow would be less distracting.
Would me nice if there was some early capsule slide summarizing what interesting new things Pycket does, as opposed to existing JIT systems for other things. Obviously you need to setup some background but I'm still waiting!
In the optimized dot code do we need to see all the other args to jump
and label
? Did you say what they are?
I'd swap these bleeding reds for another color; at least something a little more subdued? Might have a bad projector at ICFP :/
@jasonhemann -- yeah that's a projector thing -- look on the TV screen instead.
(Interpreter-JIT Code-C Code) So, the diagram is confusing: the down arrows seem to be compile, but the leftright are "mode switching"?
maybe call f
and g
something sensible, like loop
and myadd
Could you change the f
/g
to, say, the vector example from earlier? Something more concrete?
It's a shame there's not a meaningful example that's no more complicated.
It's hard to say what the "essential difficulty" of the example is, compared to Python
"This method is easy to defeat" sounds like you're trying to prevent malicious behavior, not optimize normal code. Which you go back on with the contract thing, so maybe a better way to say this?
I guess the essential difficulty is that we are not writing loops of imperative code, our loops are recursive calls of functions. (OK, finally got to this in "The Callgraph" slide)
I thought there was supposed to be something about supporting more features than python -- call/cc and contracts. But I don't think that was emphasized yet.
@ezyang yes
Would be good if this was made clear earlier :)
+1
I wonder whether the whole two-state part is necessary in the talk. I think just describing the callgraph approach is enough, because it's intuitive and satisfying.
Mentioning it in passing might be worthwhile, but yes, it seems the talk would stand fine without it (especially if it's a strategy typical to other rpython programs)
no, it's not a common technique in rpython (most languages there are imperative and it's completely obvious where the loops are), but it's not a new technique in the tracing space.
"Data structure Specialization" slide - at 16:30 minutes atm
[Bolz 2013] want to list all authors right?
In the FloatVectorStrategy picture I wonder whether the 2 should be 2.0, to make it clear that you can't really have ints in there. The paper may have the same problem, but too late for that.
For all the static-language fans that will be in the audience -- which of these goodies do they not achieve for free in a static language? Some of the contract checking? Bounds checking? A concrete example of this would be nice...
More numbers or something on the axis of the benchmark might be nice? A faint grid maybe?
@rrnewton actually your talk reminded me a lot of the strategies approach: switch between different representations of a data structure depending on how the data structure is used.
Shootout Benchmarks slide: the changing y-axis scale is confusing.
"Shootout Becnhmarks" -- it doesn't say how many benchmarks this is taking the geomean over. Is this the same set that was on the previous slide? I wasn't paying good enough attention.
@ezyang agreed, very confusing
I think that was the 20-minute mark, we just got to contracts / chaperones
Yeah changing the axes units for time comparison seems odd / confusing.
I would nix "For reference".. it's great that it's 2X faster for all benchmarks though ;-).
I missed why in "Benchmark: Contracts" there's a gap in the graph
What's the gap in the middle about? For a second I thought it was a benchmark they both go really fast at.
Thank you after the takeaways, not before.
"Virtually eliminate": but in the previous graph you did have a slow down when it was unspecialized?
Total time: 23:10
Oops, on the Y axis front... on "Benchmarks: Contracts" I lost track of what "slowdown" was -- percent or times?
I like how you explained what the two graphs were showing on the shootouts benchmark. I wasn't sure what you meant by "despecialization" at first, but then it was clear.
End with "Thank you," not thank you and then a summary. Thank you serves as a clear signal to the audience to applaud.
From Andre: how much of racket is implemented?
Spenser: covering FFI would be hard. Covered X/Y functions.
from @rrnewton: why is this harder than PyPy? Python has lambda etc.
samth's restatement of the Q (what does Pycket have which is novel); I would also ask, if you use a lot of lambdas in Python, would it slow down?
Practice talk -- 23:10 total time.