The K6 family is optimized for different things than the Pentium Pro family, and one change is that on a K6-family processor, the pipelines are shorter, thus making heavy and unoptimized FP slower.
Not quite right. The K6 FPU has a lower latency, while the Pentium FPU has a higher throughput. The result is, that unoptimized code might run faster on a K6, but optimized code will always run faster on a Pentium. (I'm talking about 'standard' FPU oprations, not 3D-Now.)
I don't know exactly what Schnirelman proved, but it seems that he meant 300000 distinct primes (The number 3 * 300002 is even and the sum of more than 300000 primes). So you're proof is wrong.
When I would do "something", evaluate a cost function, and then undo that "something" (because of an increase in cost), the cost function after the undo would be equal to the original cost function (before the "something") more often on Linux than on Solaris.
I suppose you run Linux on an x86 processor. The x86 FPU uses 80-bit floating point numbers internally. That might be the reason why Linux is more accurate. You can force an x86 program to calculate with 64-bit numbers if you write each intermediate result to memory and load it again. But that's not very efficient.
SuSE Linux has a so-called 'live filesystem' CD, that you can boot from and try out lots of apps. It used to come with the distro, but now you have to buy it separately for about $10.
Does that mean, we will soon have "no warranty" disclaimers on every piece of hardware? "Should your new processor prove defective, you assume the cost of all necessary servicing, repair or correction";)
If you double the key size, it takes eight times longer to encrypt/decrypt a message (assuming no other overhead and a 'standard' RSA implementation). 1M = 2^20, 512 = 2^9, 8^(20-9) = 2^33 = 8G It takes 8,589,934,592 times longer to encrypt/decrypt a 1Mbit key than a 512bit key. (Maybe there's an alogrithm with O(n^2.something), could be really interesting for big keys)
Even in a single rendering pass pixels are most probably rendered more than once. Basically, all polygons in a scene are rendered whether you can't see them because they overlap or not.
If you look closer at the original shipdates, you will notice that all of that software is at least (and some quite exactly) 10 years old. So we have to wait a bit for TC3, which is the compiler I started with. It really had a killer feature: Click with the right mouse button on a library function name and you get the online help;]
Slashdot Mirror
to a FW HDD at the full 400MB/s
(laughter)
die unless $everythingOk;
though it's maybe just a matter of taste.
/sbin/ipchains -A input -d 10.0.0.0/8 -j REJECT
You're rightit's /sbin/ipchains -A input -d 127.0.0.0/24 -j REJECT /sbin/ipchains -A input -d 192.168.0.0/16 -j REJECT /sbin/ipchains -A input -d 10.0.0.0/24 -j REJECT
The K6 family is optimized for different things than the Pentium Pro family, and one change is that on a K6-family processor, the pipelines are shorter, thus making heavy and unoptimized FP slower.
Not quite right. The K6 FPU has a lower latency, while the Pentium FPU has a higher throughput. The result is, that unoptimized code might run faster on a K6, but optimized code will always run faster on a Pentium. (I'm talking about 'standard' FPU oprations, not 3D-Now.)
I don't know exactly what Schnirelman proved, but it seems that he meant 300000 distinct primes (The number 3 * 300002 is even and the sum of more than 300000 primes). So you're proof is wrong.
When I would do "something", evaluate a cost function, and then undo that "something" (because of an increase in cost), the cost function after the undo would be equal to the original cost function (before the "something") more often on Linux than on Solaris.
I suppose you run Linux on an x86 processor. The x86 FPU uses 80-bit floating point numbers internally. That might be the reason why Linux is more accurate. You can force an x86 program to calculate with 64-bit numbers if you write each intermediate result to memory and load it again. But that's not very efficient.
NAME SYNOPSIS
You mean 'Hefeweizen'? Yeah, Weißbier rules 8)
SuSE Linux has a so-called 'live filesystem' CD, that you can boot from and try out lots of apps. It used to come with the distro, but now you have to buy it separately for about $10.
Why don't you print <<END
...
END the page?
What's the difference between switching to HTML (or JavaScript or SQL) via Perl multi-line strings and switching to PHP from HTML code?
Does that mean, we will soon have "no warranty" disclaimers on every piece of hardware? "Should your new processor prove defective, you assume the cost of all necessary servicing, repair or correction" ;)
Of course, some a more reliable than others ;)
Needless to say more
If you double the key size, it takes eight times longer to encrypt/decrypt a message (assuming no other overhead and a 'standard' RSA implementation).
1M = 2^20, 512 = 2^9, 8^(20-9) = 2^33 = 8G
It takes 8,589,934,592 times longer to encrypt/decrypt a 1Mbit key than a 512bit key.
(Maybe there's an alogrithm with O(n^2.something), could be really interesting for big keys)
Even in a single rendering pass pixels are most probably rendered more than once. Basically, all polygons in a scene are rendered whether you can't see them because they overlap or not.
If you look closer at the original shipdates, you will notice that all of that software is at least (and some quite exactly) 10 years old. So we have to wait a bit for TC3, which is the compiler I started with. It really had a killer feature: Click with the right mouse button on a library function name and you get the online help ;]
Check out fortify.net