Author |
Topic: MultiThreaded BB4W (Read 3465 times) |
|
DDRM
Administrator
member is offline
Gender: 
Posts: 321
|
 |
Re: MultiThreaded BB4W
« Reply #15 on: May 25th, 2010, 08:35am » |
|
on May 24th, 2010, 5:43pm, Richard Russell wrote:If you have a program which does different things according to the number of cores, are you seriously suggesting that you need test only one of the cases? In other words, are you proposing that you test only the multi-core situation, and somehow structure the code so that the single-core case is bound to work, although untested?
|
|
No, but I would expect it to work fairly straightforwardly, if most of the code is the same! My main machine is a quad-core AMD, while my laptop is a single core Intel, so I could test it in both situations. Actually, allowing testing for cores makes this problem easier, since, by disabling the test for cores and therefore NOT starting new threads, it should behave the same in a multicore machine as it would on a single-core one, shouldn't it? What you couldn't do is test the multi-core behaviour rigorously on a single-core machine, since it (shouldn't) spawn the new threads.
Quote:Why do you suspect that? ...(it would be slower running multiple threads on a single core)... Can you explain?
|
|
Largely because you would be forcing the processor to switch between the threads you had started, giving each a bit of processor time, then interrupting, and giving the next a go. In contrast, by running only a single copy, all the processor time allowed to my programme would be used as efficiently as possible. I don't have a feel for what the overheads involved in that are.
Quote:I'm pretty happy with the library, but as all my PCs have only a single CPU/core I can't test it as thoroughly as I would like. I don't have any immediate plans to release it.
|
|
I'm sure you wouldn't consider my "testing" rigorous enough, but if you would like me to RUN some tests on a multi-core machine and report the results, I will happily do so.
Best wishes,
D
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: MultiThreaded BB4W
« Reply #16 on: May 25th, 2010, 11:29am » |
|
on May 25th, 2010, 08:35am, DDRM wrote:| Largely because you would be forcing the processor to switch between the threads you had started, giving each a bit of processor time, then interrupting, and giving the next a go. In contrast, by running only a single copy, all the processor time allowed to my programme would be used as efficiently as possible. |
|
You are here simply restating the obvious, that switching processes takes a finite time. What you have failed to do is provide a plausible argument that the overhead is significant, and outweighs the clear advantages of my suggested approach (spawning multiple processes irrespective of the number of cores).
Context switches in Windows are fast, because typically there are large numbers of them taking place all the time, to service the many background tasks.
Quote:| I'm sure you wouldn't consider my "testing" rigorous enough, but if you would like me to RUN some tests on a multi-core machine and report the results, I will happily do so. |
|
I will see if I can find a suitable program (maybe the Mandelbrot plot you suggested) that I could use as a test bed. If I can, I'll send you something to try on your multi-core machine.
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: MultiThreaded BB4W
« Reply #17 on: May 26th, 2010, 5:29pm » |
|
I seem to have reached rather a dead-end with SPAWNLIB. It works (sort of) but there are two quite serious problems that I can find no way around:
1. Programs using it must be Run As Administrator on Vista and Windows 7. This is due to the way shared memory is handled on those systems, and I don't know of a workaround.
2. Large numbers of handles are leaked. This appears to be due to ShellExecute, which on its own seems to leak handles. I don't know how to prevent it.
So unless solutions to these problems are found, I will archive SPAWNLIB as an interesting, but failed, experiment.
Richard.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: MultiThreaded BB4W
« Reply #18 on: May 27th, 2010, 03:19am » |
|
on May 26th, 2010, 5:29pm, Richard Russell wrote:| 1. Programs using it must be Run As Administrator on Vista and Windows 7. This is due to the way shared memory is handled on those systems, and I don't know of a workaround. |
|
Would ShellExecuteEx using SEE_MASK_NOZONECHECKS be a solution? I haven't tested this but I hope this doesn't look at time zones instead, and I don't know how this effects Shared Memory created with the File Mapping functions.
Quote:2. Large numbers of handles are leaked. This appears to be due to ShellExecute, which on its own seems to leak handles. I don't know how to prevent it.
|
|
Also wouldn't using ShellExecuteEx give a way to return the handle to the process invoked?
Quote:| So unless solutions to these problems are found, I will archive SPAWNLIB as an interesting, but failed, experiment. |
|
I ask for my own enlightenment rather that assuming you hadn't thought of these...
Michael
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: MultiThreaded BB4W
« Reply #19 on: May 27th, 2010, 08:33am » |
|
on May 27th, 2010, 03:19am, Michael Hutton wrote:| Would ShellExecuteEx using SEE_MASK_NOZONECHECKS be a solution? |
|
What makes you think it might? The way Vista/7 handle shared memory isn't a function of how the process is launched (you can use the lower-level CreateProcess and the behaviour is the same).
Quote:| Also wouldn't using ShellExecuteEx give a way to return the handle to the process invoked? |
|
As I said earlier in the thread, SPAWNLIB doesn't need to know the process handle. As you will appreciate, the process handle has nothing whatever to do with the handle leaks I mentioned; it is closed automatically when the process terminates.
Quote:| I ask for my own enlightenment rather that assuming you hadn't thought of these... |
|
It's not so much that I hadn't thought of them, I don't see their relevance to the issues I mentioned (requiring to be Run As Administrator under Windows/7 and handle leaks from ShellExecute).
Richard.
|
|
Logged
|
|
|
|
|
