This is yet another reason not to use NT. Ease of use is not something you prefer over stability when running long jobs. Performancewise, NT is not taking full advantage of alpha. Try Tru64 Unix, or Linux/BSD
Compaq XP1000 with alpha-21264-667 with 1 Gb RAM can be had for around 10K. Also check out http://www.alphalinux.org for the list of vendors, including some in MST.
And, no, alpha line isn't going to be discontinued any time soon. In fact, for Compaq, API, and Samsung it is high-margin business still.
Not so. Solving Linear systems via LU factorization can be multithreaded, or parallelized even if in not so obvious way. For example, take a look at MPI implementation in ScaLAPACK
1. Computationally intensive jobs mean lots of floating point operations. Here Athlon outperforms Pentium-III, but less so at higher Mhz, as L2 cache becomes more of a bottleneck. However, Alpha is (so far) the absolute best in floating point. in my experience (=floating point intensive programs in Fortran 90), alpha-21264-667 is 3.7 times faster than P-III-600. Given that one never gets linear speedup by going to more CPU, I predict you'd be better off getting single CPU alpha-21264 ($10K) than quad Xeon P-III, in performance and in price. And, of course, you want Unix/Linux with it, for you don't want results of months of computattion go down the drain due to OS crash:-) 2. Where computationally intensive jobs are required? NOT for web browsing, balancing checkbook, or even games. Hence you don't see either big iron hardware at local shops, and software beyond simple calc, anywhere except may be campus bookstores. Computationally intensive calculations are done in modelling structures, solving weather forecasts, nuclear research, aerodynamics, financial (options pricing), Monte-Carlo and optimization. So it is mostly done in research institutions. No surprize then software is written by Ph.Ds , texts are dry, market is narrow. 3. There still exist free or open source math programs/libraries beyond casual calc. Take a look at MuPad, Octave, LAPACK (http://www.netlib.org ) etc. 4. I am not aware of any incredibly easy book on this. The problem is extremely advanced math requires extreme effort to comprehend (or nobody cared to boil it down). In my area (econ), Judd "Numerical Methods in economics" is pretty good. 5. About breaking up calculations. Ultimately, any program (math or not) does exactly that. there are general principles embedded in compilers technology, and, at a higher level, Fortran or C/C++ programs split the atsk into subtask. But all-purpose ALGORITHM does not exist. During debugging you do the same - look if pieces of the program do what you want them to do. That is why debugging Mathematica programs is on the one hand easier (higher level of abstraction) and more difficult (you have to trust that subroutines you call are working all right) 6. For distributed memory coding, refer to Lusk et al "Using MPI"
Slashdot Mirror
This is yet another reason not to use NT. Ease of use is not something you prefer over stability when running long jobs. Performancewise, NT is not taking full advantage of alpha. Try Tru64 Unix, or Linux/BSD
Compaq XP1000 with alpha-21264-667 with 1 Gb RAM can be had for around 10K. Also check out
http://www.alphalinux.org for the list of vendors, including some in MST.
And, no, alpha line isn't going to be discontinued any time soon. In fact, for Compaq, API, and Samsung it is high-margin business still.
Not so. Solving Linear systems via LU factorization can be multithreaded, or parallelized even if in not so obvious way. For example, take a look at MPI implementation in ScaLAPACK
1. Computationally intensive jobs mean lots of floating point operations. Here Athlon outperforms Pentium-III, but less so at higher Mhz, as L2 cache becomes more of a bottleneck. However, Alpha is (so far) the absolute best in floating point. in my experience (=floating point intensive programs in Fortran 90), alpha-21264-667 is 3.7 times faster than P-III-600. Given that one never gets linear speedup by going to more CPU, I predict you'd be better off getting single CPU alpha-21264 ($10K) than quad Xeon P-III, in performance and in price. And, of course, you want Unix/Linux with it, for you don't want results of months of computattion go down the drain due to OS crash :-) 2. Where computationally intensive jobs are required? NOT for web browsing, balancing checkbook, or even games. Hence you don't see either big iron hardware at local shops, and software beyond simple calc, anywhere except may be campus bookstores. Computationally intensive calculations are done in modelling structures, solving weather forecasts, nuclear research, aerodynamics, financial (options pricing), Monte-Carlo and optimization. So it is mostly done in research institutions. No surprize then software is written by Ph.Ds , texts are dry, market is narrow. 3. There still exist free or open source math programs/libraries beyond casual calc. Take a look at MuPad, Octave, LAPACK (http://www.netlib.org ) etc. 4. I am not aware of any incredibly easy book on this. The problem is extremely advanced math requires extreme effort to comprehend (or nobody cared to boil it down). In my area (econ), Judd "Numerical Methods in economics" is pretty good. 5. About breaking up calculations. Ultimately, any program (math or not) does exactly that. there are general principles embedded in compilers technology, and, at a higher level, Fortran or C/C++ programs split the atsk into subtask. But all-purpose ALGORITHM does not exist. During debugging you do the same - look if pieces of the program do what you want them to do. That is why debugging Mathematica programs is on the one hand easier (higher level of abstraction) and more difficult (you have to trust that subroutines you call are working all right) 6. For distributed memory coding, refer to Lusk et al "Using MPI"