Which gets back to my first point, if more people used SMP then there would be better cheeper SMP system out there. since SMP isn't a consumer product the only kit out there is very expensive.
As for performance, compaire the ASCI programs with the Earth simulator.
Well, your kind of wrong. X86 is crap for SMP, mainly because of the way memory and cach are handled. I wouldn't put more than 4 x86's in an SMP configuration.
Other architectures support point to point busses and better cache handeling more memory chanels/controlers etc... you could probably scale to 100 or so processors with that type of architecture.
Now, if some of the patents cray has were available then you can scale to thousands of processors, where memory controlers record pages that have been writen to and only sync on demand (when there's a read request page that's been writen to by another processor)
Basicly x86 sucks for SMP (which is probably why it's such a cheep architecture).
Your missing out: Latency, Mosix is just too un-responsive compaired to an SMP option. Time, The more people that buy SMP boxes the better they will get, the MHz wars and Windows killed of home SMP if Intel had invested in SMP design instead of MHz then there'd be cheeper cooler SMP machines out there.
I'm probably more wealthy then most people on/. since there is very little I want. I have too much money, far more than I could spend though probably not enough for most people.
I think Bill has problems stringing sentences together, after all he droped out.
Me Bill, Me sell Windows and Office Bill need Money, Bill buy Money, Bill need database Bill buy SQL Server Inovation big Word, Bill like Inovation and Bill like Word, Bill say inovation lots.
After reading the review I didn't know what the book was 'about', sure it sounded interesting, interesting enough to take a look at the web site.
This book appears to present methods of managing and analysing data so that you can 'solve' the problem without getting bogged down.
I would recommend giving this book a look over for the following reasons.
I do a great deal of analysis work and a lot of the concepts in the TOC sound familiar. The logical approach the book appears to present should help you fine tune your analysis and hopefully identify some areas where you've been slipping.
And for a lot of people the perfect gift would be to not have to have a Job. A nice little commune, out in the countryside, where you're free to do what you want. Ahh a perfect XMas
The users report some apparent bugs in the software.
The process that causes the bug is identified, say cancelling an order.
Scripts are produced to identify the BUG, they also provide a way for checking for associated bugs.
If the BUG is trivial then the software is corrected and tested using the above scripts.
If the BUG is non-trivial (e.g. a design flaw) then associated areas are reviewed, and sometimes the whole process needs to be redesigned or corrected.
If there's a reasonable amount of work in correcting the bug and the code's a bit crap then the code gets refactored.
Whenever a BUG is found a check is made for any similar bugs.
Changes are tracked in sourcecontrol and refer back to the bug any test scripts and design documentation.
Most of the processes can be impleneted at the pre-design/design stages of a project, except the bugs are thigs like, the application must do this, there should be far less refactoring and a lot more coding.
How else are you supposed to write good high quality software?
I can write a few thousand lines of code, and pritty much gaurentee that it will work (after a few minor typos &co have been corrected).
The methods I use aren't much different from the method I mentioned (just on a higher level), I will track down the people who are supposed to know the business process answers and kick people until inconsistancies are resolved(usually by asking them why they want this, and then refining there reasones into an design).
I write modular code and test each module in isolation. And yes I frequently write 'test' code as case studdies as part of the documentation.
The majority of the work I do is fixing design flaws in other peoples applications often doing large amounts of refactoring and documenting business processes that were missunderstood or poorly implented the first time around.
hmmm... Not always. Hell I'm almost 30 and not dead yet, I think I can put up with another 30years? Unless we turn into more fascist world, in which case suicide bomb here I come.
You can build software like a house. It's just that the master plan is never good enough.
Say I produce a master plan for a few classes./*Master plan by oliverthered*/ class masterplan public: {
public:
& plans(int planid);
& plans( planname);
protected: etc.... }......
A developer should be able to work on that plan without 'assistance'
Say I decide to write
plan& plans(int planid); well I know there needs to be a private collection some plans so i implement
Someone else comes along to implement plans(string planname) they notice that oliverthered2 may not have done the best implementation of plans(int) so they contact oliverthered(who wrote the masterplan) and oliverthered2(who done some implementation) etc.......
If OSS implmeneted that kind of design/implemtation practice then you could write software with everyone laying down a brick at a time.
Well, maybe your timescales are a little short, there's a lot of protine folding required in designing a lifeform. I'd say 40-50 years before that can be done +10/20 years for the 'home' version. So I might see it before I die(or kill myself)
Slashdot Mirror
'particular if the market for it is so small'
Which gets back to my first point, if more people used SMP then there would be better cheeper SMP system out there. since SMP isn't a consumer product the only kit out there is very expensive.
As for performance, compaire the ASCI programs with the Earth simulator.
"you can't scale SMP indefinitely."
Well, your kind of wrong.
X86 is crap for SMP, mainly because of the way memory and cach are handled. I wouldn't put more than 4 x86's in an SMP configuration.
Other architectures support point to point busses and better cache handeling more memory chanels/controlers etc... you could probably scale to 100 or so processors with that type of architecture.
Now, if some of the patents cray has were available then you can scale to thousands of processors, where memory controlers record pages that have been writen to and only sync on demand (when there's a read request page that's been writen to by another processor)
Basicly x86 sucks for SMP (which is probably why it's such a cheep architecture).
go visit the register
Well
my typing's quick, but my spelling is poor.
My speech is, ummm.... incomprehensible at times and I frequently sound like a cave man.
I think I'll stick to the keyboard, at least I can be understood that way, well maybe just about.
Nope, It's on a TV stand ;->
RF keyboards and Mice are handy, no leads running accross the living room.
oh, and I have a rocking chair.
Awesome graphics, nope TV's too crap ,low res, low frame rate.
Internet multiplayer support, but no lan parties?
Play in your comfortable living room, and my PC is, umm, in the living-room where my hifi used to be.
System = same price as a mid range pc video card, check, games at twice the price check.
Largest selection of games? hmm.... I still play low-fi games, and have a huge selection of low-fi PC games.
Your missing out:
Latency, Mosix is just too un-responsive compaired to an SMP option.
Time, The more people that buy SMP boxes the better they will get, the MHz wars and Windows killed of home SMP if Intel had invested in SMP design instead of MHz then there'd be cheeper cooler SMP machines out there.
I've seen many a BSOD or login prompt on ATM's that are running windows.
well, I suppose it's a good thing that Microsoft got a light telling off. A modular Windows would have increased there monopoly.
try replacing wealthy with greedy.
/.
I'm probably more wealthy then most people on
since there is very little I want. I have too much money, far more than I could spend though probably not enough for most people.
You know how that Eve ate the Apple and turned Babylon into the Axis of evil Iraq and Iran
I think Bill has problems stringing sentences together, after all he droped out.
Me Bill,
Me sell Windows and Office
Bill need Money,
Bill buy Money,
Bill need database
Bill buy SQL Server
Inovation big Word, Bill like Inovation and Bill like Word, Bill say inovation lots.
On the old 5HTP again, well I hope it makes you happy?.
I prefer psilocybin .
Where?
After reading the review I didn't know what the book was 'about', sure it sounded interesting, interesting enough to take a look at the web site.
This book appears to present methods of managing and analysing data so that you can 'solve' the problem without getting bogged down.
I would recommend giving this book a look over for the following reasons.
I do a great deal of analysis work and a lot of the concepts in the TOC sound familiar.
The logical approach the book appears to present should help you fine tune your analysis and hopefully identify some areas where you've been slipping.
And maybe a list of waiting/compatable patches too, so if you have hardware that isn't supported by the stock kernel you can find the patch.
Hmm.. I don't think you've tried Borland tools for quite some time.
Kylix gives you:
Just-in-time compiling so you can modify your code whilst debugging.
A far better syntax for even-handeling.
A seriously good RAD UI. you havn't seen rad till you've used Kylix/CBuilder &co.
Type sensitive code compleation.
Good ANSI compliance.
Cross platform development (including mobile devices)
the list goes on.....
I do like QT and I use it a lot but Borlands tools are the best.
And for a lot of people the perfect gift would be to not have to have a Job. A nice little commune, out in the countryside, where you're free to do what you want. Ahh a perfect XMas
Well it goes something like this.
The users report some apparent bugs in the software.
The process that causes the bug is identified, say cancelling an order.
Scripts are produced to identify the BUG, they also provide a way for checking for associated bugs.
If the BUG is trivial then the software is corrected and tested using the above scripts.
If the BUG is non-trivial (e.g. a design flaw) then associated areas are reviewed, and sometimes the whole process needs to be redesigned or corrected.
If there's a reasonable amount of work in correcting the bug and the code's a bit crap then the code gets refactored.
Whenever a BUG is found a check is made for any similar bugs.
Changes are tracked in sourcecontrol and refer back to the bug any test scripts and design documentation.
Most of the processes can be impleneted at the pre-design/design stages of a project, except the bugs are thigs like, the application must do this, there should be far less refactoring and a lot more coding.
How else are you supposed to write good high quality software?
I can write a few thousand lines of code, and pritty much gaurentee that it will work (after a few minor typos &co have been corrected).
The methods I use aren't much different from the method I mentioned (just on a higher level), I will track down the people who are supposed to know the business process answers and kick people until inconsistancies are resolved(usually by asking them why they want this, and then refining there reasones into an design).
I write modular code and test each module in isolation. And yes I frequently write 'test' code as case studdies as part of the documentation.
The majority of the work I do is fixing design flaws in other peoples applications often doing large amounts of refactoring and documenting business processes that were missunderstood or poorly implented the first time around.
hmmm... Not always. Hell I'm almost 30 and not dead yet, I think I can put up with another 30years? Unless we turn into more fascist world, in which case suicide bomb here I come.
You can build software like a house. It's just that the master plan is never good enough.
/*Master plan by oliverthered*/ ......
/*oliverthered2*/ /*oliverthered2*/
Say I produce a master plan for a few classes.
class masterplan public: {
public:
& plans(int planid);
& plans( planname);
protected:
etc....
}
A developer should be able to work on that plan without 'assistance'
Say I decide to write
plan& plans(int planid);
well I know there needs to be a private collection some plans so i implement
protected:
vector vplans;
public:
plan& plans(int planid) excepts elementnotfound{
try{
return vplans[planid];
}catch(...){
throw (new elementnotfound("Plans",planid);
}
};
And update the master plan
class masterplan public: plan{
private
vector vplans;
public:
plan& plans(int planid);
plan& plans(string planname);
protected:
etc....
}
Someone else comes along to implement plans(string planname)
they notice that oliverthered2 may not have done the best implementation of plans(int) so they contact oliverthered(who wrote the masterplan) and oliverthered2(who done some implementation)
etc.......
If OSS implmeneted that kind of design/implemtation practice then you could write software with everyone laying down a brick at a time.
That would be the case, but unfortunatly, there are only a few people who can play 'games' with real-life.
You havn't seen my code ;-?
Well, maybe your timescales are a little short, there's a lot of protine folding required in designing a lifeform. I'd say 40-50 years before that can be done +10/20 years for the 'home' version. So I might see it before I die(or kill myself)
Remember the phone network outage from maybe 10years ago.
A fault in the initial system caused the network to go down, and the backup was switched on.
Unfortunatly the backup had exactly the same fault, the software had to be corrected before the network could be brought back online.