Hallo,
when looking through the ghdl sources in the current git master
I found in ./grt/grt-options.adb some code implementing the option
--threads=N use N threads for simulation
The option isn't shown in --help, text commented out. When used
it is accepted, but doesn't seem to have much of an effect.
So I wonder whether this is dead code of an aborted effort or
whether is a current development. git blame shows that the code
is at least 2.5 years old.
I got curious, and looked a the --stats output of two simulations
1. direct simulation of the behavioral model. In this case we have
a small number of larger processes.
cycle (sum): wall: 90.130 user: 72.590 sys: 13.460
processes: wall: 64.410 user: 53.460 sys: 5.510
resume: wall: 3.970 user: 2.900 sys: 2.350
update: wall: 16.680 user: 12.200 sys: 2.820
next compute: wall: 5.070 user: 4.030 sys: 2.780
Number of processes: 766
Number of sensitized processes: 741
Number of resumed processes: 197210264
Average number of resumed processes per cycle: 14
2. functional simulation with a post-synthesis model generated
by vivado. Lots of UNISIM primitives, so a larger number of
in general quite small processes (mostly Flops and LUTs).
cycle (sum): wall: 60.750 user: 58.450 sys: 2.270
processes: wall: 28.330 user: 28.630 sys: 0.540
resume: wall: 0.530 user: 0.470 sys: 0.570
update: wall: 22.890 user: 20.270 sys: 0.510
next compute: wall: 9.000 user: 9.080 sys: 0.650
Number of processes: 6090
Number of sensitized processes: 6003
Number of resumed processes: 190890059
Average number of resumed processes per cycle: 91
I'd assume that the 'processes' part is what can be easiest
parallelized, that is 72% in the behavioral and only 49% in
the post-synthesis simulation. If only 'processes' can be
parallelized the potential is actually rather sobering.
Any thoughts on that ?
With best regards, Walter
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
