dual processors

[charles-brown]

Does anyone know whether MARK supports dual processors? And if so, does using a machine with dual processors significantly speed up the time it takes to run complex multistate models? I'm running a multistate model with 14 strata and 35 capture occasions on a machine with a 3.2 GHz processor and 3.5 GB RAM, and it appears it's going to take days if not weeks. Thanks for any suggestions.

Charles R. Brown

[cooch]

Does anyone know whether MARK supports dual processors? And if so, does using a machine with dual processors significantly speed up the time it takes to run complex multistate models? I'm running a multistate model with 14 strata and 35 capture occasions on a machine with a 3.2 GHz processor and 3.5 GB RAM, and it appears it's going to take days if not weeks. Thanks for any suggestions.

Charles R. Brown

Charles' question comes up a lot - and not simply wrt to MARK. So, here is the 'generic' answer regarding multi-processing and such...

1. having more than one processor in a machine will not speed up execution of a particular application, unless the application was written to execute various instruction sets in parallel. Most applications (including MARK) are not written this way (it is a highly non-trivial task to port anything to a parallel system). As an aside, this is why much of the hype concerning 'clustered computing' and 'massively parallel' is just that: hype. The parallel paradigm is conceptually appealing for certain kinds of problems, which are naturally suited to parallel processing (e.g., a lot of bioinformatics - gene sequencing stuff), but a parallel cluster does squat for you (in terms of processing speed) if your applications execute serially.

2. having more than one processor (which can mean either (i) more than one physical chips, or (ii) a dual-core processor, which amounts to the same thing) will let you do other work while MARK is grinding away (even Windoze is smart enough to allocate one CPU-intensive task to one CPU while letting the oterh CPU - or 'core' handle other things). This is in and of itself not a bad thing - its equivalent to buying a machine just for the purposes of numerical computation (which a number of my colleagues have done). It won't make MARK run any faster, but it will let you do other things on your machine (while you're waiting for MARK to finish).

3. MS models are invariably slow to converge - especially given the number of strata you're trying to work with. This is especially true if you try to avoid local minima problems (described in the MS chapter in the book - see recent papers by Gimenez and colleagues) by using simulated annealing for the optimization - days could turn to weeks.

Of course, this is only true if you're trying to fit a fully time-dependent model to your data - such models in and of themselves are not particularly interesting - you may in fact need to consider a slightly reduced parameter model as your general model.

[Pete Rissler]

Just out of curiosity, I'm running a fairly long multi-strata model on an Intel Core Duo processor. Program Mark is using both processors at 100%. One processor is running Mark.exe and the other is running Mark_int.exe. I was under the impression that the Mark_int.exe program is doing all the calculations so why is the Mark.exe program using up so much processing power?

Pete Rissler

[cooch]

Just out of curiosity, I'm running a fairly long multi-strata model on an Intel Core Duo processor. Program Mark is using both processors at 100%. One processor is running Mark.exe and the other is running Mark_int.exe. I was under the impression that the Mark_int.exe program is doing all the calculations so why is the Mark.exe program using up so much processing power?

Pete Rissler

Other way around - mark_int.exe is the MARK graphical interface/browser, while mark.exe is the 'numerical' engine.

But, more to the point, my guess is that MARK will use all the processor and RAM it is given. A test of this would be to start a few other applications first, then fire up MARK and see how processor load is affected. Of course, memory/processor management is not one of Micro$oft's strong points, so until Gary releases a Linux (or equivalent) version... Actually, porting the numerical routines to Linux (or anything else) would be straightforward (given decent compilers). The graphical interface/browser is another story...