Author |
Topic: MultiThreaded BB4W (Read 3487 times) |
|
DDRM
Administrator
member is offline
Gender: 
Posts: 321
|
 |
Re: MultiThreaded BB4W
« Reply #13 on: May 24th, 2010, 3:54pm » |
|
Hi Richard,
That probably reflects how efficiently you could write your "sharing" data etc, compared to how I would do it! 
I quite recognise that Windows can happily handle lots of threads on a single core, and you may well be right that it isn't worth the effort of checking - that simply always using multiple threads is almost as quick, if you are careful about how you set things up.
As for the testing question, I'm not sure that the differences would be as great as you suggest: could you not use the same procedures in either case, but simply run multiple copies if you have multiple threads running? Maybe I am misunderstanding how things will work.
As a concrete example, consider a Mandelbrot programme: I could have PROCcalcline that take an x range and a y value, a spacing, and an array for the results, and PROCplot that bangs them out to the display.
If I have a single core, I simply alternate between them.
If I have three, I can have two of them running PROCcalcline, and the third one monitoring the data and plotting it when it is ready, in the meantime giving that thread another set of data to work on.
I suspect, but do not know, that the latter scheme would run significantly less efficiently on a single core than the first.
The proof will be in the pudding when the library appears...
Best wishes,
D
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: MultiThreaded BB4W
« Reply #14 on: May 24th, 2010, 5:43pm » |
|
on May 24th, 2010, 3:54pm, DDRM wrote:| Could you not use the same procedures in either case, but simply run multiple copies if you have multiple threads running? |
|
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?
Irrespective of testing, there is bound to be extra work in writing code that works correctly in the two different ways (concurrent and alternate).
Quote:| I suspect, but do not know, that the latter scheme would run significantly less efficiently on a single core than the first. |
|
Why do you suspect that? As previously discussed in this thread, you will want the spawning of the other process(es) to happen only once, because there's a significant overhead for that. So, for a relatively slow operation such as plotting a Mandelbrot set, the once-off spawning will take an insignificant time.
That leaves us with the overhead of process switching and synchronisation. I find it hard to see why that would necessarily be significant. Can you explain?
Quote:| The proof will be in the pudding when the library appears... |
|
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.
Richard.
|
|
Logged
|
|
|
|
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
|
|
|
|
|
