UPDATE: 09.06.25
There was a misinterpretation of the data gathered, when it was first posted.
Quixie has shed 78.33% off its processing time when executing the Math benchmark, which makes it 529.73% faster; not 78.33% as first posted — that’s more than 5 times faster.
———-
I have done a comparison sheet as to how fast Quixie is becoming.
As always, ctr++ is still the fastest approach to increment a value, while Math:Add is lagging way behind. It’s also notable that ctr + 1 had cut more than 2 seconds off its previous record.
You could clearly see that Quixie has dramatically increased its speed — 529.73% faster than before.
So, how was this possible?
As stated last time, Quixie has been undergoing speed optimization. Partially, a JIT optimizer (not JIT compiler (JITC)) has been implemented to Quixie’s core functionality, especially in parts where the interpretation-process is tight and repetitive.
You may not have heard of JIT optimizer (JIO), that’s because we made that up.
We can’t call the algorithm as JITC because none is being compiled as to what’s stated to how JITC work.
To give you an idea, JITC compiles the bytecodes to virtual machine readable commands, while JIO still interprets the script on-the-fly. But after the first pass, the script is being cached to optimize the interpretation for the next pass.
You may ask why JITC was not used instead. The simple answer is, JIO is easier to implement.
With not enough free time to re-write Quixie, JIO is the only way to go.
Plus, execution will be done after all pre-processing is done, unlike in JITC, you have to wait for the program to be compiled before seeing it executed. But, JIO is not guaranteed to execute faster than JITC. No proper benchmarking has been done to prove any but, ideally, JITC should be faster.
Mj Mendoza IV
KonsolScript Developer
Leave a Reply