4 ms·

http://flint.cs.yale.edu/jvmsem/doc/threaded.ps http://flint.cs.yale.edu/jvmsem/doc/threaded.ps You should also try to play nice with the branch prediction mac

http://flint.cs.yale.edu/jvmsem/doc/threaded.ps http://flint.cs.yale.edu/jvmsem/doc/threaded.ps You should also try to play nice with the branch prediction machinery. Doing unbalanced rets isn't good. Doing all the jumps or calls from a single jump or call site isn't good, either. Spread them around so you only have one destination per call site. The method in the above paper is pretty much the ultimate you can easily do without rolling out the really heavy machinery.

agumonkey 12y ago
online viewer -> http://view.samurajdata.se/psview.php?id=abaee002&page=1&size=full&all=1 http://view.samurajdata.se/psview.php?id=abaee002&page=1&siz...
- peterfirefly 12y ago
  Right. I forget that some people use Windows and that Windows machines usually don't have PostScript viewers installed.
  - agumonkey 12y ago
    It's funny that it's such a nice, simple and old format, yet it's rarely supported natively. I wonder if browser pdf plugins can manage ps.
solarexplorer 12y ago
Thanks for the link, that was a great read! I agree that the branch (target) prediction will fail horribly on a naive interpreter that calls different branch targets from the same static instruction over and over again. That alone explains the low performance.
thyrsus 12y ago
Why are "unbalanced" rets not good? Also, am I wrong that, at least in most Unixish systems, interrupts use a separate stack register from that of user space code, and thus, with care, one can avoid corruption of the direct thread addresses?
- peterfirefly 12y ago
  Because modern CPUs have a small internal return stack for target predictions for return instructions. If your calls and returns are not balanced, you get mispredictions (or it gives up and stops predicting altogether). http://en.wikipedia.org/wiki/Branch_predictor#Prediction_of_function_returns http://en.wikipedia.org/wiki/Branch_predictor#Prediction_of_... http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363g/Cihdbcef.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... This type of branch predictor went mainstream in the late 90's with CPUs such as the AMD K6-2. It is not a correctness issue (as long as there's nothing else that thinks it can put stuff on the stack), just a performance issue. You should not expect that the code snippets you "return" to will leave the stack alone -- spill/fill and callee-save instructions etc will kill the part of the "stack" that has already been "returned" from which is fine as long as you don't want to reuse it. But I think you will.

agumonkey 12y ago

online viewer -> http://view.samurajdata.se/psview.php?id=abaee002&page=1&size=full&all=1 http://view.samurajdata.se/psview.php?id=abaee002&page=1&siz...

peterfirefly 12y ago
Right. I forget that some people use Windows and that Windows machines usually don't have PostScript viewers installed.
- agumonkey 12y ago
  It's funny that it's such a nice, simple and old format, yet it's rarely supported natively. I wonder if browser pdf plugins can manage ps.

solarexplorer 12y ago

Thanks for the link, that was a great read! I agree that the branch (target) prediction will fail horribly on a naive interpreter that calls different branch targets from the same static instruction over and over again. That alone explains the low performance.

thyrsus 12y ago

Why are "unbalanced" rets not good? Also, am I wrong that, at least in most Unixish systems, interrupts use a separate stack register from that of user space code, and thus, with care, one can avoid corruption of the direct thread addresses?

peterfirefly 12y ago
Because modern CPUs have a small internal return stack for target predictions for return instructions. If your calls and returns are not balanced, you get mispredictions (or it gives up and stops predicting altogether). http://en.wikipedia.org/wiki/Branch_predictor#Prediction_of_function_returns http://en.wikipedia.org/wiki/Branch_predictor#Prediction_of_... http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363g/Cihdbcef.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... This type of branch predictor went mainstream in the late 90's with CPUs such as the AMD K6-2. It is not a correctness issue (as long as there's nothing else that thinks it can put stuff on the stack), just a performance issue. You should not expect that the code snippets you "return" to will leave the stack alone -- spill/fill and callee-save instructions etc will kill the part of the "stack" that has already been "returned" from which is fine as long as you don't want to reuse it. But I think you will.