Nope. To quote from "Linux/IA64: Preparing for the Next Millenium" from "Proceedings of the 5th Annual Linux Expo":
"The user programming model is the standard LP64 moden meaning that the C data type "long" as well as pointers are 64-bit in size. This is the same model that has been adopted by all other Linux and UNIX 64-bit platforms in existence."
Moreover, "long long" is not in C99 (the latest ANSI C Standard); it is a gcc specific extention. The correct type should be "long long int"; this is guaranteed to be at least 64-bits. Most compilers will probably choose for this to be double the native word size (or 128-bit for 64-bit CPUs).
I read the referenced RealWorldTech article well before seeing this information on Slashdot, so I'll give a summary of Paul DeMone's conclusions, as well as my impression of why Sledgehammer was excluded.
*Alpha: The reigning champion of the 64-bit processors battlefield. The 21264a (EV67) shipping now still has the best integer and FP performance of any processor. The 21264b (EV68) will be released in two phases: first as a hybrid.18/.25 process, then fully migrated to.18 design rules. The clock speed (especially after it's contracting out to IBM) will become competitive again. 21364 will add improved SMP capabilities (and an improved cache) to the basic EV6 core. The 21464 will be an impressive 8-issue processor with simultaneous multithreading. *PA-RISC: HP has not neccesarily given up on its own processors, despite its nominal strategic alliance with Intel's IA64. An enormous cache allows the current members of this family to keep pace, even without significant architectural modifications. Later members could *Itanium: A bloated instruction set that is incredibly ornate. Heavily dependent on compiler technology. Lots of marketing hype that exaggerates the true technical merit of the Merced processor. The Merced will debut at a relatively slow clock speed, but McKinley (HP's 2nd generation IA64 CPU) will definitely been a key competitor in the 64-bit HPC market. *Sparc: Poor in performance, but software application support keeps these Sun processors alive. Even the not-yet-released UltraSparc 3 will have disappointing performance relative to modern processors. *MIPS: Fading out. *Power: The Power4 looks very impressive, but not much information has been released about it to this point.
The Sledgehamer is simply not a very interesting chip; it is generally agreed that x86 had the misfortune to become the most popular desktop ISA, without regard to its actual merits. An extention of x86 to 64-bits does not interest people much, essentially because of how ugly, inefficient, and inelegant the original x86 ISA is/was. Speaking for myself, I certainly do not want to have to put up with 30 more years of this defectiveness.
For existing x86 32-bit code, I expect the Sledgehammer to perform significantly better than the Merced in all respects (for equivalent clock speeds). For heavily numerical or scientific programming, I expect that the Merced will do better than the Sledgehammer, even with a significant clock speed differential (the Sledgehammer will probably release with a > 300 Mhz lead over the Merced). This is especially so for tasks such as encryption, large integer arithmetic, computational linear algebra, and certain other applications of this type. One must keep in mind that the Merced can potentially execute 2 bundles of 3 instructions each every clock cycle (and that some instructions can perform more than one operation on multiple operands); optimistically, Merced can perform something like 12 discrete operations every cycle (on full width words, no less). For general purpose applications(non-server, non-computational codes), before the IA64 compilers mature, I think that the Sledgehammer would do better.
No, the language specification is not affected by the underlying instruction set of the processor on which the code is compiled or executed (especially so for Java (or so I would hope), with its much vaunted platform independence). I do suppose that some vendors (if they have not yet done so already) would offer a compiler specific additional type, akin to the pre-C99 "long long" or "_int64" offered by gcc, VC++ respectively.
"Don't forget that you'll have to buy twice the RAM chips to get the same amount of memory (effectively.)"
Bullshit. The size of the base word will not affect the effective amount of memory, just the amount of memory that can be addressed. If you declare a 16-bit variable (probably a short, but ANSI makes no guarantees), it will occupy 16-bits, subject to alignment constraints.
"And programs will be about twice as large on your hard drive due to the 64 bit instruction words."
(Alpha) stage3-decompose.o: 213920 bytes (x86) stage3-decompose.o: 264018 bytes Here's a hint: 64 bit ISAs don't neccesarily use 64 bit instructions; the x86 ISAs variable length words take up as much (if not more) space than the fixed 32-bit words in more RISC-like ISAs.
"And there's no point in running a 64 bit system with IDE drives, so you'd best pick up some nice expensive SCSI drives, too."
IDE drives can offer entirely acceptable performance, although for a serious performance system or server, one would of course use SCSI drives or a RAID array. But it's definitely possible to use IDE drives with 64 bit systems.
"Some 16 and 32 bit code will recompile cleanly. I expect much more will not."
If AMD specifies the standard LP-64 programming model (longs and pointers are 64 bits, ints are 32 bits), I would expect a significant majority of the non-Windows software to compile relatively cleanly on the Sledgehammer (or other 64 bit processor). Most Windows software unfortunately won't, because of some poor assumptions built into MFC and standard Windows programming techniques that I won't go into here (specifically the assumption that sizeof(int)==sizeof(int *)==sizeof(long)).
Evaluating processor performance is not just a matter of multiplying (function units*data size*clock speed). Many issues need to be considered for advanced, out-of-order, superscalar processors, including decoder width, cache structure, branch prediction techniques, reorder buffers, pipeline depth, mispredict penalties, and base instruction set. Sledgehammer will probably come close, if not slightly surpass, current 21264 integer performance, but will fall somewhat short of FP performance. However, by the time that Sledgehammer does come out, 21264b (first in a hybrid.18/.25 process, then completely migrated to.18 micron design rules) will almost certainly have clock speeds comparable to the Sledgehammer; the EV68 will blow just about every commodity chip (ie. excluding custom vector processors) out of the water in any performance metric.
The x86 ISA is so defective that any reasonable assembly programmer who has used any other ISA would rather gouge out his or her eyes with sharp pieces of bamboo rather than deal with the monstrosity that is x86. Any potential extention of the x86 ISA to 64-bits will take one of two forms, neither of which is neccesarily pleasant:
*An extended set of instructions (akin to MMX, 3dNow!, or SSE) that operate on 64-bit words and corresponding memory operations that load/store 64-bit words using an increased address speed. This option seems to be the one that AMD will most probably use, since they stress compatibility with the existing ISA to such a great extent in their PR. This is also the worse option: we will still be stuck with the essential garbage that underlies the x86 ISA: 2 operand instructions, a limited register set, nonorthogonality of the instruction set, and numerous other flaws.
*The processor boots to x86 compatibility mode, then requires an instruction to bring it into x86-64 mode. x86-64 mode is a sanely designed ISA that addresses and performs operations on 64-bit works. We lose the limitations of a tiny register set, horrible instruction encoding, and the other flaws of x86. This option would be far superior to the first one, but if one is willing to go to such lengths to distance oneself from the original x86 ISA (thereby losing all compatibility with native x86 applications in x86-64 mode), why not just migrate completely to a new ISA and use those wonderful fabs for new Alphas or Power4s and include a token K7 or P3 for x86 compatibility? BTW, this option almost resembles the rationale for the monstrosity that is IA-64...
Most troubling of all is that x86-64 may bring back segments. I cannot stress how horrible this would be; application programmers from the days of mixed 16/32-bit programming will agree with me. In any case, we have been stuck with this sickening, illogical, inelegant, and inefficient instruction set for the past 3 decades; do we really want to put up with another 3 decades of this crap? I say, kill off x86 for good and move to a sane architecture.
"How the power of this computer compares to that of Distributed.net or similar projects?": A comparison is not really possible. d.net can do more raw operations per second if one just adds up the total power of all the machines involved. However, ASCI White has far better internode communication. For the purposes of during highly paralizable calculations like distributed FFTs on blocked data and brute force sieving or key searches, d.net is probably faster. For the purposes of doing tasks like numerical linear algebra, nuclear/non-linear dynamics, weather forcasting, etc. ASCI White would be faster.
"How feasible is the distribution of such a computation? Are all the calculations similar, or would a lot of different computational code have to be written?": It would essentially be impossible to distribute the computational task, even if the intial value data could be distributed (and it can't; even simplier FEA simulations routinely have datasets exceeding 30 GB), the process would require so much internode communication that any d.net type system operating over a heterogenous, low-bandwidth, high-latency, public network like the Internet would never work.
"Are there any such systems already in place? Currently, I'm only aware of one "useful" system, and that's ProcessTree (damn, I lost my referral number). SETI@Home is arguably useful, depending on whether you believe there is extraterrestrial life that uses the same radio waves we're scanning and is sending signals we could interpret.": Not for using distributed computing for these kind of tasks.
No. The interactions between particles during the initial phases of a nuclear explosion are highly nonlinear and often not in local equilibrium. The interactions are orders of magnitude more complex than the gravitation force; there is no known way to recursively block and calculate aggregate forces and effects. Besides, the objective to simulate nuclear explosions from first principles means that the usual simplifying hueristics cannot be used; one cannot substitute simplier equations (if an explicit form even exists, which they usually don't) for the systems of differential equations that need to be solved.
Well, it's an IBM computer and I don't think IBM would really want to be using chips designed by SGI/MIPS. SGI has constructed ASCI Blue Mountain (a 3 teraflop machine) and has submitted a bid to build a 30 teraflop machine for the next phase of the ASCI program.
The OP's comment is utterly moronic. Solving ODEs and PDEs is a task perfectly well suited for a conventional computer. Quantum computers do *not* double their performance each time a single atom is added; not even when a single qubit is added to the device. Obviously, you are a troll or otherwise attempting to exploit the moderation system.
NO!!! The operating principles are as removed from a beowulf cluster as a bicycle from a car("Yes, they both have wheels, gears, and are made of metal."). The RS/6000s are not commercial off-the-shelf parts; they are substantially modified to allow greater internode communication bandwidth and lower backplane latency. The network switch for SMP (known as an interconnect) is orders of magnitude faster than even gigabit Ethernet; it is entirely custom built and accounts for a majority of the developement cost of the machine.
Most people who ramble on about NP have no clue what the N actually stands for. Your question has no real meaning in the sense that it asks about an attribute that is not associated with the question (rather like saying "How many doors are on the dog?"). The simulation is polynomial w.r.t the number of particles being simulated, but exponential w.r.t to the mesh granularity; it's entirely practical to approxiamate systems of non-linear differential equations to as much precision as one wants to wait for. In this case, a more powerful computer means that one only has to wait months instead of years to get results starting from physical first principles (instead of experimentally derived hueristics).
A good software developer uses the tools and platforms that best fit the task at hand, much as a good architect would use the materials that best suited the specific area of the building that he was designing. The person who posed the question stated that COM+ worked well and possessed many positive attributes; it considerably simplified the programming task, while not extracting any cost in stability. Obviously, COM+ works well for the application that the person was using it for. It is blatantly unprofessional to use an inferior product or tool when one already exists that performs the required task superbly; to do so smacks of bias and illogical prejudice based solely on the origin of a product that does not do justice to the needs of the consumer.
The OP is correct (and you've missed a rather subtle point). The OP said "It suffices to build a (roughly) square matrix containing the prefix of all the pads we wish to include in the analysis, run Gaussian elimination, and then see if there is a dependency with the file." The key word in that sentence is the word "square". Moreover, it is emminently possible to use more than just the 64 bit prefixes of the files; if one uses say 3,000,000 (where 3,000,000=the total number of pads), the total size of the matrix is well within the bounds of conventional techniques, to say nothing of SGE or BL/BC.
You see, a decent viewer can somethings actually correct this type of problem automatically. Considering the ammount of structure in image files, it's actually quite easy to build a reconstructor that will make the image passible.
Actually, the signature used in PNG/MNG is a *very* cool hack. By including both the LF and CR ASCII bytes, a properly constructed PNG/MNG decoder can determine whether or not the image file was misconverted as it passed through different computer systems than the one it was created in (ie. the file might have been sent in text mode by accident).
Why don't we give this a chance to mirror...
on
Mozilla M16 Released
·
· Score: 3
Just kidding of course (although I will note that Signal 11 posted a comment with this very topic to the story about the latest release of Mandrake and got moderated up to +5 (Insightful)). Anyway, not being a karma whore, I will be forced to confine myself to pertinent and ontopic postings. I downloaded M16 a couple of hours before the Slashdot story submission came through. It's *much* better than M14 (the last milestone that I've tried). As expected, the HTML rendering engine is fast and reasonably accurately displays most HTML documents, including the Slashdot home page. CSS support is a bit iffy around the edges, but this is well within acceptable limits (text styles are not always rendered consistently depending on window resizing details). The whole UI is a faster and more streamlined than in previous milestones, although I regret to say that it did crash 3 (three!) times the first time that I tried to start it up. A quick reboot later and it worked fine from there.
No. The asymtoptic speedup is still present; adding matrices is easy, but multiplying them is significantly harder. The method of matrix multiplication described recursively reduces the sizes of the matrices to be multiplied at the expense of more adds. For dimensions over 2000 or so on a modern computer, the improved method wins out.
Berlekamp's algorithm is useful for syndrome decoding, certain applied aspects of communication error detection protocols, and is closely related to the far more useful Berlekamp-Massey algorithm for determining the linear complexity of a bit sequence (used in Reed-Solomon ECCs). Besides, most cryptographic applications are out of reach of Berlekamp's original algorithm; one would need to use Shoup or the Hogland-Warfield probabilistic algorithms for that.
Here's my commentary on the some of the algorithms selected. I've included brief descriptions/references to further information where useful.
The Metropolis Algorithm for Monte Carlo: Based on the thermodynamic equivalent of crystals forming in cooling solids. As opposed to the naive optimization algorithm, the Metropolis algorithm sometimes allows a step to be taken even when it decreases the objective evaluation function with a probablity equal to the value of an exponentially decaying "entropy" function. _Numerical Recipes_ has a nice description, although their example is quite abysmal. The GNU Scientific Library (sourceware.cygnus.com/gsl) has an implementation of the algorithm, referred to as simulated annealing. ... The Fortran Optimizing Compiler: compiler techniques in general have improved enormously since the 1950s...this selection doesn't really make much sense to me, as this field has been more about continous and gradual improvement, whether than the developement of some breakthrough optimization techniques. If anything, the pioneering work of Zhang and Roberts establishing the computation infeasibilty of an "universal optimizer" is a much more interesting result. QR Algorithm for Computing Eigenvalues: Elegant method for determining the values for which A*x_i=\lambda\_i*x_i for a square matrix A. the eigenvalues and corresponding eigenvectors (the vectors belonging the the nullspace of (A-\lambda\_i*I)) are in a certain sense the natural frequencies of a matrix. Determining the eigenvalues without solving the characteristic polynomial (as with the QR method) is critical for avoiding numerical analysis problems.
Some notable algorithms which seem to be missing: -Sieving techniques for the decomposition of large composites into prime factors -RSA/other asymmetric key exchange algorithms -Huffman codes, LZ sliding-window compression techniques, arithmetic encoding -MDS matrices, error correction codes, cyclic redundancy checks -The linear feedback shift register -Predictor/corrector methods, adaptive numerical intergration and approximation of ODEs and PDEs -Lenstra-Lenstra-Lovasz lattice basis reduction algorithm -Berlekamp's Q-matrix algorithm for the factorization of polynomials
Slashdot Troll Warning System Version 0.2.290325-beta5-pre19438-xofdjcx0-patchlevel8 -------------------------------------------------- ---------------------------------- ****POTENTIAL TROLL DETECTED**** Heuristics matched: [x] Poster implied that Linux has problems OR poster does not use Linux [] Poster implied that {RMS, ESR, Linus, TC, Bruce Perens} is wrong [] Poster criticized {Andover.net, VA Linux, Cygnus, Redhat, other Linux company} [x] Poster criticized {Slashdot policies, story selection, CmdrTaco, RobLimo} [] Poster asserts that Signal 11 is {wrong, karma whoring} or moderates him down [x] Poster admits that he/she uses or approves of Microsoft/other closed source products [] Poster states that intellectual property laws are sometimes just [] Poster states that limits to free speech are sometimes just [] Poster notes that parent comment is uninsightful, banal, or incorrect [x] Poster made comment that angers Slashdot moderators Suggested countermeasure: [] Bitchslap (all posts changed to -1, your comments will start at -1, no moderation) [] Ban user from posting [] Ban IP address from posting [] Moderation as Overrated ("I don't agree with you. So there.") [x] Moderation as Off-topic ("I don't have a coherent rebuttal. But I can moderate down!") [x] Moderation as Troll ("I think the comment says bad things about the things I like")
Thank you for using the automated Slashdot Troll Warning System (STWS) Patent pending, copyright (c) 2000 by Andover.net Try to use our code without permission and we'll get our lawyers sue you
Bullshit. Do you even know what ROI means or are you trying to karma whore? ROI=Return On Investment. A ROI of zero is not a good thing. Another acronym that you should perhaps learn is TCO: Total Cost of Ownership. StarOffice and their ilk are free (as in beer), but the cost of actually training users, the cost of converting documents, dealing with support issues, compatibility problems, and other costs that are not immediately apparent will quickly drive the cost far above the actual price of the software. When purchased in bulk (ie. fulfillment/licensing), Office 2000 costs far less than the boxed version. Moreover, there are no good office suites for Linux that are open (StarOffice certainly isn't, nor is WordPerfect). They do not have well documented formats and I have no idea what their use has to do with "a network more in tune with the rest of the internet." The vast majority of a company's customers are likely to be using Office 2000 file formats: that is the de facto standard of the office enviroment. Your entire post seems like a quickly thrown together, illogical open-source party line post. I appreciate free software as much as the next person (I've used LaTeX for over a two decades), but there is a place for commercial software when no free software can fill its niche.
Signal 11 is just babbling as usual, although Shoeboy is technically correct. Nonetheless, if the judge has the authorized the use of electronic cease and desist notifications, it is usually not a good idea to refuse to comply, as this would invariably make the judge irritated. Needless to say, this is not highly recommended. Moreover, a motion for a change of venue is not as easy to obtain as you seem to suggest that it is. Generally speaking, you cannot force the court to change the venue across the country, especially if you are being sued in a state court. Attempting to do so would most likely bring more displeasure from the bench. Finally, I have no idea why you would consider it sticking it to them hard to "substitute the judge." The judge basically has the final decision on whether to recluse himself/herself or not, barring exceptional circumstances. Following Signal 11's advice is likely to produce little benefit for yourself and predispose the judge against you. Not a good idea.
By the way, as "someone who's been there, and done that", you seem spectecularly clue-impared. Have you ever actually tried what you are suggesting?
Slashdot Mirror
Nope. To quote from "Linux/IA64: Preparing for the Next Millenium" from "Proceedings of the 5th Annual Linux Expo":
"The user programming model is the standard LP64 moden meaning that the C data type "long" as well as pointers are 64-bit in size. This is the same model that has been adopted by all other Linux and UNIX 64-bit platforms in existence."
Moreover, "long long" is not in C99 (the latest ANSI C Standard); it is a gcc specific extention. The correct type should be "long long int"; this is guaranteed to be at least 64-bits. Most compilers will probably choose for this to be double the native word size (or 128-bit for 64-bit CPUs).
I read the referenced RealWorldTech article well before seeing this information on Slashdot, so I'll give a summary of Paul DeMone's conclusions, as well as my impression of why Sledgehammer was excluded.
.18/.25 process, then fully migrated to .18 design rules. The clock speed (especially after it's contracting out to IBM) will become competitive again. 21364 will add improved SMP capabilities (and an improved cache) to the basic EV6 core. The 21464 will be an impressive 8-issue processor with simultaneous multithreading.
*Alpha: The reigning champion of the 64-bit processors battlefield. The 21264a (EV67) shipping now still has the best integer and FP performance of any processor. The 21264b (EV68) will be released in two phases: first as a hybrid
*PA-RISC: HP has not neccesarily given up on its own processors, despite its nominal strategic alliance with Intel's IA64. An enormous cache allows the current members of this family to keep pace, even without significant architectural modifications. Later members could
*Itanium: A bloated instruction set that is incredibly ornate. Heavily dependent on compiler technology. Lots of marketing hype that exaggerates the true technical merit of the Merced processor. The Merced will debut at a relatively slow clock speed, but McKinley (HP's 2nd generation IA64 CPU) will definitely been a key competitor in the 64-bit HPC market.
*Sparc: Poor in performance, but software application support keeps these Sun processors alive. Even the not-yet-released UltraSparc 3 will have disappointing performance relative to modern processors.
*MIPS: Fading out.
*Power: The Power4 looks very impressive, but not much information has been released about it to this point.
The Sledgehamer is simply not a very interesting chip; it is generally agreed that x86 had the misfortune to become the most popular desktop ISA, without regard to its actual merits. An extention of x86 to 64-bits does not interest people much, essentially because of how ugly, inefficient, and inelegant the original x86 ISA is/was. Speaking for myself, I certainly do not want to have to put up with 30 more years of this defectiveness.
For existing x86 32-bit code, I expect the Sledgehammer to perform significantly better than the Merced in all respects (for equivalent clock speeds). For heavily numerical or scientific programming, I expect that the Merced will do better than the Sledgehammer, even with a significant clock speed differential (the Sledgehammer will probably release with a > 300 Mhz lead over the Merced). This is especially so for tasks such as encryption, large integer arithmetic, computational linear algebra, and certain other applications of this type. One must keep in mind that the Merced can potentially execute 2 bundles of 3 instructions each every clock cycle (and that some instructions can perform more than one operation on multiple operands); optimistically, Merced can perform something like 12 discrete operations every cycle (on full width words, no less). For general purpose applications(non-server, non-computational codes), before the IA64 compilers mature, I think that the Sledgehammer would do better.
No, the language specification is not affected by the underlying instruction set of the processor on which the code is compiled or executed (especially so for Java (or so I would hope), with its much vaunted platform independence). I do suppose that some vendors (if they have not yet done so already) would offer a compiler specific additional type, akin to the pre-C99 "long long" or "_int64" offered by gcc, VC++ respectively.
"Don't forget that you'll have to buy twice the RAM chips to get the same amount of memory (effectively.)"
Bullshit. The size of the base word will not affect the effective amount of memory, just the amount of memory that can be addressed. If you declare a 16-bit variable (probably a short, but ANSI makes no guarantees), it will occupy 16-bits, subject to alignment constraints.
"And programs will be about twice as large on your hard drive due to the 64 bit instruction words."
(Alpha) stage3-decompose.o: 213920 bytes
(x86) stage3-decompose.o: 264018 bytes
Here's a hint: 64 bit ISAs don't neccesarily use 64 bit instructions; the x86 ISAs variable length words take up as much (if not more) space than the fixed 32-bit words in more RISC-like ISAs.
"And there's no point in running a 64 bit system with IDE drives, so you'd best pick up some nice expensive SCSI drives, too."
IDE drives can offer entirely acceptable performance, although for a serious performance system or server, one would of course use SCSI drives or a RAID array. But it's definitely possible to use IDE drives with 64 bit systems.
"Some 16 and 32 bit code will recompile cleanly. I expect much more will not."
If AMD specifies the standard LP-64 programming model (longs and pointers are 64 bits, ints are 32 bits), I would expect a significant majority of the non-Windows software to compile relatively cleanly on the Sledgehammer (or other 64 bit processor). Most Windows software unfortunately won't, because of some poor assumptions built into MFC and standard Windows programming techniques that I won't go into here (specifically the assumption that sizeof(int)==sizeof(int *)==sizeof(long)).
Evaluating processor performance is not just a matter of multiplying (function units*data size*clock speed). Many issues need to be considered for advanced, out-of-order, superscalar processors, including decoder width, cache structure, branch prediction techniques, reorder buffers, pipeline depth, mispredict penalties, and base instruction set. Sledgehammer will probably come close, if not slightly surpass, current 21264 integer performance, but will fall somewhat short of FP performance. However, by the time that Sledgehammer does come out, 21264b (first in a hybrid .18/.25 process, then completely migrated to .18 micron design rules) will almost certainly have clock speeds comparable to the Sledgehammer; the EV68 will blow just about every commodity chip (ie. excluding custom vector processors) out of the water in any performance metric.
The x86 ISA is so defective that any reasonable assembly programmer who has used any other ISA would rather gouge out his or her eyes with sharp pieces of bamboo rather than deal with the monstrosity that is x86. Any potential extention of the x86 ISA to 64-bits will take one of two forms, neither of which is neccesarily pleasant:
*An extended set of instructions (akin to MMX, 3dNow!, or SSE) that operate on 64-bit words and corresponding memory operations that load/store 64-bit words using an increased address speed. This option seems to be the one that AMD will most probably use, since they stress compatibility with the existing ISA to such a great extent in their PR. This is also the worse option: we will still be stuck with the essential garbage that underlies the x86 ISA: 2 operand instructions, a limited register set, nonorthogonality of the instruction set, and numerous other flaws.
*The processor boots to x86 compatibility mode, then requires an instruction to bring it into x86-64 mode. x86-64 mode is a sanely designed ISA that addresses and performs operations on 64-bit works. We lose the limitations of a tiny register set, horrible instruction encoding, and the other flaws of x86. This option would be far superior to the first one, but if one is willing to go to such lengths to distance oneself from the original x86 ISA (thereby losing all compatibility with native x86 applications in x86-64 mode), why not just migrate completely to a new ISA and use those wonderful fabs for new Alphas or Power4s and include a token K7 or P3 for x86 compatibility? BTW, this option almost resembles the rationale for the monstrosity that is IA-64...
Most troubling of all is that x86-64 may bring back segments. I cannot stress how horrible this would be; application programmers from the days of mixed 16/32-bit programming will agree with me. In any case, we have been stuck with this sickening, illogical, inelegant, and inefficient instruction set for the past 3 decades; do we really want to put up with another 3 decades of this crap? I say, kill off x86 for good and move to a sane architecture.
"How the power of this computer compares to that of Distributed.net or similar projects?":
A comparison is not really possible. d.net can do more raw operations per second if one just adds up the total power of all the machines involved. However, ASCI White has far better internode communication. For the purposes of during highly paralizable calculations like distributed FFTs on blocked data and brute force sieving or key searches, d.net is probably faster. For the purposes of doing tasks like numerical linear algebra, nuclear/non-linear dynamics, weather forcasting, etc. ASCI White would be faster.
"How feasible is the distribution of such a computation? Are all the calculations similar, or would a lot of different computational code have to be written?":
It would essentially be impossible to distribute the computational task, even if the intial value data could be distributed (and it can't; even simplier FEA simulations routinely have datasets exceeding 30 GB), the process would require so much internode communication that any d.net type system operating over a heterogenous, low-bandwidth, high-latency, public network like the Internet would never work.
"Are there any such systems already in place? Currently, I'm only aware of one "useful" system, and that's ProcessTree (damn, I lost my referral number). SETI@Home is arguably useful, depending on whether you believe there is extraterrestrial life that uses the same radio waves we're scanning and is sending signals we could interpret.":
Not for using distributed computing for these kind of tasks.
You need internode bandwidth and low communications latency; this type of simulation can only be done with a large, monolithic memory space machine.
No. The interactions between particles during the initial phases of a nuclear explosion are highly nonlinear and often not in local equilibrium. The interactions are orders of magnitude more complex than the gravitation force; there is no known way to recursively block and calculate aggregate forces and effects. Besides, the objective to simulate nuclear explosions from first principles means that the usual simplifying hueristics cannot be used; one cannot substitute simplier equations (if an explicit form even exists, which they usually don't) for the systems of differential equations that need to be solved.
Well, it's an IBM computer and I don't think IBM would really want to be using chips designed by SGI/MIPS. SGI has constructed ASCI Blue Mountain (a 3 teraflop machine) and has submitted a bid to build a 30 teraflop machine for the next phase of the ASCI program.
The OP's comment is utterly moronic. Solving ODEs and PDEs is a task perfectly well suited for a conventional computer. Quantum computers do *not* double their performance each time a single atom is added; not even when a single qubit is added to the device. Obviously, you are a troll or otherwise attempting to exploit the moderation system.
NO!!! The operating principles are as removed from a beowulf cluster as a bicycle from a car("Yes, they both have wheels, gears, and are made of metal."). The RS/6000s are not commercial off-the-shelf parts; they are substantially modified to allow greater internode communication bandwidth and lower backplane latency. The network switch for SMP (known as an interconnect) is orders of magnitude faster than even gigabit Ethernet; it is entirely custom built and accounts for a majority of the developement cost of the machine.
Most people who ramble on about NP have no clue what the N actually stands for. Your question has no real meaning in the sense that it asks about an attribute that is not associated with the question (rather like saying "How many doors are on the dog?"). The simulation is polynomial w.r.t the number of particles being simulated, but exponential w.r.t to the mesh granularity; it's entirely practical to approxiamate systems of non-linear differential equations to as much precision as one wants to wait for. In this case, a more powerful computer means that one only has to wait months instead of years to get results starting from physical first principles (instead of experimentally derived hueristics).
A good software developer uses the tools and platforms that best fit the task at hand, much as a good architect would use the materials that best suited the specific area of the building that he was designing. The person who posed the question stated that COM+ worked well and possessed many positive attributes; it considerably simplified the programming task, while not extracting any cost in stability. Obviously, COM+ works well for the application that the person was using it for. It is blatantly unprofessional to use an inferior product or tool when one already exists that performs the required task superbly; to do so smacks of bias and illogical prejudice based solely on the origin of a product that does not do justice to the needs of the consumer.
The OP is correct (and you've missed a rather subtle point). The OP said "It suffices to build a (roughly) square matrix containing the prefix of all the pads we wish to include in the analysis, run Gaussian elimination, and then see if there is a dependency with the file." The key word in that sentence is the word "square". Moreover, it is emminently possible to use more than just the 64 bit prefixes of the files; if one uses say 3,000,000 (where 3,000,000=the total number of pads), the total size of the matrix is well within the bounds of conventional techniques, to say nothing of SGE or BL/BC.
You see, a decent viewer can somethings actually correct this type of problem automatically. Considering the ammount of structure in image files, it's actually quite easy to build a reconstructor that will make the image passible.
Actually, the signature used in PNG/MNG is a *very* cool hack. By including both the LF and CR ASCII bytes, a properly constructed PNG/MNG decoder can determine whether or not the image file was misconverted as it passed through different computer systems than the one it was created in (ie. the file might have been sent in text mode by accident).
Just kidding of course (although I will note that Signal 11 posted a comment with this very topic to the story about the latest release of Mandrake and got moderated up to +5 (Insightful)). Anyway, not being a karma whore, I will be forced to confine myself to pertinent and ontopic postings. I downloaded M16 a couple of hours before the Slashdot story submission came through. It's *much* better than M14 (the last milestone that I've tried). As expected, the HTML rendering engine is fast and reasonably accurately displays most HTML documents, including the Slashdot home page. CSS support is a bit iffy around the edges, but this is well within acceptable limits (text styles are not always rendered consistently depending on window resizing details). The whole UI is a faster and more streamlined than in previous milestones, although I regret to say that it did crash 3 (three!) times the first time that I tried to start it up. A quick reboot later and it worked fine from there.
No. The asymtoptic speedup is still present; adding matrices is easy, but multiplying them is significantly harder. The method of matrix multiplication described recursively reduces the sizes of the matrices to be multiplied at the expense of more adds. For dimensions over 2000 or so on a modern computer, the improved method wins out.
Berlekamp's algorithm is useful for syndrome decoding, certain applied aspects of communication error detection protocols, and is closely related to the far more useful Berlekamp-Massey algorithm for determining the linear complexity of a bit sequence (used in Reed-Solomon ECCs). Besides, most cryptographic applications are out of reach of Berlekamp's original algorithm; one would need to use Shoup or the Hogland-Warfield probabilistic algorithms for that.
Here's my commentary on the some of the algorithms selected. I've included brief descriptions/references to further information where useful.
...
The Metropolis Algorithm for Monte Carlo: Based on the thermodynamic equivalent of crystals forming in cooling solids. As opposed to the naive optimization algorithm, the Metropolis algorithm sometimes allows a step to be taken even when it decreases the objective evaluation function with a probablity equal to the value of an exponentially decaying "entropy" function. _Numerical Recipes_ has a nice description, although their example is quite abysmal. The GNU Scientific Library (sourceware.cygnus.com/gsl) has an implementation of the algorithm, referred to as simulated annealing.
The Fortran Optimizing Compiler: compiler techniques in general have improved enormously since the 1950s...this selection doesn't really make much sense to me, as this field has been more about continous and gradual improvement, whether than the developement of some breakthrough optimization techniques. If anything, the pioneering work of Zhang and Roberts establishing the computation infeasibilty of an "universal optimizer" is a much more interesting result.
QR Algorithm for Computing Eigenvalues: Elegant method for determining the values for which A*x_i=\lambda\_i*x_i for a square matrix A. the eigenvalues and corresponding eigenvectors (the vectors belonging the the nullspace of (A-\lambda\_i*I)) are in a certain sense the natural frequencies of a matrix. Determining the eigenvalues without solving the characteristic polynomial (as with the QR method) is critical for avoiding numerical analysis problems.
Some notable algorithms which seem to be missing:
-Sieving techniques for the decomposition of large composites into prime factors
-RSA/other asymmetric key exchange algorithms
-Huffman codes, LZ sliding-window compression techniques, arithmetic encoding
-MDS matrices, error correction codes, cyclic redundancy checks
-The linear feedback shift register
-Predictor/corrector methods, adaptive numerical intergration and approximation of ODEs and PDEs
-Lenstra-Lenstra-Lovasz lattice basis reduction algorithm
-Berlekamp's Q-matrix algorithm for the factorization of polynomials
Slashdot Troll Warning System Version 0.2.290325-beta5-pre19438-xofdjcx0-patchlevel8- ----------------------------------
-------------------------------------------------
****POTENTIAL TROLL DETECTED****
Heuristics matched:
[x] Poster implied that Linux has problems OR poster does not use Linux
[] Poster implied that {RMS, ESR, Linus, TC, Bruce Perens} is wrong
[] Poster criticized {Andover.net, VA Linux, Cygnus, Redhat, other Linux company}
[x] Poster criticized {Slashdot policies, story selection, CmdrTaco, RobLimo}
[] Poster asserts that Signal 11 is {wrong, karma whoring} or moderates him down
[x] Poster admits that he/she uses or approves of Microsoft/other closed source products
[] Poster states that intellectual property laws are sometimes just
[] Poster states that limits to free speech are sometimes just
[] Poster notes that parent comment is uninsightful, banal, or incorrect
[x] Poster made comment that angers Slashdot moderators
Suggested countermeasure:
[] Bitchslap (all posts changed to -1, your comments will start at -1, no moderation)
[] Ban user from posting
[] Ban IP address from posting
[] Moderation as Overrated ("I don't agree with you. So there.")
[x] Moderation as Off-topic ("I don't have a coherent rebuttal. But I can moderate down!")
[x] Moderation as Troll ("I think the comment says bad things about the things I like")
Thank you for using the automated Slashdot Troll Warning System (STWS)
Patent pending, copyright (c) 2000 by Andover.net
Try to use our code without permission and we'll get our lawyers sue you
Bullshit. Do you even know what ROI means or are you trying to karma whore? ROI=Return On Investment. A ROI of zero is not a good thing. Another acronym that you should perhaps learn is TCO: Total Cost of Ownership. StarOffice and their ilk are free (as in beer), but the cost of actually training users, the cost of converting documents, dealing with support issues, compatibility problems, and other costs that are not immediately apparent will quickly drive the cost far above the actual price of the software. When purchased in bulk (ie. fulfillment/licensing), Office 2000 costs far less than the boxed version. Moreover, there are no good office suites for Linux that are open (StarOffice certainly isn't, nor is WordPerfect). They do not have well documented formats and I have no idea what their use has to do with "a network more in tune with the rest of the internet." The vast majority of a company's customers are likely to be using Office 2000 file formats: that is the de facto standard of the office enviroment. Your entire post seems like a quickly thrown together, illogical open-source party line post. I appreciate free software as much as the next person (I've used LaTeX for over a two decades), but there is a place for commercial software when no free software can fill its niche.
Signal 11 is just babbling as usual, although Shoeboy is technically correct. Nonetheless, if the judge has the authorized the use of electronic cease and desist notifications, it is usually not a good idea to refuse to comply, as this would invariably make the judge irritated. Needless to say, this is not highly recommended. Moreover, a motion for a change of venue is not as easy to obtain as you seem to suggest that it is. Generally speaking, you cannot force the court to change the venue across the country, especially if you are being sued in a state court. Attempting to do so would most likely bring more displeasure from the bench. Finally, I have no idea why you would consider it sticking it to them hard to "substitute the judge." The judge basically has the final decision on whether to recluse himself/herself or not, barring exceptional circumstances. Following Signal 11's advice is likely to produce little benefit for yourself and predispose the judge against you. Not a good idea.
By the way, as "someone who's been there, and done that", you seem spectecularly clue-impared. Have you ever actually tried what you are suggesting?