new MARK release | v. 6.2

[cooch]

Gary has just posted version 6.2. While it has been fairly well tested, it should be considered 'beta' for a week or so, in case any 'kinks' turn up. You can download the new 6.2 beta, and the stable prior 6.1 release, on the left-hand side of the following:

http://www.phidot.org/software/mark/download/

About the new release

There are 2 'major enhancements' of the new release:

1\ 32-bit and 64-bit support

2\ multi-core support

Some comments:

1\ 64-bit is *not* by definition faster than 32-bit. Anyone who tells you otherwise is promulgating hype (I've gone into technical details as to why in other posts). What 64-bit gives you is access to greater RAM space. For many people this is neither here nor there. For people working with big, high-dimensional problems, this can be a big (critical) advantage. When you install the new MARK (6.2), two versions of the numerical component of MARK are installed: mark32.exe and mark64.exe. MARK will detect the bit-length of your operating system, and use either mark32.exe or mark64.exe, as appropriate. People using rmark will need to be aware of this, and adjust accordingly (see this recent post by Jeff Laake).

2\ the *really* nifty feature (IMO) is multi-core support. MARK will now use multiple cores to improve the efficiency of some of its internal computations (most especially, generation of cell probabilities). This can make a big difference for large jobs (I've had actual run times - based on time elapsed from submission of the model to the prompt to add the result to the browser- reduced by 30-40%. Your results may vary). For small problems (short time series, small state space, low dimension), the speed improvements may not be overly noticeable (if you notice them at all). For large ugly problems, multi-core processing can make a very real difference.

So, if you have multi-core processors (as most new machines of the last year or so generally do), MARK will use them. However, it is worth noting that Gary has provided some control over how many cores MARK will use. Under 'File | Preferences', you will now see an option to set the 'number of threads for numerical processing'. If you enter 0 (the default), MARK will use the maximum possible (meaning, all of your cores). If you enter a negative value (say -1), it will use one less than the number of possible cores. So, if you want MARK to really tie up your machine, use the default of all the cores. Faster, but makes it somewhat difficult to do much else while MARK is grinding away. If you want to 'keep one core available' to do other things, enter -1. And so on.

As with all new releases, it is worth *carefully* checking your results using the new MARK against the older stable release. If you find anything truly odd/broken, contact Gary. Be sure you send him enough information to help him see what is going on (operating system, data type, sample data files, etc).