View Single Post
Coin
Coin is offline
#55
Dec8-07, 04:33 PM
P: 587
Garrett, thanks! I may have some more questions later :)

Quote Quote by Cold Winter View Post
Quote Quote by Garrett
The tables in my paper just involve the roots for E8 -- it is not necessary to consider representations. (Though considering the representations may be needed for quantization -- which is a somewhat terrifying prospect.) If you do try to reproduce the Atlas calculation, let me know so I can send your computer a sympathy card.
LOL, I have no sympathy for iron. I just pound it hard. While the prospect of running my little monster here for 8 weeks straight doesn't bother me ( I have nice cool place for it here in my home ), I want to build a new little monster. The Atlas redo kinda justifies it... sort of gives me an excuse... sort of... . Problem is this is a wait for prices and technology to converge issue. I'm reasonably certain a 16way AMD64 system will be fairly cheap to build in about 18 months.
Hi Cold Winter, you may want to read the ATLAS group's somewhat tortured narrative of exactly how they went about their calculation. The limiting factor turns out to actually be not CPU power, but RAM. Performing the calculation turns out to involve constructing some tables that grow to hundreds of gigs in size, and they found that they essentially had to store the entire table in RAM, as the calculation requires so many more-or-less-random accesses to this table that access times would have been prohibitive had they allowed swapping to disk. It's an interesting read, anyway.

Incidentally, as regards your comment about doing calculations in C, I think actually this is not so necessary as it at first seems. For heavy computation of the exact kind that dominates the E8 stuff-- working with vectors and matrices and such-- C is I think not actually a very good choice. Many higher-level languages can do vector and matrix operations with a highly optimized backend library, removing many of the advantages C would get in this area from being "closer to the metal". On the other hand with C the "close to the metal" nature can actually be a major drawback, since the degree of power given to the programmer in C takes power away from the compiler, thus preventing many useful compiler optimizations from being possible-- and with this kind of stuff a compiler really is usually much better at optimizing than a human is. I can't speak to the efficiency of Mathematica in specific but it would not surprise me if there are language platforms, for example among some of the functional languages, which resemble Mathematica more than C and yet get better performance than C on E8-related calculations. Of course, these languages bring their own problems! And if you are going to be doing something on the scale of the ATLAS calculation I would tend to suspect you have no choice but to use C. Interestingly ATLAS has a package of downloadable software (although I am not sure whether the E8 map program is included) and it is all written in C++.