In news: firstname.lastname@example.org timestamped Tue, 12 Jun 2007 12:00:51 +0100, Evan Lavelle posted: "[..] On 8 Jun 2007 10:59:32 GMT, Colin Paul Gloster wrote: >If one thread/process is running and all other threads/processes are >not running, then they are not running concurrently. They are not >running, actually. that's how (most) computers work. That's also exactly how the standard Unix process model works,"
By invoking top with top -i (to more closely (though unfortunately still not perfectly) show only active tasks) and after invocation pressing 1 to remove the imaginary single CPU load with loads for real CPUs, it is possible to check that tasks can run literally concurrently (i.e. simultaneously i.e. contemporaneously) as shown in some examples below... Running NCSim with Verilog on a machine with four x86_64 cores (AMD Opterons)... "top - 15:26:15 up 56 days, 20:29, 10 users, load average: 0.27, 0.14, 0.05 Tasks: 190 total, 3 running, 187 sleeping, 0 stopped, 0 zombie Cpu0 : 52.2% us, 8.6% sy, 0.0% ni, 37.5% id, 0.7% wa, 0.0% hi, 1.0% si Cpu1 : 93.4% us, 2.0% sy, 0.0% ni, 0.3% id, 4.3% wa, 0.0% hi, 0.0% si Cpu2 : 72.1% us, 0.3% sy, 0.0% ni, 27.6% id, 0.0% wa, 0.0% hi, 0.0% si Cpu3 : 0.3% us, 0.0% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 8108556k total, 4594596k used, 3513960k free, 143932k buffers Swap: 0k total, 0k used, 0k free, 3576148k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3367 gloster 25 0 32128 16m 5440 R 99.5 0.2 0:06.16 ncsim 3300 petri 19 0 248m 159m 22m R 95.2 2.0 0:06.31 design_vision_e
31390 gloster 16 0 9620 1240 868 R 0.3 0.0 0:24.25 top" Running NCSim with VHDL on a machine with four x86_64 cores (AMD Opterons)... "top - 12:54:51 up 56 days, 17:57, 10 users, load average: 0.18, 0.08, 0.02 Tasks: 185 total, 2 running, 183 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7% us, 0.0% sy, 0.0% ni, 98.3% id, 0.0% wa, 0.0% hi, 0.0% si Cpu1 : 88.4% us, 0.0% sy, 0.0% ni, 11.6% id, 0.0% wa, 0.0% hi, 0.0% si Cpu2 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si Cpu3 : 0.3% us, 0.0% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 8108556k total, 4263752k used, 3844804k free, 143896k buffers Swap: 0k total, 0k used, 0k free, 3408576k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31372 gloster 19 0 24916 10m 4700 R 88.3 0.1 0:02.71 ncsim
31390 gloster 16 0 9620 1212 864 R 0.7 0.0 0:00.10 top" Running NCSim with VHDL on a machine with four Intel Xeon cores... "top - 13:02:02 up 56 days, 17:31, 4 users, load average: 0.39, 0.14, 0.15 Tasks: 128 total, 2 running, 126 sleeping, 0 stopped, 0 zombie Cpu0 : 0.7% us, 0.0% sy, 0.0% ni, 99.3% id, 0.0% wa, 0.0% hi, 0.0% si Cpu1 : 100.0% us, 0.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Cpu2 : 0.3% us, 0.0% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si Cpu3 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 1034188k total, 650436k used, 383752k free, 18696k buffers Swap: 2031608k total, 72320k used, 1959288k free, 328948k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24994 gloster 25 0 24924 10m 4700 R 99.9 1.0 0:13.74 ncsim
24681 gloster 16 0 2152 1148 884 R 0.3 0.1 0:02.25 top"
In news: email@example.com timestamped Tue, 12 Jun 2007 12:00:51 +0100, Evan Lavelle posted: "[..]; SystemC, VHDL, and Verilog all provide user-level concurrency, whatever hardware or OS they run on.
[..] If I can just repeat what I said, or tried to say, im my last post, the issue of underlying concurrency support is just not relevant. HDL simulation semantics are defined in such a way that everything happens *sequentially*
, in such a way that *models*
, or simulates, "concurrency". This is true of any HDL that I know about."
Once again I point out to you that providing the user with only one conceptually running task and forcing the user to manually switch the simulation from one task to another -- which is exactly what is forced upon the user by SystemC(R) cooperative multitasking -- is not user-level concurrency (though an optimizer might be able to find a way to replace the source code with concurrent parts). This is unlike the user-level perception of VHDL with processes whose interleaving is a job for the simulator. It is true that inside a VHDL process one can have sequential code, but the relationship between one VHDL process and another VHDL process can be one of concurrency at the user-level, which is not a SystemC(R) possibility at the user-level because nothing in the SystemC(R) standard involves user-level concurrency. "[..] >[..] However, I am not aware of a SystemC(R) >implementation (aside from synthesizers of course) which actually >exploits concurrent hardware (e.g. a multiprocessor workstation). I'm not either, but that doesn't mean that it hasn't been done, or is not possible."
I had already admitted this in news:f4bcqk$lon$ firstname.lastname@example.org .
" Are you aware of any VHDL or Verilog implementations which exploit 'concurrent hardware'? Yes, I'm sure there are trivial examples of multi-threaded simulators, but are you aware of any simulators which assign processes to threads? I'm not."
No, I am not aware of any industrial simulators which do this. In the Cadence NCSim examples above, not much of the available processing power was exploited.
"[..] Besides, it would generally be pointless; any realistic simulation runs a vast number of "simultaneous" "concurrent" processes, and you need special-purpose hardware to make any sense of that."
Quite a lot of people write software which runs on multiprocessor computers with a task which runs on one processor at the same time as other tasks of the same software's run on other processors, with some of these tasks interacting. "[..] If you're really smart, you can try to take advantage of 'parallel' hardware to run multiple processes simultaneously, but it's difficult."
True. ">If >you check one of the forums on SystemC.org you can notice people who >were not pleased that their OSCI simulators would use just one >operating system process. I've been following these forums for years, and I don't recall any specific discussions on this."
Some examples (N.B. to other people, a password is required for all of these webpages)... From
By: Larry Whitley Subject: sc model thread system thread[ Reply ] Date: 2006-08-21
I'll set the console into raw mode and use getchar() to wait for and receive characters typed at the console. If I do this in a systemc thread (a pthread) the model appears to stop executing while getchar() waits for the next key to be hit. Thus the need for an external system thread.
By: Vincent Viteau Subject: RE: sc model thread system thread[ Reply ] Date: 2006-08-22 Hi Larry, If I understood right, I would have done something similar. This was not about a console but graphical display. So I had my SystemC model and a part of it was a graphical monitor and capture. These last 2 elements were X windows supposed to interact with the user. First I just did everything from SystemC but my problem was that SystemC engine only executes in pure sequence and suspends non active threads. This was not good: 1. to refresh the X windows when necessary, 2. to properly capture all the user actions.
To address this, I used pthread threads. [..] [..]"
By: Paco Blasco Subject: Running SystemC on multiprocessor computer[ Reply ] Date: 2006-12-15 Hi all: I'm developing some SystemC complex simulation, and I've noticed that SystemC only use one processor becouse it appears to be a monothread application. Pthreads/Fibers or QuickThreads maintain only on thread (or fiber ) active each time. Is it possible to use the full performace of a quad processor computer? Are the "control" data of the kernel of systemc thread-safe? I want to modify the "crunch" method of sc_simcontext to provide a concurrent method and thread execution. [..]"
In news: email@example.com timestamped Tue, 12 Jun 2007 12:00:51 +0100, Evan Lavelle posted: "[..] You would use (TM) in normal usage. But my point was that the word "Verilog" is also trademarked. I'm sure that we could have a Verilog discussion without continuously referring to "Verilog(R)" or Verilog(TM)"."
Whether or not "Verilog" is trademarked is irrelevant. The OSCI expressly forbade in a license to me particular ways of using "SystemC". I have noticed that you have an account of SystemC.org. How did you get this account without consenting to the terms I mentioned?
"Everybody else calls it "SystemC"."
Not everybody else has agreed to abide by the OSCI's rules. People who do not have a SystemC.org account nor a copy of anything from the OSCI are not obliged to comply with the OSCI's rules.
Regards, Colin Paul Gloster