1
2
3
4\logo [XEON] {XEON}
5\logo [OPENSUSE]{OpenSUSE}
6\logo [QEMU] {QEMU}
7
8\startcomponent musingsriscv
9
10\environment musingsstyle
11
12\startchapter[title={Testing \RISCV}]
13
14\startsection[title={Introduction}]
15
16Having played with and being interested in electronics since I was kid, it will
17be no surprise that I also keep an eye on \RISCV. And because of that I already
18wondered for a while how easy it would be to compile \LUAMETATEX\ on that
19architecture. Although there are now some decent small boards that can be used, I
20dont have these, which made me check out if one could emulate it.
21
22\stopsection
23
24\startsection[title={Virtual machines}]
25
26Back in the days I used VMWare to run a \LINUX\ machine on my \WINDOWS\ laptop,
27but nowadays the Linux Subsystem is pretty good for what I want. On the servers
28we always used (OpenSUSE) linux although at some point we switched from bare
29metal to virtual machines on top of Proxmox. So, there is some experience with
30virtual machinery. Of course a question to be asked is \quotation {What does it
31do with performance?} but plenty about that has been said in the past so I stick
32to a summary.
33
34Given enough memory and a decent disk setup, for us running \TEX\ in a virtual
35machine is not that significant slower as on bare metal. For instance, running a
36NAS on the same virtual host is quite efficient, because of the more or less
37direct connection, while using the same NFS setup over different machine comes at
38a higher price. The same is true for compiling in the Linux Subsystem: a single
39core \TEX\ process can benefit from the other core being used by the host for
40file management.
41
42Performance of \TEX\ depends not only on the \CPU. Just compare making a format
43file on a freshly restarted computer with a second make: its way faster due to
44the operating system caching the many files that get loaded. The same is true for
45making the font database although that happens seldom. The console is actually
46one of the factors that has a high influence.
47
48However, in al these cases we use a real \CPU\ for the task. In the case of this
49test with \RISCV\ I had to use an emulator (QEMU) so I knew that performance
50would be kind of bad. Of course thats relative because even (say) 20 times
51slower would just bring us back to the beginning of this century and its not
52like performance was a show stopper then.
53
54\stopsection
55
56\startsection[title={Compiling \LUAMETATEX}]
57
58I used my \LINUX\ laptop that has the same specification as the \WINDOWS\ one: a
59refurbished Dell Precision 7520 with plenty memory, a fast large \SSD, and mobile
60\XEON\ \CPUs.
61
62The \LINUX\ machine runs \OPENSUSE\ and I was able to install a \RISCV\ virtual
63machine using \QEMU, once Id figured out how to boot one. Its a bit of a hassle
64but in the end it works. Compiling \LUAMETATEX\ boils down to:
65
66\startitemize[packed]
67\startitem installing the \GCC\ compiler (in this case version 13) \stopitem
68\startitem installing \CMAKE \stopitem
69\startitem fetching the \LUAMETATEX\ git repository (I used \type {work}) \stopitem
70\startitem running the \type {build.sh} script \stopitem
71\stopitemize
72
73When we had to support the Raspberry Pi and the Apple M* architectures we had to
74adapt a few compiler flags and have some specific platform detection (not that
75dramatic). So I expected that I had to tune for \RISCV\ but in the end the code
76just compiled. It took however quite some time. Later I gave the virtual machine
77four cores and then compilation time was sort of acceptable. So, I had a binary!
78
79\stopsection
80
81\startsection[title={Running \TEX}]
82
83Next comes a challenge: how to test \LMTX\ when there is no installer. I mounted
84my main disk to the virtual machine and just copied the \TEX\ tree from there.
85Then I copied the binary from \type {buildnative} to the \typ
86{texmflinux64bin} path and voila, after extending the \type {PATH} variable I
87could make a format. Because \TEX\ is a single core process, one has to be
88patient.
89
90\starttabulate[lr]
91\NC \RISCV \NC 17.8 s \NC \NR
92\NC \LINUX \NC 1.0 s \NC \NR
93\NC \WINDOWS \NC 2.0 s \NC \NR
94\stoptabulate
95
96The winner is \LINUX. The \WINDOWS\ binary is a cross compiled \MINGW\ one and I
97think that the difference in performance is mainly due to file handling. In all
98tree cases the log is piped to a file, otherwise these times are quite a bit
99higher.
100
101Next I ran the following file, which results in 223 pages:
102
103\starttyping
104\starttext
105\dorecurse {1000} {
106 \samplefile{tufte}\par
107}
108\stoptext
109\stoptyping
110
111This time we need:
112
113\starttabulate[lr]
114\NC \RISCV \NC 46.1 s \NC \NR
115\NC \LINUX \NC 2.9 s \NC \NR
116\NC \WINDOWS \NC 2.8 s \NC \NR
117\stoptabulate
118
119The reason why \LINUX\ and \WINDOWS\ are the same is that there is less file
120access. We load the format file, some fonts, the main file, and output a few
121hundred pages \PDF.
122
123The emulated \RISCV\ machine is about 15 times slower so not really an option for
124production but that was not the objective anyway. Actually, if I remember right,
125the first Raspberrys were not that fast either and those were bare metal and
126currently most \RISCV\ boards are in its version 3 performance range. Also, this
127test is mostly done to see what is needed to support \RISCV: nothing special.
128
129\stopsection
130
131\startsection[title={Conclusion}]
132
133The main conclusion is that it was actually quite easy to support this new
134architecture. Of course I now need to come up with an installer but I delay that
135till I have hardware because buying some just for testing makes little sense. After
136all I dont have an M3 for testing either.
137
138The installation script has been extended with a \type {native} option (one can
139also set that in the installer file) in which case files will be updated. This
140assumes that the user has compiled a binary and put it in the installations \type
141{bin} path alongside the \type {mtxrun.lua} file there. The user also has to make
142sure that \typ {textexmfnative} has the updated binary. Its a bit more work
143but at least one has an updated system.
144
145In the end a 15 time slowdown is not that dramatic. Weve made \CONTEXT\ a bit
146faster with \LUAMETATEX\ anyway. My best laptop will be 1.5 times (or more)
147faster and I expect upcoming \RISCV\ boards to catch up too, just like all these
148\ARM\ machines did.
149
150Just for the record: I didnt try to compile \LUATEX. That source tree is much
151larger and there are all kind of dependencies involved. It takes way more time to
152compile anyway. But I expect it to works out well too.
153
154\stopsection
155
156\stopchapter
157
158\stopcomponent
159
160 |