Up to Main Index Up to Journal for April, 2023
JOURNAL FOR THURSDAY 13TH APRIL, 2023
______________________________________________________________________________
SUBJECT: Support, benchmarks and more types
DATE: Thu 13 Apr 11:59:37 BST 2023
This morning the server was down for a brief period. Seems there was a minor
hiccup with a tftp server the server boots from. Quick email to support at
Mythic Beasts[1] and the server was up and running again in about 30 minutes.
Thanks guys, great job as always :)
Amazingly I managed to get the new version of Mere deployed on the server for
everyone to play with. I expected people to be asking for better IF statements
or FOR loops, maybe even functions — all my big ticket items. But, people can
be funny and surprise you. What was the most requested feature? More types!
Specifically unsigned integers, bytes and runes :|
I’m working on unsigned integers now, most of the code is done. It’s actually
taking me longer to update all of the tests. The hardest part was deciding on
how to represent unsigned integer literals. Go has this nice thing where
literals, like constants can be untyped. This allows, for example, 12345 to be
an integer or unsigned integer depending on context. Mere does not have such
nice things :(
For now an unsigned integer can be obtained in one of two ways: the uint
operator or a ‘u’ suffix on the integer, with any of the int forms:
// Integers
x = uint 12345 // decimal
x = uint 0x3039 // hex
x = uint 0o30071 // octal
x = uint 0b11000000111001 // binary
// Unsigned integers
x = 12345u // decimal
x = 0x3039u // hex
x = 0o30071u // octal
x = 0b11000000111001u // binary
This is already working. The second form was added to make uint arrays and
uint map keys more palatable. For example:
x = [uint](
1u 42u,
2u []uint(0u, 1u, 1u, 2u, 3u, 5u),
)
x = [uint](
uint 1, uint 42,
uint 2, []uint(uint 0, uint 1, uint 1, uint 2, uint 3, uint 5),
)
I think we can all agree that the first uint map definition is much more
preferrable to the second :|
Then I need to decide on bytes and runes:
x = byte 12
x = uint8 12
x = 12u8
x = '⋆'
x = rune 0x22C6
x = int32 0x22C6
x = 0x22C6u32
So, ‘u’ is 32-bit or 64-bit dependant on platform and ‘uxx’ is of a specific
size. I guess I’m going to need u8 (byte), u16, u32, u64 as well as i, i8, i16
(rune), i32, i64 for signed integers? At the moment floats are all 64-bit. Do
we need f32 and f64 as well? Oh bother! :P
Some people have asked if I could provide some performance figures for the
latest Mere compared to the old Mere. Here you go…
Speed
Old New Diff Up Notes
------- ------- -------- ----- -------------------------------
Debian: 3456ms 399ms -3057ms 8.6x 64bit, desktop i5-2400 @ 3.1Ghz
Win10: 3989ms 557ms -3432ms 7.2x 64bit, KVM+QEMU virtual machine
RPi4: 7551ms 970ms -6581ms 7.9x 64bit, 8GB RAM
RPi4: 11780ms 1141ms -10639ms 10.3x 32bit, 4GB RAM
Edge: 21107ms 2080ms -19027ms 10.1x 64bit, Debian v112.0.1722.39
Chrome: 21915ms 2189ms -19726ms 10.0x 64bit, Debian v112.0.5615.49
RPi3B: 33524ms 4264ms -29260ms 7.9x 32bit
RPi0: 96203ms 10270ms -85933ms 9.4x 32bit
All tests run multiple times. All Raspberry Pi run Raspberry Pi OS, switched
to the testing distribution. Not sure why Edge was a tad faster than Chrome.
All compilation was done natively on the hardware with Go 1.20.3
The test script was my standard benchmark counter.mr:
// A mere counting example...
//
// Useful for benchmarking.
end=0; start=time
println("123456789%")
x=0
loopx:
if x++ % 100000 == 0; print "."
if x < 1000000; goto loopx
println "✓"
end=time; printf "Out: %dms\n", (end-start)/1000
Minimum speed-up was 7.2 (Windows 10 in a KVM+QEMU virtual machines). Highest
speed-up was 10.3x (Raspberry Pi 4, 4Gb RAM, Respberry Pi OS).
If you are wondering why I included Windows 10 and Edge — I’m having to use
them a lot for work at the moment :| They just happened to be handy at the
time I was testing…
--
Diddymus
[1] Not affiliated, just a great hosting company to do business with:
https://www.mythic-beasts.com
Up to Main Index Up to Journal for April, 2023