On Fri, Apr 19, 2024 at 07:12:06PM +0800, Qian Yun wrote:
> You can notice a "pause" when you draw a picture like:
>
> (1) -> draw(x,x=1..2)
> Compiling function %C with type DoubleFloat -> DoubleFloat
> Graph data being transmitted to the viewport manager...
> FriCAS2D data being transmitted to the viewport manager...
> <<<<it is paused here>>>>
> (1) TwoDimensionalViewport: "x"
>
> It is also very noticeable when you generate the viewports.
>
> The following numbers are build with 8 cores.
>
> This is build without X11.
>
> real 1m52.533s
> user 6m47.266s
> sys 0m58.385s
>
>
> This is build with X11. So it takes 11s more CPU time
> to build hyperdoc/graphics binary and run them to
> generate hyperpages and viewports.
>
> But the user have to wait 1 more minute to see the build
> finish. Most time is wasted on this "sleep".
>
> real 2m52.534s
> user 6m58.368s
> sys 0m55.921s
>
>
> This is build with X11 and this patch.
> This takes 14s more CPU time and 9s real time.
>
> real 2m1.381s
> user 7m0.911s
> sys 0m56.194s
>
>
> The "readViewport" and "send_int" are synchronized IO,
> so no race condition here.
Long ago I looked at communication protocol between various
processes that we use and my conclusion was that it is
inherently racy: there are parallel chanels of communication
and both ends assume that data comes in right order. I added
a little piece of code to detect lost race, that mitigates
worst things. Machines now are faster than in the past,
so lost races probably are quite rare given 1s delay.
It is quite possible that original authors after realizing
that there are races put delays in places that are not necessary
(and wrogly placed delay could even make races worse).
To explain more: most of C code uses sockets and this alone should
be OK. However, data from FRICASsys sends textual output on
standard output, which is captured by 'sman'. But "event indicators"
are sent via sockets, so we depend on data on FRICASsys standard
output and data coming via sockets to arrive in order in which
it was sent.
> The only reason to put a "sleep" here,
> I presume it is a workaround for a bug in viewAlone:
>
> See the "printf" I removed bellow: it writes to stdout instead of
> stderr, causing the parent process function "readViewport" to return
> early and make parent process exits, and the data passed to child
> process via pipe is lost.
IIRC 'viewAlone' is started from HyperDoc when you click on a image.
Normal graphics uses 'view2D' and 'view3D' via 'viewman'.
Anyway, I think it would be reasonably safe to use smaller delay,
say 50 or 100 milliseconds (I use such delay during startup).
Quite possible that we can elliminate the delays, but that IMO
would require deeper analysis and more testing. As I wrote we
have several channels of communication and code assumes certain
ordering contraints. Without identifying contraints (and some
could be far from obvious) and analysing them it is hard to say
more than "there are races".
BTW: My inital motivation for work on streams was to pass all
FRICASsys (actually it was called AXIOMsys at that time) output
to sockets, which would allow messages with confirmation.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZiJmXz8JYw2GfIRC%40fricas.org.
