Over the last few weeks the Red Lang core team drilled down to make some truly great progress on Red’s fast-lexer branch–while we also gained valuable support from the contributions of Red doers and makers as they consolidate a world of useful information and resources.
In the fast-lexer branch
of Red, you can see lots of new work from Red creator @dockimbel (Nenad Rakocevic
) and core teammate @qxtie
. Among other fixes and optimizations, they substituted a hashtable for what had previously been a large array in context!
The numbers so far: Loading 100’000 words (5 to 15 characters, 1MB file):
Red (master): 19000ms. Red (fast-lexer): 150ms. Nenad’s observations on further testing:
“FYI, we just [ran] some simple benchmarks on the new low-level lexer for Red using 1M 10-digit integers. The new lexer completes the loading about 100 times faster than the current high-level one. Loading 1M 10-digit integers in one block: Red: 175ms; R2: 136ms; R3: 113ms.
“We use a faster method than Rebol, relying on several lookup tables and a big FSM with pre-calculated transition table (while Rebol relies on a lot of code for scanning, with many branches, so bad for modern CPU with branch predictions). With an optimizing backend, Red’s LOAD should in theory run 2-3 times faster than Rebol’s one. (Though, we still need to optimize the symbol table loading in order to reach peak performance). Given that Rebol relies on optimized C code while Red relies on sub-optimal code from R/S compiler, that speaks volume about the efficiency of our own approach. So, Red/Pro should give us a much faster LOAD.
“The lexer is not finished yet, but the hard part is done. We still need to figure out an efficient way to load keywords, like escaped character names (`^(line), ^(page), …) and month nouns in dates.”
This is a huge accomplishment, and it’s shaping up to make future goals even more impressive. The fast-lexer branch
is a work in progress, but stay tuned: Nenad has more to say about why it’s been prioritized just now, which we will have in an upcoming post.
Red’s MVPs Contribute New Resource Material & Tools
If you’re new to Red, sometimes the flexibility of the language can leave you uncertain about which aggregate structure to use. In red/red’s wiki
on github, @9214
contributes a useful guide
for those seeking to tease apart the differences. For example, map!
works better with data that can be atomized, or framed as a conventional associative array, while hash!
lends itself to data that will be queried at a high volume and which will require fewer updates. Learn further linguistic nuances, including object!
, as well as a useful comparison table of their algorithmic complexity, here
, meanwhile, has furnished us with loads of useful information, diving deeper into code statistics. His value datatype distribution, here
, his unofficial Red build archive here
, and his rebolek/red-tools repo
containing various tools–line parsers, codecs, APIs and documentation among them–are greatly appreciated. The tools repo has a number of new features you can check out here
About Those Ports…
Wondering about port!
? Here’s the latest
. We’ve got port!
in the master branch already, but low-level input/output networking abilities aren’t complete yet, so we need to focus on this, and your feedback can always help. “We have a working async TCP and TLS ports implementation (both client and server-side),” explains Nenad, “but they still require more work to cover all the target platforms.” Here
, he goes on to explain the prerequisites for our team to complete this process; your thoughts and code contributions are welcomed.
Games and Experiments
It’s a fun one
to end this update on: Red community member @GalenIvanov
’s “Island Alleys,” a game of unspooling Hamiltonian paths! A path of this type only allows its line, which inscribes a closed loop, to cross through a vertex within a graph once, a process which can lend itself to neural network-related interpretations. And @planetsizedcpu
offers a wintry little spin on this repo
. Enjoy, and thanks to all!