You have to remember what speculative execution really means. It means that your start fetching and executing the next intruction immediately even when you won't know the result of the previous instruction for 20-1000+ clocks. (If the previous inst missing the cache and goes to memory it might be gone a LONG time.) So if the previous instruction is a branch, you guess where it will go and keep going. If it turns out that you are wrong, then that instrution (and likely 100's of others) needs to be flushed from the machine and restarted.
So It does introduce a bubble, but it is a BIG one.
The branch predicter in the P4 is really amazing, but think of a loop to count the number of set bits in a 32-bit random number. (Bonus points if you can portability code that function to have no branches!)
I almost hate to get sucked into this, but here goes...
What you said was "Wouldn't it be cool if the version system can show me who changed the return value of this function and why?" Answer: yes it is cool. But lets looks at something simpler. It would be cool if your version system can tell you who changed the current line and why. None of the systems being talked about here can.
Don't tell me about 'cvs annotate'. That is the other reason branching sucks in CVS. It totally trashes your history. After you merge a branch, the person who did the merge appears to have done all the work. The actual author of gets lost.
It takes people a while to really "get" what this buys you in BitKeeper, but after they understand it they are spoiled for life! Suddenly you don't use comments to understand code, you use the revision history...
I know it is off topic, but you mentioned clearmake. Open source projects should really try CONS. When you use the drived object cache it will automaticly grab any objects that someone else created and you know they are right. It has automatic dependancy scanning and doesn't use file timestamps so builds are MUCH more reliable.
And when it is fully cooked, SCONS will also be a good choice.
You have to understand benchmarking people. When they say kernels they mean benchmarking kernels. Small contained programs that extract key loops or algrothmns from larger programs.
They have a suite of keys loops where each is inportant to someone (fft, lloops, matrix mul, 3d geom, etc..) and determined that in general Proton (the internal codename) is much faster than GCC. Of course it is.
If only it was free. Unfortunatly, Intel built that compiler on several other companies IP and can't release the source.
Here is the first mention I could find of perl by Larry Wall. It is humorous because he is announcing the birth of his daughter Geneva Marie and lists perl has her sibling at age 3 months.
The first announcement of perl 1.0 is here .
Patches (a new concept!) followed shortly after that.
Slashdot Mirror
You have to remember what speculative execution really means. It means that your start fetching and executing the next intruction immediately even when you won't know the result of the previous instruction for 20-1000+ clocks. (If the previous inst missing the cache and goes to memory it might be gone a LONG time.) So if the previous instruction is a branch, you guess where it will go and keep going. If it turns out that you are wrong, then that instrution (and likely 100's of others) needs to be flushed from the machine and restarted.
So It does introduce a bubble, but it is a BIG one.
The branch predicter in the P4 is really amazing, but think of a loop to count the number of set bits in a 32-bit random number. (Bonus points if
you can portability code that function to have no branches!)
It is called RAID 5.
You can use partimage instead. It supports most filesystems on linux and saves a raw partition without saving empty blocks.
Must be nice.
I have 3Mbps for $200/month. But I live in the boonies and it is a fixed wireless connection.
Of course it is 3Mbps symetric with no restrictions on servers or such.
-Wayne
Perhaps you should have previewed that post at little longer? :-)
I almost hate to get sucked into this, but here goes...
What you said was "Wouldn't it be cool if the version system can show me who changed the return value of this function and why?" Answer: yes it is cool. But lets looks at something simpler. It would be cool if your version system can tell you who changed the current line and why. None of the systems being talked about here can.
Don't tell me about 'cvs annotate'. That is the other reason branching sucks in CVS. It totally trashes your history. After you merge a branch, the person who did the merge appears to have done all the work. The actual author of gets lost.
It takes people a while to really "get" what this buys you in BitKeeper, but after they understand it they are spoiled for life! Suddenly you don't use comments to understand code, you use the revision history...
Show me a "few employees with average qualifications" that can keep a server farm running under the load the ebay normally sees.
Get him to post a picture of the "swing" in his backyard and I think you will know the answer.
And when it is fully cooked, SCONS will also be a good choice.
You have to understand benchmarking people. When they say kernels they mean benchmarking kernels. Small contained programs that extract key loops or algrothmns from larger programs.
They have a suite of keys loops where each is inportant to someone (fft, lloops, matrix mul, 3d geom, etc..) and determined that in general Proton (the internal codename) is much faster than GCC. Of course it is.
If only it was free. Unfortunatly, Intel built that compiler on several other companies IP and can't release the source.
> Where do these college students get all this time to hack on the kernel? Don't they have to study at all?
I had tons of time in college. Too bad I spend it all writing borgs for netrek...
The first announcement of perl 1.0 is here . Patches (a new concept!) followed shortly after that.
-Wayne