Moving away from signal-driven I/O in Maiko #125
Replies: 1 comment 2 replies
-
The main interpreter loop was THE hotspot in all performance testing. When we were first doing maiko for SPARC, their compiler was awful; did no optimizations. This led to the awful hack of a lex-on-asm peephole "optimizer", written in a way that it would be harmless when Sun fixed their compiler. I'd be surprised if it actually did anything now. |
Beta Was this translation helpful? Give feedback.
-
The usage of signal-driven I/O presents some issues:
I haven't really started to look at what's necessary here. Has anyone else?
I suspect that it will mean changes to the core interpreter loop in
src/xc.c
.Beta Was this translation helpful? Give feedback.
All reactions