Hi,
We recently implemented a parallel π-WAM on
a CPU backend and could demonstrate an
estimated 1.7 Giga Lips. This CPU backend
was written in Java, uses Java platform
threads and is meanwhile part of library(edge/
brainfog). In the following we report first
porting steps to JavaScript.
With the adoption of JavaScript workers we
embrace preemptive multithreading, even
for a Web Prolog, and depart from Dogelog
Players cooperative multitasking. The design
also adopts SharedArrayBuffer to replicate
the Java heap, that is shared among
Java platform threads.
Bye
See also:
Parallel π-WAM: JavaScript Workers as CPU Backend
https://medium.com/2989/5ef903e5e785
Mild Shock schrieb:
Hi,
We recently implemented a parallel π-WAM
on a GPU backend and could demonstrate an
estimated 11.4 Giga Lips. In this post we
report a further experiment, this time
presenting a parallel π-WAM on a CPU backend,
that can lift specialized Prolog, currently
to 1.7 Giga Lips performance.
Having an excess number of threads is a
bad idea. What if we do context switching
on our own? With this approach we could
bring down the execution time of 128 Hack
VMs by 33%. We estimate for the test which
had 11.4 GLips on the GPU, that we reach
1.7 GLips on the CPU.
Bye
See also:
Parallel π-WAM: 1.7 Giga Lips on a CPU
https://medium.com/2989/8a984e75af44