Sure thing. # openssl speed sha1 Doing sha1 for 3s on 16 size blocks: 4925162 sha1's in 3.00s Doing sha1 for 3s on 64 size blocks: 3460802 sha1's in 2.99s Doing sha1 for 3s on 256 size blocks: 1972423 sha1's in 3.00s Doing sha1 for 3s on 1024 size blocks: 722903 sha1's in 3.00s Doing sha1 for 3s on 8192 size blocks: 104552 sha1's in 2.99s OpenSSL 0.9.8g 19 Oct 2007 built on: Mon Jun 7 19:28:26 UTC 2010 options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DMD5_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha1 26267.53k 74077.37k 168313.43k 246750.89k 286451.50k
26 MB/sec on small blocks in sha1sum. String compares I don't have a command handy to time, but I know that they will be in the hundreds of megabytes / sec range. Now this does not cover security concerns at all. I think that, since we are talking about a security system, we should talk about them.
Passwords are salted and hashed because storing a plaintext password is a grave security mistake. Anyone working with the database could grab a single table and know what everyone's passwords were. That is exceptionally bad, even if they only used the password in that one place. Someone could use that knowledge to legitimately log in as a user. Extrapolate from there. Worse still, many people use the same passwords in a few places, perhaps with a few variants.
Without just telling you to Read More Schneier (which would be rude) , I'd like to make you aware that hashing is one of the most amazingly cheap non-arbitrary things one can do on a modern processor, and that all other operations in a useful system take vastly longer (database lookups, disk access, network access, public key cryptography to establish an SSL session which you better hope your password travels over).
Also for further reading: Package transforms and Schneier's book Applied Cryptography.
Security is important, and I'd think that if you have such strong opinions you could put them to good use. Happy reading!
PS: None of the links I provided talk about timing attacks. That is very important, but once you've got your head around cryptographic hashes you will know that a well salted and properly implemented hash library will not be vulnerable to many timing attacks. Figured I'd warn you.
Actually, no, anti-aliasing leads to an image that more closely mimics the way we perceive the world (continuous analog signals, instead of digital samples). Here is a VERY good primer on Anti-Aliasing (with pictures!) http://www.povray.org/documentation/view/3.6.1/223/#s02_01_02_08_04
Now, that isn't exactly how it works in every system, but the basics are there and the best algorithms for the task are also presented. In case you didn't click, or don't care to read the whole thing here are the basics:
Oh no! The pixel next to me is WAY different! I'll bet that we missed something that goes between us!
*look in between the pixels*
Ah HA! I see that this is an edge of some sort, and human eyes would, if this were real, see this pixel as a mixture of colors
*combine the samples taken when looking around in an average mimicking what real life would show*
So you see, it isn't blurring at all! It's taking more samples, and increasing the accuracy of the image relative to what is being sampled, where it is necessary.
As I said, this isn't the algorithm that everything uses, some do it for every single pixel, but the end result is about the same except in extreme corner cases.
I'm not a kernel hacker, just yet, but it is a personal goal that I've been working towards for a while now. I don't get a chance to work on anything deeply linux at work, but I've seen some shortcomings in the kernel that I'd like to rectify. One example is the lack of a "Ready Boost" like cache, but a bit beefier, utilizing SSD's to alow large databses to run at SSD speed for writes and cached reads while gaining the benefit of cheap spinning disk storage. This is a LOT of theory work and deep kernel driver stuff that I'm glad to learn on my own time.
I might be unique, or perhaps the fact that I'm not actively DOING it makes me another statistic, but i think the kernel is a worthwhile cause.
One Time Pad
This has guaranteed security because you simply xor one character of plaintext with one character of key. Since someone trying to "crack" the key could come up with any message at all with a chosen key it is 100% secure. Nothing differentiates the right key from the wrong key.
However, OTPs require the secure transmission of the OTP beforehand, so it does not see much real world use.
There is a limitation that quantum computing has to deal with that normal computing does not. That is the problem of decoherence. Think of it as noise, but worse. Quantum computers need to operate on all of their bits at the same time. This introduces problems once you scale up, since you can't just compartmentalize the problem. You have to add error correction, but that adds more complexity, and therefore more bits. It starts to spiral out of control very quickly.
So, though we jump to higher per operation bit counts in normal processors very easily, quantum breakthroughs are needed to even go to the next level of quantum computing. Though, if I had to place a bet I'd say it would follow a linear version of moore's law, since you have a qudratic level of complexity added to the problem, canceling out our honored tradition of quadratic computing growth.
A very fine point you make about trusted intermediaries. Quantum key exchange only works 'point to point' not 'end to end' that means that for every link in the chain there is a weak point to be exploited. That is unacceptable for some uses and users.
The wiki article has really good information, but please research this in depth (learn the lingo, do some google searches if you want to know more) http://en.wikipedia.org/wiki/Quantum_cryptography .
Good insights Davidwr, but I hope we can come up with a system that provides 'end to end' security, since I don't like to trust third parties for security. Too much corruption.
So, yeah. Quantum computers of reasonable size get us discrete logarithms. This means that the Diffie Hellman key exchange can be reversed after the exchange if the attacker has a powerful enough quantum computer. The computer to break DH key exchanges would be powerful enough to also break the encapsulating RSA or similar exchange (even assuming RSA encryption AND signatures was used).
As far as being terrified by it, that's fairly easy.
I'm a bit of a crypto nerd (more of a fan, not exactly up to sratch on designing the algorithms, but I've read EXTENSIVELY on their proper use) and if you get a large quantum computer working, things go titsup for any of our currently viable public key crypto schemes. The short of it is this: you can no longer trust any key exchange system that relies on public keys. SSH is no longer secure, SSL is trash, the list goes on. Any time you need to exchange secure data without having previously encountered the far end securely first, game over.
That's frightening. I know that there are some proposed algorithms that only allow for a polynomial speedup in quantum computers, but I couldn't find them between when I posted initially and now.
So yeah, fear it, but in terms of cracking larger numbers this is not even a proverbial "smoke in the building" scenario. It looks like their technique does not employ error checking, making large numbers of qbits near impossible to work with.
So, this is really impressive. I'd also like to know how many (useful, as opposed to error checking) qbits they can manipulate in total using this technique, and traditional techniques, for that matter. Those are the big limiting factors in this technique's use.
Side question: Which asymmetrical encryption algorithms are safe(er) against quantum algorithms (Some algorithms do not benefit from a tremendous quantum speedup, only a large one)?
Today's chips, at their core, look a lot like RISC chips. They do a lot of work to hide that, translating x86 ops to native ops. I'd like to see a chip that can run in a x86 'translated' mode and a 'native' RISC mode, much like was done with 32bit/64 bit.
this is, admittedly, a much harder task to accomplish, but exposing a more efficient RISC mode would drive OS vendors to migrate to that. With a bit of careful juggling and VM technology the chips would allow legacy code to run while exposing the more efficient native modes to software that took advantage of it.
Such a shift would take time, but so is 64bit.
Oh well, I guess I'll go back to the idea lab and keep on dreaming.
Actually a switching power supply leaves the power DC.
Switching power supplies are easy to understand, here is the basic idea:
take a bunch of capacitors and charge them in parallel (for a voltage increase) or in series (for a voltage drop) and then discharge them in the opposite configuration.
So if you charge two caps in series at 3V when you discharge them in parallel they will produce 1.5v each.
Think of it in the same way as batteries, in series they voltage is added together. This is why it is called a switching power supply, the caps are switched to charge then to discharge, then back many times per second. A large capacitor on the output side smooths out the voltage to within tolerances.
This is VERY efficient, since switching is very cheap in terms of power used, and capacitors lose very little energy charging and discharging.
Have a handy link to read more: wikipedia
Actually, DRM does not equate to a locked door. Here is what DRM, generally, does:
It encrypts the content with a key (sometimes unique to an instance of the media, sometimes it is shared among a whole release) and then that key is sent to the consumer via a different channel. For example on DVD players (of both new and old) the key is embedded in the DVD player on a chip (or, so much less securely, inside a sotware player).
This is DRM's only trick, hide the key a little bit!
In the end in order for the user view the content it has to be decrypted. Since the user has the key (in some form) to view the content then they can use that key to remove the DRM form that content.
I hope that you can see the DRM is not a locked door, it is more like a locked door with the key under the doormat!
Crypto is almost unbelievably hard to get right, and the odds of more than a tiny handful of programs pulling it off is slim.
Cryptographic algorithms are difficult to design, but they are documented, implemented, and made publicly available. GPG is not the only secure encryption program out there, it is simply a common and well designed one. RSA and AES encryption libraries are widely available. They are even embedded in the Linux kernel for use by programs that call the openssl library so that the kernel can use its bultin algorithms or offload to a piece of hardware, if it is available. This is, in fact, what GPG does. It calls the openssl library where available and embeds (links) openssl's algorithms where it is not.
I will, however, grant you the point that in designing a system to properly use the algorithms there are places where developers can go wrong. That is where peer review and open source shine. Anyone can review the program, and in popular projects they often do.
For a good primer on encryption pick up Bruce Scheiner's Applied Cryptography. You can also find a lot of resources online, like wikipeida, though those articles can get a bit technical.
I hope that you can learn that encryption can be utilized by almost any competent programmer, and that it is not the program you should distrust, but rather third parties. That is, after all, the heart of encryption, knowing who and what to trust and giving everyone else hell.
That is now on my list of things to read.
I think a lot will be review for me but it certainly has a TON of meat on its bones from the look of it.
Thanks 2^20:P
We already do.
Given the twisted labyrinths inside those chips the data paths are a lot longer than the width of the chip.
They overcome this, and related problems, by "pipelining" the instructions. Moderns CPUs can track many instructions "inflight" while they are being performed in steps (12 - 43 on most modern processors depending on the model of chip, they try to keep this number as low as they can).
So to answer your question, "Break things into small, manageable steps and develop the logic to put on the chip to handle that efficiently"
They do this with branch prediction, command re-ordering, caching, and the like.
It is really REALLY interesting stuff. Hard to find goos sources to learn about it online but wiki and ars technica are good places to start.
Yeah, okay, that is all well and good, but not everything can be arbitrarily broken down into parallel tasks. Take your example. Imagine v1 takes 2s of CPU time and cannot be split into smaller pieces to be processed. However v2 takes 25s and cannot be broken up into parallel tasks. v4 will execute slightly sooner because parts of v2 started processing slightly sooner than if there were no parallelism between v1 and v2, but the speedup is minimal since the large wait is on v2.
Take that down to a smaller level. Painting the screen, performing a sort, taking a sha1 checksum. They all have a non-parallel bottleneck. Painting the screen has to be done in the order things are viewed, you can calculate where things overlap, but eventually one thread has to paint it in order. A sort must eventually have a certain number of comparisons made, and they have to be made in a certain order, a small speedup can be had from using multiple cores but it ends up costing more CPU horsepower overall. Sha1/md5 checksums can only be processed in a certain order.
We can break small parts of most tasks up between cores, but beyond a certain level it becomes non-trivial to find work for all the hardware to do. Either the problem has to be re-engineered, such as developing a multi step sorting algorithm, or the problem has to be broken into single steps and each evaluated against the rest for order of execution to find out which steps can be executed out of order (since there is no guarantee which steps will happen first on a multi CPU system) and then writing an entire system to farm out arbitrary bits of code to multiple processors (either at the compiler level after giving it hints, or at the code level with threads, mutexes, semaphores, and shared memory).
Web servers and the like, on the other hand, can see a benefit immediately since they already have more tasks running than CPU's to run them on (server dozens of pages simultaneously). However even those can start to see diminishing returns when memory begins to be contented for by all the threads.
I don't know, if the hacker has a few profiles on myspace, a could of flickr galleries, etc and a 'core network' of bots that visit those pages (so the feds can't simply find an insanely popular page to blame as the root) he could hide VERY effectively. Law enforcement or not there are more ways for these guys to go undergound than we have ways of stopping them.
The problem with blocking is this: User Content on Large/Important websites
All a hacker must do is create a bot to make logons on some social networking sites, flickr, photobucket, wikipedia, etc and re-direct the captchas to a legitimate pornography site to have real humans crack. Once the bots are on the sites thousands of them can upload content with encrypted stenographic messages. In the case of pictures they will be undetectable, since encrypted messages show up as noise, just as is introduced by a camera. Now you have a large, distributed control network that can be self-healing (give status updates to eath other, have a web of control instead of a single link, dead peer detection, peer sharing, etc)
Partially true.
The GPUs of today now have some general purpose circuits, but they are far from optimized and the execution unit count is skewed to the point that these processors would never, ever be able to run, say, an OS with anything approaching efficiency. FAH benefits from the insane amount of Floating point power because FAH is nothing but a pure FP stress test. They had to heavily modify the code to run on these babies, basically tuning the problems into vector information and letting the GPU do its thing, throwing. Only a few areas involve a need for CPU style processor, which is functionality provided only on these new cards. So please, please realize that even though these cards do not a contain a "protein folding circuit", they did modify the program to run on what it does have: 4x4 matrix operation units for multiplication and addiction.
Slashdot Mirror
Sure thing.
# openssl speed sha1
Doing sha1 for 3s on 16 size blocks: 4925162 sha1's in 3.00s
Doing sha1 for 3s on 64 size blocks: 3460802 sha1's in 2.99s
Doing sha1 for 3s on 256 size blocks: 1972423 sha1's in 3.00s
Doing sha1 for 3s on 1024 size blocks: 722903 sha1's in 3.00s
Doing sha1 for 3s on 8192 size blocks: 104552 sha1's in 2.99s
OpenSSL 0.9.8g 19 Oct 2007
built on: Mon Jun 7 19:28:26 UTC 2010
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DMD5_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 26267.53k 74077.37k 168313.43k 246750.89k 286451.50k
26 MB/sec on small blocks in sha1sum. String compares I don't have a command handy to time, but I know that they will be in the hundreds of megabytes / sec range. Now this does not cover security concerns at all. I think that, since we are talking about a security system, we should talk about them.
Passwords are salted and hashed because storing a plaintext password is a grave security mistake. Anyone working with the database could grab a single table and know what everyone's passwords were. That is exceptionally bad, even if they only used the password in that one place. Someone could use that knowledge to legitimately log in as a user. Extrapolate from there. Worse still, many people use the same passwords in a few places, perhaps with a few variants.
Without just telling you to Read More Schneier (which would be rude) , I'd like to make you aware that hashing is one of the most amazingly cheap non-arbitrary things one can do on a modern processor, and that all other operations in a useful system take vastly longer (database lookups, disk access, network access, public key cryptography to establish an SSL session which you better hope your password travels over).
Cryptographic hashes are one of the best building blocks for secure systems, and you may find their application interesting. Give it a look-see. I do recommend Schneier, but some free links follow:
http://unixwiz.net/techtips/iguide-crypto-hashes.html (decent primer, little long winded)
http://mathworld.wolfram.com/BirthdayAttack.html (simple explanation of the birthday attack)
http://en.wikipedia.org/wiki/Salt_(cryptography) (I know a wiki link, but this ties in VERY closely with password security)
http://en.wikipedia.org/wiki/Message_authentication_code (another, I know. But it has a lot of titillating links in it that should be followed)
Also for further reading: Package transforms and Schneier's book Applied Cryptography.
Security is important, and I'd think that if you have such strong opinions you could put them to good use. Happy reading!
PS: None of the links I provided talk about timing attacks. That is very important, but once you've got your head around cryptographic hashes you will know that a well salted and properly implemented hash library will not be vulnerable to many timing attacks. Figured I'd warn you.
Now, that isn't exactly how it works in every system, but the basics are there and the best algorithms for the task are also presented. In case you didn't click, or don't care to read the whole thing here are the basics:
So you see, it isn't blurring at all! It's taking more samples, and increasing the accuracy of the image relative to what is being sampled, where it is necessary.
As I said, this isn't the algorithm that everything uses, some do it for every single pixel, but the end result is about the same except in extreme corner cases.
I'm not a kernel hacker, just yet, but it is a personal goal that I've been working towards for a while now. I don't get a chance to work on anything deeply linux at work, but I've seen some shortcomings in the kernel that I'd like to rectify. One example is the lack of a "Ready Boost" like cache, but a bit beefier, utilizing SSD's to alow large databses to run at SSD speed for writes and cached reads while gaining the benefit of cheap spinning disk storage. This is a LOT of theory work and deep kernel driver stuff that I'm glad to learn on my own time.
I might be unique, or perhaps the fact that I'm not actively DOING it makes me another statistic, but i think the kernel is a worthwhile cause.
One Time Pad This has guaranteed security because you simply xor one character of plaintext with one character of key. Since someone trying to "crack" the key could come up with any message at all with a chosen key it is 100% secure. Nothing differentiates the right key from the wrong key. However, OTPs require the secure transmission of the OTP beforehand, so it does not see much real world use.
THANK YOU!
That link was exactly what I was looking for.
Really thank you.
There is a limitation that quantum computing has to deal with that normal computing does not. That is the problem of decoherence. Think of it as noise, but worse. Quantum computers need to operate on all of their bits at the same time. This introduces problems once you scale up, since you can't just compartmentalize the problem. You have to add error correction, but that adds more complexity, and therefore more bits. It starts to spiral out of control very quickly.
So, though we jump to higher per operation bit counts in normal processors very easily, quantum breakthroughs are needed to even go to the next level of quantum computing. Though, if I had to place a bet I'd say it would follow a linear version of moore's law, since you have a qudratic level of complexity added to the problem, canceling out our honored tradition of quadratic computing growth.
A very fine point you make about trusted intermediaries. Quantum key exchange only works 'point to point' not 'end to end' that means that for every link in the chain there is a weak point to be exploited. That is unacceptable for some uses and users.
The wiki article has really good information, but please research this in depth (learn the lingo, do some google searches if you want to know more) http://en.wikipedia.org/wiki/Quantum_cryptography .
Good insights Davidwr, but I hope we can come up with a system that provides 'end to end' security, since I don't like to trust third parties for security. Too much corruption.
A very insightful question. Mod parent up.
In short, yes: Wiki see also (with more math than I can handle) Berkley article
So, yeah. Quantum computers of reasonable size get us discrete logarithms. This means that the Diffie Hellman key exchange can be reversed after the exchange if the attacker has a powerful enough quantum computer. The computer to break DH key exchanges would be powerful enough to also break the encapsulating RSA or similar exchange (even assuming RSA encryption AND signatures was used).
As far as being terrified by it, that's fairly easy.
I'm a bit of a crypto nerd (more of a fan, not exactly up to sratch on designing the algorithms, but I've read EXTENSIVELY on their proper use) and if you get a large quantum computer working, things go titsup for any of our currently viable public key crypto schemes. The short of it is this: you can no longer trust any key exchange system that relies on public keys. SSH is no longer secure, SSL is trash, the list goes on. Any time you need to exchange secure data without having previously encountered the far end securely first, game over.
That's frightening. I know that there are some proposed algorithms that only allow for a polynomial speedup in quantum computers, but I couldn't find them between when I posted initially and now.
So yeah, fear it, but in terms of cracking larger numbers this is not even a proverbial "smoke in the building" scenario. It looks like their technique does not employ error checking, making large numbers of qbits near impossible to work with.
So, this is really impressive. I'd also like to know how many (useful, as opposed to error checking) qbits they can manipulate in total using this technique, and traditional techniques, for that matter. Those are the big limiting factors in this technique's use.
Side question: Which asymmetrical encryption algorithms are safe(er) against quantum algorithms (Some algorithms do not benefit from a tremendous quantum speedup, only a large one)?
^_^ That was a good onion article, that one was.
http://www.theonion.com/content/node/33930
By the by, when did the onion open up their archives? I recall them shuffling articles out of their free page very quickly.
I'd like to see this go a bit father.
Today's chips, at their core, look a lot like RISC chips. They do a lot of work to hide that, translating x86 ops to native ops. I'd like to see a chip that can run in a x86 'translated' mode and a 'native' RISC mode, much like was done with 32bit/64 bit.
this is, admittedly, a much harder task to accomplish, but exposing a more efficient RISC mode would drive OS vendors to migrate to that. With a bit of careful juggling and VM technology the chips would allow legacy code to run while exposing the more efficient native modes to software that took advantage of it.
Such a shift would take time, but so is 64bit.
Oh well, I guess I'll go back to the idea lab and keep on dreaming.
Actually a switching power supply leaves the power DC.
Switching power supplies are easy to understand, here is the basic idea:
take a bunch of capacitors and charge them in parallel (for a voltage increase) or in series (for a voltage drop) and then discharge them in the opposite configuration.
So if you charge two caps in series at 3V when you discharge them in parallel they will produce 1.5v each.
Think of it in the same way as batteries, in series they voltage is added together. This is why it is called a switching power supply, the caps are switched to charge then to discharge, then back many times per second. A large capacitor on the output side smooths out the voltage to within tolerances.
This is VERY efficient, since switching is very cheap in terms of power used, and capacitors lose very little energy charging and discharging.
Have a handy link to read more: wikipedia
XD Wish I had mod points
Actually, DRM does not equate to a locked door. Here is what DRM, generally, does:
It encrypts the content with a key (sometimes unique to an instance of the media, sometimes it is shared among a whole release) and then that key is sent to the consumer via a different channel. For example on DVD players (of both new and old) the key is embedded in the DVD player on a chip (or, so much less securely, inside a sotware player).
This is DRM's only trick, hide the key a little bit!
In the end in order for the user view the content it has to be decrypted. Since the user has the key (in some form) to view the content then they can use that key to remove the DRM form that content.
I hope that you can see the DRM is not a locked door, it is more like a locked door with the key under the doormat!
Crypto is almost unbelievably hard to get right, and the odds of more than a tiny handful of programs pulling it off is slim.
Cryptographic algorithms are difficult to design, but they are documented, implemented, and made publicly available. GPG is not the only secure encryption program out there, it is simply a common and well designed one. RSA and AES encryption libraries are widely available. They are even embedded in the Linux kernel for use by programs that call the openssl library so that the kernel can use its bultin algorithms or offload to a piece of hardware, if it is available. This is, in fact, what GPG does. It calls the openssl library where available and embeds (links) openssl's algorithms where it is not.
I will, however, grant you the point that in designing a system to properly use the algorithms there are places where developers can go wrong. That is where peer review and open source shine. Anyone can review the program, and in popular projects they often do.
For a good primer on encryption pick up Bruce Scheiner's Applied Cryptography. You can also find a lot of resources online, like wikipeida, though those articles can get a bit technical. I hope that you can learn that encryption can be utilized by almost any competent programmer, and that it is not the program you should distrust, but rather third parties. That is, after all, the heart of encryption, knowing who and what to trust and giving everyone else hell.
That is now on my list of things to read. I think a lot will be review for me but it certainly has a TON of meat on its bones from the look of it. Thanks 2^20 :P
We already do.
Given the twisted labyrinths inside those chips the data paths are a lot longer than the width of the chip.
They overcome this, and related problems, by "pipelining" the instructions. Moderns CPUs can track many instructions "inflight" while they are being performed in steps (12 - 43 on most modern processors depending on the model of chip, they try to keep this number as low as they can).
So to answer your question, "Break things into small, manageable steps and develop the logic to put on the chip to handle that efficiently"
They do this with branch prediction, command re-ordering, caching, and the like. It is really REALLY interesting stuff. Hard to find goos sources to learn about it online but wiki and ars technica are good places to start.
Yeah, okay, that is all well and good, but not everything can be arbitrarily broken down into parallel tasks.
Take your example. Imagine v1 takes 2s of CPU time and cannot be split into smaller pieces to be processed. However v2 takes 25s and cannot be broken up into parallel tasks. v4 will execute slightly sooner because parts of v2 started processing slightly sooner than if there were no parallelism between v1 and v2, but the speedup is minimal since the large wait is on v2.
Take that down to a smaller level. Painting the screen, performing a sort, taking a sha1 checksum. They all have a non-parallel bottleneck. Painting the screen has to be done in the order things are viewed, you can calculate where things overlap, but eventually one thread has to paint it in order. A sort must eventually have a certain number of comparisons made, and they have to be made in a certain order, a small speedup can be had from using multiple cores but it ends up costing more CPU horsepower overall. Sha1/md5 checksums can only be processed in a certain order.
We can break small parts of most tasks up between cores, but beyond a certain level it becomes non-trivial to find work for all the hardware to do. Either the problem has to be re-engineered, such as developing a multi step sorting algorithm, or the problem has to be broken into single steps and each evaluated against the rest for order of execution to find out which steps can be executed out of order (since there is no guarantee which steps will happen first on a multi CPU system) and then writing an entire system to farm out arbitrary bits of code to multiple processors (either at the compiler level after giving it hints, or at the code level with threads, mutexes, semaphores, and shared memory).
Web servers and the like, on the other hand, can see a benefit immediately since they already have more tasks running than CPU's to run them on (server dozens of pages simultaneously). However even those can start to see diminishing returns when memory begins to be contented for by all the threads.
You can see this problem gets complex fast.
engineering
Couldn't code it anyways. ;)
The only development base I know is Linux. Not so great for viri.
I don't know, if the hacker has a few profiles on myspace, a could of flickr galleries, etc and a 'core network' of bots that visit those pages (so the feds can't simply find an insanely popular page to blame as the root) he could hide VERY effectively. Law enforcement or not there are more ways for these guys to go undergound than we have ways of stopping them.
The problem with blocking is this:
User Content on Large/Important websites
All a hacker must do is create a bot to make logons on some social networking sites, flickr, photobucket, wikipedia, etc and re-direct the captchas to a legitimate pornography site to have real humans crack. Once the bots are on the sites thousands of them can upload content with encrypted stenographic messages. In the case of pictures they will be undetectable, since encrypted messages show up as noise, just as is introduced by a camera.
Now you have a large, distributed control network that can be self-healing (give status updates to eath other, have a web of control instead of a single link, dead peer detection, peer sharing, etc)
How would one fight that?
Thank you for that, I really appreciate that level of intimate detail.
Partially true. The GPUs of today now have some general purpose circuits, but they are far from optimized and the execution unit count is skewed to the point that these processors would never, ever be able to run, say, an OS with anything approaching efficiency. FAH benefits from the insane amount of Floating point power because FAH is nothing but a pure FP stress test. They had to heavily modify the code to run on these babies, basically tuning the problems into vector information and letting the GPU do its thing, throwing. Only a few areas involve a need for CPU style processor, which is functionality provided only on these new cards. So please, please realize that even though these cards do not a contain a "protein folding circuit", they did modify the program to run on what it does have: 4x4 matrix operation units for multiplication and addiction.