The great thing about RC5 is that it is parameterizable. One of the parameters is the machine word size, which can and will be changed from 32 to 64 bits when 64-bit CPUs become commonplace. In fact, Ronald Rivest wrote the following on his original paper on RC5: ``as 64-bit processors become available, it should be possible for RC5 to exploit their longer word length.'' The 64-bit transition also means the cipher's block size is upped to 128 bits, which is considered a Good Thing(TM) by cryptographers.
However, the current RSA Secret Key Challenges have, indeed, fixed machine word size at 32 bits and will not benefit from 64-bit processors.
I feel the same way -- every written test I had to take, I was proficient on the underlying theory, and would be able to code it in front of a computer. Most of the time I miss the 100% grade due to an off-by-one error, or an `if' clause testing the exact opposite of what I intended to. These sort of errors are easily spotted if you have a computer to aid in debugging, and that's why I believe coding tests should be done on a computer, period. Especially with students unfamiliar with the mechanics of coding -- after a few years of daily coding, a person seldom commits these silly errors.
As a side note, having learned touch typing, it's really hard to write on paper. Thoughts flow much faster than handwriting, and you end up losing yourself sometimes. I'm positive that also affects other coders when doing written tests.
Written properly, Maxwell's equations would be still be valid with relativistic effects.
Maxwell's equations are valid regardless of relativity, in the same form they were laid down by James Clark Maxwell in the 19th century.
In fact, the importance of Einstein's contribution was changing Newtonian mechanics to comply with some of the strange consequences of Maxwell's equations, such as the constancy of the speed of light. So physics had to adapt to Maxwell's equations, not the other way around.
Although many people discuss the superiority of the SCSI protocol vs. the IDE protocol, this is not really the question.
Manufacturers produce the fastest disks on the planet on SCSI interfaces only. There are no 10K/15K RPM IDE discs, period. If one wants the lowest access time available today coupled with respectable transfer rates, one must purchase a 15K RPM drive, which are only available in SCSI interfaces.
For single-user access patterns, the author is correct to state that IDE drives have the lead today. StorageReview.com recently reviewed the latest 7200 RPM Seagate SCSI offering, and it was beaten down in single user tests by half a dozen of the newer IDE drives; however, when tested with server access patterns, it was the clear leader (excluding higher-RPM offerings, of course.) Still, 7200 RPM drives can't beat 15K RPM drives in any access pattern.
And I noticed the author was RAIDing drives -- 3ware's RAID products are very high quality, and their performance exceeds each and every other RAID card out there, SCSI or IDE interface. That surely contributed to his conclusion that current IDE drives are faster than their SCSI counterparts.
Yes, a one-time pad is unbreakable in an information-theoretic sense. However, there are few ciphers today capable of being broken by brute force. Most attacks are directed at protocols and other security problems.
For all practical purposes, 128-bit symmetric key ciphers are as unbreakable as an OTP, even to the three-letter organizations, but without the pratical problems associated to the OTP.
Quantum cryptography comes to extend ``nearly-unbreakable'' crypto even further. From the looks of it, the usage of OTPs will decrease due to quantum crypto, even if it isn't unbreakable.
Wrong. Java is compiled to an intermediate representation (bytecode), and later translated to the machine's native instructions by means of the JVM. Reverse engineering the bytecode is every bit as hard as reverse engineering ordinary assembly code for any processor.
First, an ICQ-style notification list. That alone, although it only depends on a client mod, would be great.
Second, in IRC, you can never be sure you're talking to the right person. The nick might have been hijacked or something. Having a central database of nicknames would solve the problem. Yeah, there's NickServ, but it's also a hack -- IRC needs an integrated authentication service.
Plus, people won't be using text interfaces for long. Once there's bandwidth enough, people are going to use voice and video, and save by a dirty hack IRC can't expand into that. Any IRC-replacing protocols must expand easily and cleanly -- you can't tell what the future holds for more efficient means of communication.
Being able to authorize people to go into your notify list or not is also a desirable feature for some.
I don't want to turn IRC into ICQ. I want to grab the best of both worlds into a single application, with the addition of cryptography and network scalibility enhacements.
You can't simply fix a broken protocol by tunneling it over a secure connection. IRC wasn't made with security in mind, and it shows. Stunnel is no more than a temporary and very dirty hack, until something better shows up. That might be SILC, or this project I've started along with a few other IRC addicts: CIRCUS.
Then there's other fixes regarding network scalibility, for instance. And don't forget the boom of IM in the last few years, which has shown quite a few features which IRC is lacking, and an updated protocol might take a shot at improving user experience, going way beyond what IRC can offer.
I second that absolutely. I only listen to music in my computer, I don't have a standalone CD player. Taking away demo/bootlegged live songs from my playlist (I wouldn't be able to buy them on a CD anyway), I'm left with no more than 6 hours of MP3s in here. The rest of my music collection, I usually have downloaded the MP3 first, figured the band was good, and bought a CD or DVD. Right now I own 100 records, split 5:1 between CDs and DVDs respectively (mostly purchased in the last 3 or 4 years -- I dumped my previous CDs by that time, although I had at least a hundred of them also.)
But, apparently, the record companies are forcing me to download MP3s only from now on. I'd rather have the higher sound quality found in a CD, and the nice cover and booklets, but oh well, I'm being forced into this.
To start off, there's an error in your question. There's no such thing as ``the IA-64 CPU.'' IA-64 is the instruction set architecture behind Itanium and the around-the-corner McKinley, and while I could list all the features and shortcomings behind it, it'd be a boring and technical explanation.
You can jump to conclusions, if you wish, by looking at Ace's HardwareSPECmine database, which contains all current SPEC2000 results. In case you don't know, those are the industry standard benchmarks. Here is a sample query of the SPEC2000 integer benchmarks, and here is a sample query of floating point results. As you can see, there are always better choices than the Itanium, and mostly from vendors who have been in the field of 64-bit processors for long, and probably with better prices too. You can never underestimate how important vendor reputation and experience is.
I alluded to the shortcomings of the instruction set of Intel's 64-bit offerings. Indeed, the poor performance can mostly be attributed to it (although the Itanium's poor design has helped a lot -- let's see whether McKinley fares better.) The truth is, Intel took VLIW and redressed it as EPIC; but VLIW has never been a panacea. Serial designs with out of order execution have been around longer, and worked great. The Itanium is a strict in-order processor, and the SPECint results show. And compiler technology isn't there yet; but Intel has acquired Alpha from Compaq and employed their compiler and MPU design team, widely reputed as the best in the field. Whether clever design will be able to mend the instruction set flaws, only time will tell. Indeed, the best strategy now is to wait a few years; seeing as how hardly a thousand Itanium system were actually purchased and paid for, most people seem to be taking this route. With McKinley the situation will be better for Intel, but not until the 3rd or 4th generation will the mass purchases begin, if ever.
Another common misconception is about the performance of Sun hardware. Just look at the values linked above from the SPEC benchmarks. Sun is known for scalable, reliable hardware, stuff you can depend on. But they're not the best performers by any account. The best designs come, undoubtedly, from the Alpha team; the upcoming EV8 would be the most advanced processor for a long time to come, if it weren't for Intel (who cancelled the EV8 project, obviously.) Unfortunately, Alpha is no longer a good buy, though not by technical merits. Having a vendor who will vanish sometime in the future is never a good strategy. Luckily, IBM's POWER series and HP-PA still remain, although the Precision Architecture will be discontinued some time in the future as well. IBM's Power4 design is the current king of the hill in SPEC scores, beating the closest competitors by a fair amount.
Finally, a great source of information is the Real World Tech forum, and the ``Silicon Insider'' columns by Paul DeMone, on the same website. (Paul also regularly reads the forum, and posts quite frequently too.)
You're mixing things up. OTPs are unconditionally secure. Shannon (in `Communication Theory of Secrecy Systems', 1949) has proven that unconditionally secure systems require keys as lenghty as the message itself, but OTOH an adversary cannot gleam anything about the plaintext given the ciphertext. One such example is the Vernam cipher, which represents the message and the key as a stream of bits, and XORs them together to generate the ciphertext.
Provably secure cryptosystems are those who have been proven to be as hard as the underlying hard problem, such as the Rabin cryptosystem, which is provably as hard as the integer factorization problem. In fact, it is based on the `square roots of modular numbers' problem, which has been proven to be computationally equivalent to integer factorization.
Ok, Mr. Know-it-all. Here's all the evidence I could gather for you. I really don't know why I spent so much time responding to an obvious troll, but it seems the moderators don't agree with me.
I hope that you realize, by the end of this post, that you shouldn't comment on subjects you have no clue about. Even worse, in this case, you have the wrong `clues'. You managed to squeeze a lot of stupid and wrong stuff in a few lines, and you seem to stick to you. So here goes:
Factoring is the underlying, presumably hard problem upon which several public-key cryptosystems are based, including the RSA algorithm. (...) It has not been proven that factoring must be difficult, and there remains a possibility that a quick and easy factoring method might be discovered, though factoring researchers consider this possibility remote.
Oh, then you must be wrong somewhere, OK? I know exactly where. Here's from the book ``Algorithms and Complexity'', by Herbert Wilf:
The problem is this. Let n be a given integer. We want to find out if n is prime. The method that we choose is the following. For each integer m = 2,3,..., floor(sqrt(n)) we ask if m divides (evenly into) n. If all of the answers are `No,' then we declare n to be a prime number, else it is composite.
OK, so as a primality testing algorithm, it is rather inefficient. The Jacobi sum test and Atkin's test have a much better asymptotic growth, but if you look at it, you can use the same procedure to factor numbers.
We will now look at the computational complexity of this algorithm. That means that we are going to find out how much work is involved in doing the test. For a given integer n the work that we have to do can be measured in units of divisions of a whole number by another whole number. In those units, we obviously will do about sqrt(n) units of work.
See? Your O(n) algorithm (O(n) according to your stupid notation) is already a slow one. There are much faster algorithms out there than trial division. You should be realizing, by now, that you are beyond clueless, but here's the finishing touch:
It seems as though this is a tractable problem, because, after all, n is of polynomial growth in n. For instance, we do less than n units of work, and that's certainly a polynomial in n, isn't it? So, according to our definition of fast and slow algorithms, the distinction was made on the basis of polynomial vs. faster-than-polynomial growth of the work done with the problem size, and therefore this problem must be easy. Right? Well no, not really.
Reference to the distinction between fast and slow methods will show that we have to measure the amount of work done as a function of the number of bits of input to the problem. In this example, n is not the number of bits of input. For instance, if n = 59, we don't need 59 bits to describe n, but only 6. In general, the number of binary digits in the bit string of an integer n is close to (log n)/(log 2).
If we express the amount of work done as a function of B; we find that the complexity of this calculation is approximately 2**(B/2) , and that grows much faster than any polynomial function of B.
Satisfied there? Great. Now, if this book isn't enough for you, go out there and try to find another book which contradicts this one. And no, Teach Yourself Algorithms in 21 days, or something along these lines, doesn't count. Which seems to be your source of information; otherwise you'd have refrained from posting this.
Now, for the really stupid part:
The reason cryptosystems based on factorization are thought to be safe is because we can choose arbitrarily large values of n and we presume that there is no more efficient way to factor integers.
This shows how you have no understanding of asymptotics, or the general field of complexity of algorithms. Refer to the introduction of any good book on the matter, and you'll realize how wrong you are.
If that's not a good example, do some research on calculating Pi, for instance. You'll soon realize that the bottleneck for those computations is a means to do fast multiplication, and it can be done today in better than O(n log n) time (this particular value is the growth for the FFT-based methods.) But still, it can't be done yet in O(n) time, and it has been proven that this O(n) is the theoretical floor for a multiplication algorithm. So, it can't possibly do better than factorization, correct? But how come I can calculate a couple billion digits of Pi on my computer, while I can't factorize even a 100-digit number? In fact, I think I could hardly factorize an 80-digit number in the same amount of time it takes for calculating these billions of digits of Pi. (And it makes sense that algorithms for factorization are researched far more frequently than algorithms for Pi-calculation.)
Now, if you haven't convinced yourself, there's nothing more I can offer. I just hope the moderators read this post and mod you down into -1.
Now, if someone were to find a way to factor integers faster than O(n), we could still keep increasing n but that alone might not be sufficient.
I have shown you one such algorithm above. Did this change the world? No. And it is still a very slow algorithm by today's standards. Oh, and did I mention that it was invented by the greek mathematician Erathostenes, a few millenia ago? You should rethink about posting every idiot idea that comes out of your head from now on; at least avoid a complete embarassment by looking up whether you've been wrong for thousand of years.
Now, I was about to moderate this post down, but I find that the moderation choices are highly non-orthogonal. Where is the `incorrect' moderation option? Or `clueless poster' option? And even better, what about leaving a small space for the moderator to explain why he modded as such?
I say this because most of the/. crowd (as shown by the high score of the parent post) doesn't understand shit about the subject, so they moderate it up, and would metamoderate a clued in moderation (that is, one which detracted points from the post) as `unfair'.
My opinion is: if you don't understand the subject, restrict yourself to moderating and metamoderating the `funny' posts. And, even better, don't post. The S/N ratio is already too low with all the crapflooding, and downright wrong posts are even worse, since only knowledgeable people can moderate it up. Which isn't happening, as the parent post shows.
Although the x86 ISA is serial in nature, processors starting with the Pentium were superscalar (that is, were able to execute more than one instruction per clock cycle), and since the Pentium Pro/II/III were capable of out of order execution.
The difference between the original code and my code is simple. Unless the branch can be easily predicted, this code will take (worst case scenario) something from 12 cycles (on the Athlon) to 22 cycles (on the P4.) We're only taking into account the delay caused by pipeline flushing. In fact, his code was also not aligned to a particular boundary (say, addresses divisible by 16.) This might incur penalties as well.
My code, on the other hand, will execute in 2 cycles, since the first two instructions are paired in about any superscalar processor (see? My code runs in parallel as well. That's not an Itanium-only feature; in fact, you might even say that Itanium's hardwired implementation of parallelism is rather poor.) But I digress. My point was, I didn't study the IA-64 documentation, and if this is the only situation where I can avoid branches, than I need not drift away from x86; there I can avoid these sorts of branches already.
As for MOV EAX, 0 vs. XOR EAX, EAX, while both accomplish the same goal at the same speed, the former instruction is encoded into 5 bytes, while the latter is encoded into a single byte. If you're optimizing tight loops, this might really make a difference.
64-bit CPUs will be faster at a few things, like copying memory and crunching RC5,
Sorry buddy, but you're wrong.
Taking an example from the x86 world: since the Pentium MMX, there exists the ability to copy memory in 64-bit chunks, using the MMX instructions. The Pentium 4 adds SSE2 instructions into the mix, being able to address data in 128-bit chunks, plus some ``Cacheability Control'' instructions. These hint the processor on the nature of the data, so it can handle caching better. (Although some PREFETCH instructions, found e.g. in the Athlon, already have some of these capabilities.) In the end, a ``plain'' 64-bit processor can't possibly use memory bandwidth as efficiently as these 32-bit designs shown above.
Now for the issue of RC5. First, I assume you're talking about the distributed.net client. (The RC5 cypher itself is parameterizable, so this discussion might not apply to real-life RC5 implementations.) I do have some knowledge on this area, and I can assure you, 64-bit will only slow down RC5 implementations, when the word size parameters are specified at 32 bits. Which, BTW, is the value set by RSA on all their Secret Key Challenges, this being the stuff distributed.net is cracking.
This is mostly related to the fact that arithmetic must be done modulo 2**32, and this cannot be done effectively with 64-bit instructions. With ADD instructions, that's fairly easy -- just mask out the 32 most significants bits, i.e. AND REG, 0x00000000FFFFFFFF (still, you're executing an ``useless'' instruction, as in ``unrelated to the algorithm at hand'', and which will slow you down.) However, RC5 relies heavily on rotation instructions, and unless the ISA in question allows for working with 32-bit chunks of registers, we're back to the slow {shift left by n, shift right by 32-n, OR} procedure. Again, that's not a flaw in the algorithm -- it allows you to specify many parameters, word size being one of them, and RSA picked 32-bit in their contests.
You are. That's my biggest grip with your post (that, and your downplaying of AMD's x86-64 architecture.) The guy asked about the advantages of 64-bit computing in general. In particular, he didn't ask for features specific to a single architecture. None of the features you talked about couldn't be implemented on a 32-bit processor, or an 8-bit microcontroller for that matter. Based on that, your post is completely off-topic and should be moderated accordingly.
Mind you, I might stop here, but I do have some other problems with your post.
Heavy use of ILP (Instruction Level Parallelism) - speaks for itself.
SPEC results also speaks for themselves, and louder.
You don't need to tell me that the Itanium crushes everyone else in floating point applications in a clock-for-clock comparison. That makes it great for scientific computations, but what about everything else? (Nobody's playing Quake on a multi-thousand-dollar CPU.) Still, the 1 GHz Alpha 21264 is 11% faster than the 800 MHz Itanium on SPECfp, and even the newest P4s beat Itanium in this benchmark. While, of course, completely trashing it in the integer benchmarks. Seeing as how Itanium can't scale either, it won't regain the performance crown soon, if ever.
Predication - less branches taken and hence stalling. The conditional handling is done through a controlling predicate, rather than jumping. look at this C code:
There are enough examples out there that show the x86 in a bad light in this regard, however, you didn't choose one. A real programmer would rather write:
Just as fast as your code, cycle-wise. Note: a 2 GHz processor has a 2.5x smaller cycle time than an 800 MHz processor.
(The above code only runs on 6th+ generation processors, and requires VALUE[A-B] to be stored in registers; not a problem, I'd say.)
I really wished to debunk the rest of your points, but I've got better stuff to do. Not that I think those were the only flaws on your post.
Face it, Itanium is doomed. McKinley will be the first IA64 processor to be taken seriously. Particular implementations notwithstanding, it's a flawed architecture. VLIW has proved NOT to be a panacea, while OOO, which has proven time and again to work, was laughed at by the Intel PR machine. Now, with benchmarks available, they're just reaping the bitter results of their strategy.
Finally, the fact that ``[t]he Hammer series processors are really just an x86 extension'' is, in fact, its most advertised feature, and you didn't seem to have gotten it. Only time will tell whether AMD will succeed, and most factors are outside of AMD's control (and quite a bit of those are non-technical.) If Intel didn't have as much power as it does, hardly would the Itanium suceed in the marketplace. But then again, Sun hardware has always been a bad performer; technical factors do not play a major role in market economics, apparently.
I'm 101% positive you didn't read the article, since they mention (in the third paragraph of the first page) that their drive is an IBM UltraStar 36LP. Although I'm not familiar with this specific unit, UltraStars are IBM's SCSI offerings.
If you have no resources for purchasing scientific software, where did you get the money for purchasing MS Windows licenses?
Moderators: THIS IS NOT A TROLL. The question is simple: if you're already w4r3zing Windows, what refrains you from w4r3zing your scientific software also, and in the process saving us from these terrible Ask Slashdots of late?
Forgot to mention in my previous comment -- this onboard RAID featured in your motherboard, whatever manufacturer it may be, is not equivalent to a real RAID board with a microprocessor inside, which offloads all the processing. Imagine Winmodem -- all processing is done on the host. Of course a modem's work isn't as CPU intensive as the RAID work, but the data rate here is of a few megabytes per second. You will end up paying with your memory bandwidth too. If you're going the RAID way, try to avoid these ``WinRAID'' controllers; buy a 3ware instead, or perhaps an Adaptec.
Apparently, the guy who asked the question was looking to strip his drives in a RAID 0 configuration. This config won't add reliability at all, and in fact will decrease it proportionally to the amount of drives used: a single drive fails, you lose all your data. ALL OF IT, let that be clear. No going back. And this factor is increasingly more important in these days of the Deskstar 75GXP.
However, RAID 5 (which is what I believe you refer to) can indeed add reliability, but at a price: one of your disks' worth of space is ``wasted'', and drive performance can decrease along with an increase in CPU usage, unless you have a high quality controller.
Of course, RAID 0's twice as high likelihood of failure may not be all that important if you're only storing your MP3s, but keep it in mind if you're storing important data on it.
In terms of throughput, yes, you'll get about the same performance. However, unless you spend all day loading large files from a completely defragmented partition, what you should really look for is reduced seek times. This is the bottleneck when doing 99% of the work in your computer -- and that's why solid state drives are so blazingly fast, despite having an inferior throughput than their mechanical counterparts: they have smaller seek times, by many orders of magnitude.
Smaller seek times can be achieved by various means:
1. Get a high-end drive. More expensive models feature faster actuators.
2. Reduce the physical area the disk can access, by partitioning accordingly. Seagate also used this trick with their first-gen X15 drive, by reducing the platter size from 3" to 2.5", and they were very successful.
3. Use RAID 1 (mirroring) with a good controller, which for IDE basically means the 3ware models. They are, far and away, the best. Besides shaving off the seek times, they also improve the throughput.
4. And, of course, the most important: get a hard drive which spins faster. If you don't believe me, take a look at the sites below for benchmarks.
The hard drive is the only peripheral nowadays whose access time is measured in miliseconds and not nanoseconds. Instead of buying loads of memory and the fastest processor available, everyone should pay attention to the storage side of their machines -- whoever has experienced 10k and 15k RPM disks finds it hard to go back.
The best places in the web for storage info are Storage Review and, to a lesser extent, x-bit labs. Storage Review, besides their extremely scientific methodologies, maintains a drive reliability database, so you can check whether the drive you're looking for is likely to fail.
You should leave the language choice up to the students. Someone who picks C to do pattern matching and string operations instead of Perl deserves the buggy code they'll get (and the time they'll waste). Actually, this will end up enriching the contest, so far as students who learned more than one language will be able to pick the one best suited to the task at hand, a skill which can make or break a good design.
For that to happen, first those two processors must be in the same market segment. Do you see people using Alphas switching to x86? The same way, Itanium's market is not the desktop or average workstation. They're trying to compete with the cream of the crop RISC chips.
Rants aside, the Hammer architecture is a nice way to transition to 64-bit computing while keeping legacy code, no rewriting or even recompiling. But it has a cost: it'll carry the same inefficiencies found in current CISC processors. While many designers have found their way around it in the performance arena, the drawbacks are evident: higher complexity, power dissipation, etc. -- die size is unevenly divided between control logic and number-crunching logic, which isn't a comfortable situation.
Take the time to generate assembly code using gcc -S, and you'll soon find out there's just a handful of instructions being generated. Taking a peek at AMD's code optimization guide, you can see those are the fastest instructions (collectively called DirectPath instructions), and they can be paired with 2 other simple instructions in the decoding stage. Trying to execute hand-optimized 8086-80386 code would actually result in slow execution, due to the use of VectorPath instructions, which can't be paired and, as a rule of thumb, take more cycles to execute (not always the case though. We're RISC-ing the code in order to make it efficient, but we're carrying the burden of Intel's design flaws of long ago, in the form of this added control logic for handling legacy code.
At this point, since rarely used instructions are being executed slowly, why not resort to some sort of emulation, a la Code Morphing? Not completely throwing away the architecture as Transmeta did, keep the simple instructions and emulate the rest (such as those used to handle BCD arithmetic, hardly used today).
Although it may seem like I hate x86, in fact, as an assembly coder, I find it one of the most comfortable architectures to work with. I have read some RISC assembly code, and couldn't picture myself writing code in it. I've programmed in 68HC11 assembly as well (it's a microcontroller from Motorola), and it feels like coding with your hands tied. So I'll definitely enjoy the new Hammer archicteture, especially because it fixes my two major complaints: small amount of registers (they've added 8 new ones), and the 32-bit architecture. Also, I'll be drowning for SSE2 support, including 8 new registers as well (that's 16 128-bit registers! yay!)
Slashdot Mirror
The great thing about RC5 is that it is parameterizable. One of the parameters is the machine word size, which can and will be changed from 32 to 64 bits when 64-bit CPUs become commonplace. In fact, Ronald Rivest wrote the following on his original paper on RC5: ``as 64-bit processors become available, it should be possible for RC5 to exploit their longer word length.'' The 64-bit transition also means the cipher's block size is upped to 128 bits, which is considered a Good Thing(TM) by cryptographers.
However, the current RSA Secret Key Challenges have, indeed, fixed machine word size at 32 bits and will not benefit from 64-bit processors.
I feel the same way -- every written test I had to take, I was proficient on the underlying theory, and would be able to code it in front of a computer. Most of the time I miss the 100% grade due to an off-by-one error, or an `if' clause testing the exact opposite of what I intended to. These sort of errors are easily spotted if you have a computer to aid in debugging, and that's why I believe coding tests should be done on a computer, period. Especially with students unfamiliar with the mechanics of coding -- after a few years of daily coding, a person seldom commits these silly errors.
As a side note, having learned touch typing, it's really hard to write on paper. Thoughts flow much faster than handwriting, and you end up losing yourself sometimes. I'm positive that also affects other coders when doing written tests.
Slot A was the first packaging for the 0.25 and 0.18u AMD Athlon CPUs, soon abandoned in favor of Socket A, still in use today.
What you actually have is a Slot 1 motherboard.
Maxwell's equations are valid regardless of relativity, in the same form they were laid down by James Clark Maxwell in the 19th century.
In fact, the importance of Einstein's contribution was changing Newtonian mechanics to comply with some of the strange consequences of Maxwell's equations, such as the constancy of the speed of light. So physics had to adapt to Maxwell's equations, not the other way around.
Although many people discuss the superiority of the SCSI protocol vs. the IDE protocol, this is not really the question.
Manufacturers produce the fastest disks on the planet on SCSI interfaces only. There are no 10K/15K RPM IDE discs, period. If one wants the lowest access time available today coupled with respectable transfer rates, one must purchase a 15K RPM drive, which are only available in SCSI interfaces.
For single-user access patterns, the author is correct to state that IDE drives have the lead today. StorageReview.com recently reviewed the latest 7200 RPM Seagate SCSI offering, and it was beaten down in single user tests by half a dozen of the newer IDE drives; however, when tested with server access patterns, it was the clear leader (excluding higher-RPM offerings, of course.) Still, 7200 RPM drives can't beat 15K RPM drives in any access pattern.
And I noticed the author was RAIDing drives -- 3ware's RAID products are very high quality, and their performance exceeds each and every other RAID card out there, SCSI or IDE interface. That surely contributed to his conclusion that current IDE drives are faster than their SCSI counterparts.
Yes, a one-time pad is unbreakable in an information-theoretic sense. However, there are few ciphers today capable of being broken by brute force. Most attacks are directed at protocols and other security problems.
For all practical purposes, 128-bit symmetric key ciphers are as unbreakable as an OTP, even to the three-letter organizations, but without the pratical problems associated to the OTP.
Quantum cryptography comes to extend ``nearly-unbreakable'' crypto even further. From the looks of it, the usage of OTPs will decrease due to quantum crypto, even if it isn't unbreakable.
Wrong. Java is compiled to an intermediate representation (bytecode), and later translated to the machine's native instructions by means of the JVM. Reverse engineering the bytecode is every bit as hard as reverse engineering ordinary assembly code for any processor.
Many things could be done.
First, an ICQ-style notification list. That alone, although it only depends on a client mod, would be great.
Second, in IRC, you can never be sure you're talking to the right person. The nick might have been hijacked or something. Having a central database of nicknames would solve the problem. Yeah, there's NickServ, but it's also a hack -- IRC needs an integrated authentication service.
Plus, people won't be using text interfaces for long. Once there's bandwidth enough, people are going to use voice and video, and save by a dirty hack IRC can't expand into that. Any IRC-replacing protocols must expand easily and cleanly -- you can't tell what the future holds for more efficient means of communication.
Being able to authorize people to go into your notify list or not is also a desirable feature for some.
I don't want to turn IRC into ICQ. I want to grab the best of both worlds into a single application, with the addition of cryptography and network scalibility enhacements.
You don't get the point.
You can't simply fix a broken protocol by tunneling it over a secure connection. IRC wasn't made with security in mind, and it shows. Stunnel is no more than a temporary and very dirty hack, until something better shows up. That might be SILC, or this project I've started along with a few other IRC addicts: CIRCUS.
Then there's other fixes regarding network scalibility, for instance. And don't forget the boom of IM in the last few years, which has shown quite a few features which IRC is lacking, and an updated protocol might take a shot at improving user experience, going way beyond what IRC can offer.
here. Only for non-commercial use. At least the cost factor will no longer be a problem for some users.
I second that absolutely. I only listen to music in my computer, I don't have a standalone CD player. Taking away demo/bootlegged live songs from my playlist (I wouldn't be able to buy them on a CD anyway), I'm left with no more than 6 hours of MP3s in here. The rest of my music collection, I usually have downloaded the MP3 first, figured the band was good, and bought a CD or DVD. Right now I own 100 records, split 5:1 between CDs and DVDs respectively (mostly purchased in the last 3 or 4 years -- I dumped my previous CDs by that time, although I had at least a hundred of them also.)
But, apparently, the record companies are forcing me to download MP3s only from now on. I'd rather have the higher sound quality found in a CD, and the nice cover and booklets, but oh well, I'm being forced into this.
To start off, there's an error in your question. There's no such thing as ``the IA-64 CPU.'' IA-64 is the instruction set architecture behind Itanium and the around-the-corner McKinley, and while I could list all the features and shortcomings behind it, it'd be a boring and technical explanation.
You can jump to conclusions, if you wish, by looking at Ace's Hardware SPECmine database, which contains all current SPEC2000 results. In case you don't know, those are the industry standard benchmarks. Here is a sample query of the SPEC2000 integer benchmarks, and here is a sample query of floating point results. As you can see, there are always better choices than the Itanium, and mostly from vendors who have been in the field of 64-bit processors for long, and probably with better prices too. You can never underestimate how important vendor reputation and experience is.
I alluded to the shortcomings of the instruction set of Intel's 64-bit offerings. Indeed, the poor performance can mostly be attributed to it (although the Itanium's poor design has helped a lot -- let's see whether McKinley fares better.) The truth is, Intel took VLIW and redressed it as EPIC; but VLIW has never been a panacea. Serial designs with out of order execution have been around longer, and worked great. The Itanium is a strict in-order processor, and the SPECint results show. And compiler technology isn't there yet; but Intel has acquired Alpha from Compaq and employed their compiler and MPU design team, widely reputed as the best in the field. Whether clever design will be able to mend the instruction set flaws, only time will tell. Indeed, the best strategy now is to wait a few years; seeing as how hardly a thousand Itanium system were actually purchased and paid for, most people seem to be taking this route. With McKinley the situation will be better for Intel, but not until the 3rd or 4th generation will the mass purchases begin, if ever.
Another common misconception is about the performance of Sun hardware. Just look at the values linked above from the SPEC benchmarks. Sun is known for scalable, reliable hardware, stuff you can depend on. But they're not the best performers by any account. The best designs come, undoubtedly, from the Alpha team; the upcoming EV8 would be the most advanced processor for a long time to come, if it weren't for Intel (who cancelled the EV8 project, obviously.) Unfortunately, Alpha is no longer a good buy, though not by technical merits. Having a vendor who will vanish sometime in the future is never a good strategy. Luckily, IBM's POWER series and HP-PA still remain, although the Precision Architecture will be discontinued some time in the future as well. IBM's Power4 design is the current king of the hill in SPEC scores, beating the closest competitors by a fair amount.
Finally, a great source of information is the Real World Tech forum, and the ``Silicon Insider'' columns by Paul DeMone, on the same website. (Paul also regularly reads the forum, and posts quite frequently too.)
You're mixing things up. OTPs are unconditionally secure. Shannon (in `Communication Theory of Secrecy Systems', 1949) has proven that unconditionally secure systems require keys as lenghty as the message itself, but OTOH an adversary cannot gleam anything about the plaintext given the ciphertext. One such example is the Vernam cipher, which represents the message and the key as a stream of bits, and XORs them together to generate the ciphertext.
Provably secure cryptosystems are those who have been proven to be as hard as the underlying hard problem, such as the Rabin cryptosystem, which is provably as hard as the integer factorization problem. In fact, it is based on the `square roots of modular numbers' problem, which has been proven to be computationally equivalent to integer factorization.
Just FYI.
I hope that you realize, by the end of this post, that you shouldn't comment on subjects you have no clue about. Even worse, in this case, you have the wrong `clues'. You managed to squeeze a lot of stupid and wrong stuff in a few lines, and you seem to stick to you. So here goes:
From the RSA Labs Cryptography FAQ (here's a link to this particular question):
Oh, then you must be wrong somewhere, OK? I know exactly where. Here's from the book ``Algorithms and Complexity'', by Herbert Wilf:
OK, so as a primality testing algorithm, it is rather inefficient. The Jacobi sum test and Atkin's test have a much better asymptotic growth, but if you look at it, you can use the same procedure to factor numbers.
See? Your O(n) algorithm (O(n) according to your stupid notation) is already a slow one. There are much faster algorithms out there than trial division. You should be realizing, by now, that you are beyond clueless, but here's the finishing touch:
Satisfied there? Great. Now, if this book isn't enough for you, go out there and try to find another book which contradicts this one. And no, Teach Yourself Algorithms in 21 days, or something along these lines, doesn't count. Which seems to be your source of information; otherwise you'd have refrained from posting this.
Now, for the really stupid part:
This shows how you have no understanding of asymptotics, or the general field of complexity of algorithms. Refer to the introduction of any good book on the matter, and you'll realize how wrong you are.
If that's not a good example, do some research on calculating Pi, for instance. You'll soon realize that the bottleneck for those computations is a means to do fast multiplication, and it can be done today in better than O(n log n) time (this particular value is the growth for the FFT-based methods.) But still, it can't be done yet in O(n) time, and it has been proven that this O(n) is the theoretical floor for a multiplication algorithm. So, it can't possibly do better than factorization, correct? But how come I can calculate a couple billion digits of Pi on my computer, while I can't factorize even a 100-digit number? In fact, I think I could hardly factorize an 80-digit number in the same amount of time it takes for calculating these billions of digits of Pi. (And it makes sense that algorithms for factorization are researched far more frequently than algorithms for Pi-calculation.)
Now, if you haven't convinced yourself, there's nothing more I can offer. I just hope the moderators read this post and mod you down into -1.
I have shown you one such algorithm above. Did this change the world? No. And it is still a very slow algorithm by today's standards. Oh, and did I mention that it was invented by the greek mathematician Erathostenes, a few millenia ago? You should rethink about posting every idiot idea that comes out of your head from now on; at least avoid a complete embarassment by looking up whether you've been wrong for thousand of years.
Now, I was about to moderate this post down, but I find that the moderation choices are highly non-orthogonal. Where is the `incorrect' moderation option? Or `clueless poster' option? And even better, what about leaving a small space for the moderator to explain why he modded as such?
/. crowd (as shown by the high score of the parent post) doesn't understand shit about the subject, so they moderate it up, and would metamoderate a clued in moderation (that is, one which detracted points from the post) as `unfair'.
I say this because most of the
My opinion is: if you don't understand the subject, restrict yourself to moderating and metamoderating the `funny' posts. And, even better, don't post. The S/N ratio is already too low with all the crapflooding, and downright wrong posts are even worse, since only knowledgeable people can moderate it up. Which isn't happening, as the parent post shows.
There's a huge difference there.
Although the x86 ISA is serial in nature, processors starting with the Pentium were superscalar (that is, were able to execute more than one instruction per clock cycle), and since the Pentium Pro/II/III were capable of out of order execution.
The difference between the original code and my code is simple. Unless the branch can be easily predicted, this code will take (worst case scenario) something from 12 cycles (on the Athlon) to 22 cycles (on the P4.) We're only taking into account the delay caused by pipeline flushing. In fact, his code was also not aligned to a particular boundary (say, addresses divisible by 16.) This might incur penalties as well.
My code, on the other hand, will execute in 2 cycles, since the first two instructions are paired in about any superscalar processor (see? My code runs in parallel as well. That's not an Itanium-only feature; in fact, you might even say that Itanium's hardwired implementation of parallelism is rather poor.) But I digress. My point was, I didn't study the IA-64 documentation, and if this is the only situation where I can avoid branches, than I need not drift away from x86; there I can avoid these sorts of branches already.
As for MOV EAX, 0 vs. XOR EAX, EAX, while both accomplish the same goal at the same speed, the former instruction is encoded into 5 bytes, while the latter is encoded into a single byte. If you're optimizing tight loops, this might really make a difference.
Sorry buddy, but you're wrong.
Taking an example from the x86 world: since the Pentium MMX, there exists the ability to copy memory in 64-bit chunks, using the MMX instructions. The Pentium 4 adds SSE2 instructions into the mix, being able to address data in 128-bit chunks, plus some ``Cacheability Control'' instructions. These hint the processor on the nature of the data, so it can handle caching better. (Although some PREFETCH instructions, found e.g. in the Athlon, already have some of these capabilities.) In the end, a ``plain'' 64-bit processor can't possibly use memory bandwidth as efficiently as these 32-bit designs shown above.
Now for the issue of RC5. First, I assume you're talking about the distributed.net client. (The RC5 cypher itself is parameterizable, so this discussion might not apply to real-life RC5 implementations.) I do have some knowledge on this area, and I can assure you, 64-bit will only slow down RC5 implementations, when the word size parameters are specified at 32 bits. Which, BTW, is the value set by RSA on all their Secret Key Challenges, this being the stuff distributed.net is cracking.
This is mostly related to the fact that arithmetic must be done modulo 2**32, and this cannot be done effectively with 64-bit instructions. With ADD instructions, that's fairly easy -- just mask out the 32 most significants bits, i.e. AND REG, 0x00000000FFFFFFFF (still, you're executing an ``useless'' instruction, as in ``unrelated to the algorithm at hand'', and which will slow you down.) However, RC5 relies heavily on rotation instructions, and unless the ISA in question allows for working with 32-bit chunks of registers, we're back to the slow {shift left by n, shift right by 32-n, OR} procedure. Again, that's not a flaw in the algorithm -- it allows you to specify many parameters, word size being one of them, and RSA picked 32-bit in their contests.
You are. That's my biggest grip with your post (that, and your downplaying of AMD's x86-64 architecture.) The guy asked about the advantages of 64-bit computing in general. In particular, he didn't ask for features specific to a single architecture. None of the features you talked about couldn't be implemented on a 32-bit processor, or an 8-bit microcontroller for that matter. Based on that, your post is completely off-topic and should be moderated accordingly.
Mind you, I might stop here, but I do have some other problems with your post.
SPEC results also speaks for themselves, and louder.
Itanium 800, SPEC base=314, SPEC peak=314. Athlon XP 1600, SPEC base=677, SPEC peak=701.
You don't need to tell me that the Itanium crushes everyone else in floating point applications in a clock-for-clock comparison. That makes it great for scientific computations, but what about everything else? (Nobody's playing Quake on a multi-thousand-dollar CPU.) Still, the 1 GHz Alpha 21264 is 11% faster than the 800 MHz Itanium on SPECfp, and even the newest P4s beat Itanium in this benchmark. While, of course, completely trashing it in the integer benchmarks. Seeing as how Itanium can't scale either, it won't regain the performance crown soon, if ever.
There are enough examples out there that show the x86 in a bad light in this regard, however, you didn't choose one. A real programmer would rather write:
movl VALUEA, %ebx
testl %eax, %eax
cmovzl VALUEB, %ebx
Just as fast as your code, cycle-wise. Note: a 2 GHz processor has a 2.5x smaller cycle time than an 800 MHz processor.
(The above code only runs on 6th+ generation processors, and requires VALUE[A-B] to be stored in registers; not a problem, I'd say.)
I really wished to debunk the rest of your points, but I've got better stuff to do. Not that I think those were the only flaws on your post.
Face it, Itanium is doomed. McKinley will be the first IA64 processor to be taken seriously. Particular implementations notwithstanding, it's a flawed architecture. VLIW has proved NOT to be a panacea, while OOO, which has proven time and again to work, was laughed at by the Intel PR machine. Now, with benchmarks available, they're just reaping the bitter results of their strategy.
Finally, the fact that ``[t]he Hammer series processors are really just an x86 extension'' is, in fact, its most advertised feature, and you didn't seem to have gotten it. Only time will tell whether AMD will succeed, and most factors are outside of AMD's control (and quite a bit of those are non-technical.) If Intel didn't have as much power as it does, hardly would the Itanium suceed in the marketplace. But then again, Sun hardware has always been a bad performer; technical factors do not play a major role in market economics, apparently.
I'm 101% positive you didn't read the article, since they mention (in the third paragraph of the first page) that their drive is an IBM UltraStar 36LP. Although I'm not familiar with this specific unit, UltraStars are IBM's SCSI offerings.
If you have no resources for purchasing scientific software, where did you get the money for purchasing MS Windows licenses?
Moderators: THIS IS NOT A TROLL. The question is simple: if you're already w4r3zing Windows, what refrains you from w4r3zing your scientific software also, and in the process saving us from these terrible Ask Slashdots of late?
Forgot to mention in my previous comment -- this onboard RAID featured in your motherboard, whatever manufacturer it may be, is not equivalent to a real RAID board with a microprocessor inside, which offloads all the processing. Imagine Winmodem -- all processing is done on the host. Of course a modem's work isn't as CPU intensive as the RAID work, but the data rate here is of a few megabytes per second. You will end up paying with your memory bandwidth too. If you're going the RAID way, try to avoid these ``WinRAID'' controllers; buy a 3ware instead, or perhaps an Adaptec.
Apparently, the guy who asked the question was looking to strip his drives in a RAID 0 configuration. This config won't add reliability at all, and in fact will decrease it proportionally to the amount of drives used: a single drive fails, you lose all your data. ALL OF IT, let that be clear. No going back. And this factor is increasingly more important in these days of the Deskstar 75GXP.
However, RAID 5 (which is what I believe you refer to) can indeed add reliability, but at a price: one of your disks' worth of space is ``wasted'', and drive performance can decrease along with an increase in CPU usage, unless you have a high quality controller.
Of course, RAID 0's twice as high likelihood of failure may not be all that important if you're only storing your MP3s, but keep it in mind if you're storing important data on it.
In terms of throughput, yes, you'll get about the same performance. However, unless you spend all day loading large files from a completely defragmented partition, what you should really look for is reduced seek times. This is the bottleneck when doing 99% of the work in your computer -- and that's why solid state drives are so blazingly fast, despite having an inferior throughput than their mechanical counterparts: they have smaller seek times, by many orders of magnitude.
Smaller seek times can be achieved by various means:
1. Get a high-end drive. More expensive models feature faster actuators.
2. Reduce the physical area the disk can access, by partitioning accordingly. Seagate also used this trick with their first-gen X15 drive, by reducing the platter size from 3" to 2.5", and they were very successful.
3. Use RAID 1 (mirroring) with a good controller, which for IDE basically means the 3ware models. They are, far and away, the best. Besides shaving off the seek times, they also improve the throughput.
4. And, of course, the most important: get a hard drive which spins faster. If you don't believe me, take a look at the sites below for benchmarks.
The hard drive is the only peripheral nowadays whose access time is measured in miliseconds and not nanoseconds. Instead of buying loads of memory and the fastest processor available, everyone should pay attention to the storage side of their machines -- whoever has experienced 10k and 15k RPM disks finds it hard to go back.
The best places in the web for storage info are Storage Review and, to a lesser extent, x-bit labs. Storage Review, besides their extremely scientific methodologies, maintains a drive reliability database, so you can check whether the drive you're looking for is likely to fail.
You should leave the language choice up to the students. Someone who picks C to do pattern matching and string operations instead of Perl deserves the buggy code they'll get (and the time they'll waste). Actually, this will end up enriching the contest, so far as students who learned more than one language will be able to pick the one best suited to the task at hand, a skill which can make or break a good design.
For that to happen, first those two processors must be in the same market segment. Do you see people using Alphas switching to x86? The same way, Itanium's market is not the desktop or average workstation. They're trying to compete with the cream of the crop RISC chips.
Rants aside, the Hammer architecture is a nice way to transition to 64-bit computing while keeping legacy code, no rewriting or even recompiling. But it has a cost: it'll carry the same inefficiencies found in current CISC processors. While many designers have found their way around it in the performance arena, the drawbacks are evident: higher complexity, power dissipation, etc. -- die size is unevenly divided between control logic and number-crunching logic, which isn't a comfortable situation.
Take the time to generate assembly code using gcc -S, and you'll soon find out there's just a handful of instructions being generated. Taking a peek at AMD's code optimization guide, you can see those are the fastest instructions (collectively called DirectPath instructions), and they can be paired with 2 other simple instructions in the decoding stage. Trying to execute hand-optimized 8086-80386 code would actually result in slow execution, due to the use of VectorPath instructions, which can't be paired and, as a rule of thumb, take more cycles to execute (not always the case though. We're RISC-ing the code in order to make it efficient, but we're carrying the burden of Intel's design flaws of long ago, in the form of this added control logic for handling legacy code.
At this point, since rarely used instructions are being executed slowly, why not resort to some sort of emulation, a la Code Morphing? Not completely throwing away the architecture as Transmeta did, keep the simple instructions and emulate the rest (such as those used to handle BCD arithmetic, hardly used today).
Although it may seem like I hate x86, in fact, as an assembly coder, I find it one of the most comfortable architectures to work with. I have read some RISC assembly code, and couldn't picture myself writing code in it. I've programmed in 68HC11 assembly as well (it's a microcontroller from Motorola), and it feels like coding with your hands tied. So I'll definitely enjoy the new Hammer archicteture, especially because it fixes my two major complaints: small amount of registers (they've added 8 new ones), and the 32-bit architecture. Also, I'll be drowning for SSE2 support, including 8 new registers as well (that's 16 128-bit registers! yay!)