Well, some does, but I am referring to those that don't, which is the majority at that. They tell the user what it will do, but in terms that are too obscure for most user to know what it means. Like Google.
They introduced a tool that lets you search your desktop from remote machines. They state at download that the tool copies data to their servers.
It is not hard to argue that this does not help all that much however. Notice how Firefox, IE and pretty much all browsers warn the first time you want to submit a form on a webpage (google web search perhaps) that this action will transmit data over the internet? Or pretty much all registration procedures for software, and tons of other little things. The fact is that people expect an application from a known vendor to not do something as stupid as copy the documents whole to their servers with only so little warning.
The fact is that the user did indeed choose it, however users also often install spyware. Yet we consider the spyware makers evil but Google good here.
I'd have to agree with the article that this feature was poor judgement on Google's part. Slashdot may consider it wrong to cater to the fact that people are a bit clueless with computers, but it is the truth and any serious software company must work with that in mind.
I suspect that most other people would be happy with a sub $6000 5:1 system from their local electrical outlet or nothing at all.
Do you see what you are saying here? A $6000 system, do you want people to live like animals? You are what is wrong with the world today, denying the common folk the very basics of civilized living.
I'd say that at this point it is much too early to claim that Intel is behind. As it currently stand their 1066 MHz FSB only manages to fill dual-channel 533MHz DDR2 granted, while there is fairly affordable 667MHz DDR2 out there (and not-very-affordable 800MHz), the Conroe which is not that far off now is expected to bump the FSB to 1333MHz, filling dual-channel 667MHz DDR2. This may then sound like a bad thing seeing how there is already faster memory out there, and AMD's hypertransport links scaling to insane speeds. As it happens though the AMD M2 processors will only have support for dual-channel 667MHz DDR2 ("only", it is pretty damn ridicolously much bandwidth), making them just match the capabilities of the Conroe.
Additionally DDR2 incurrs higher latencies than regular DDR, which is an advantage for Intel (although small) since the low-latency memory controllers on Athlon64's will have slightly less impact that way.
So: While Intels FSB situation might not have much headroom, while AMD has ample opportunity for bandwidth but no integrated controller that can use it. So the fact is that the whole of AMD's advantage is that they will be alone having 667MHz DDR2 between socket M2's release and the 1333MHz FSB Conroe, whereas Intel will have been alone with 533MHz DDR2 up until the release of socket M2 athlons.
It spreads via Windows shares if you run executables on other peoples shares. As in "stupidly run executables from untrusted sources". As in "it is a virus, not a worm". As in "stop spreading misinformation":)
First and foremost the change from 16 bit processors to 32 bit processors happened when the typical memory use and actual memory size had long since become far greater than what could be addressed without segmenting (16 bit addresses only gives you 64 kilobytes of addressable memory). As things stand now however it is quite rare among pros to need more than 3 gigabytes of memory for any one app, and no home user does. As it happens you don't actually get that much ram into the typical laptop anyway.
In a similar way the usefulness of 64 bit variables over 32 bit variables for integers is a lot less than going to 32 bit over 16. While one has to keep track of values larger than 65535 a lot of the time, the four billion as a maximal value for 32 bit is comfortably far away for a lot of tasks. Making actually operating on 64 bit integers rare enough that it is a non-existent win to go with them.
The actual feature that x86-64 has an impact on the typical user is the increased number of directly accessible registers, which does give a nice performance boost. What it comes down to then however is some straight benchmarks of whatever heavy apps one plans to run on it, it is not a killer application but rather a nice performance advantage.
Easy to say that they should "solve it", as far as I know no other platform has solved it. Only possible thing I can think of would be to only allow the OS to run appropriately digitally signed applications, which they have worked on, but that appears slightly impopular around Slashdot.
The story and summary are confused; This is not a worm, and what is discussed is not a patch for it. Blackworm is a regular old "run this fine file I have emailed you!"-trojan, so as long as people don't randomly run email attachments they are safe. What is not scheduled for release until the regular patch-cycle is the "removal tool" which is included in every patch-cycle. It just removes malicious software which has already sneaked onto the computer, in this case through user carelessness.
Some may argue that Microsoft should release a removal tool before the patch cycle anyway, and there is some credibility to the idea, though the logical extreme is that Microsoft should include an anti-virus program for free with Windows.
That said, anyone who buys a laptop and doesn't play games on it is better off sticking with Intel. There's no better chip when it comes to running the usual suspect win32 apps. But your 3D games will suffer.
Food for thought when your laptops integrated graphics chip is just starving for more frames to render.
If one does not manage to leverage the SIMD'ness though the performance suddenly becomes a whole lot less impressive even under ideal parallelized conditions. Even then considering the SPE's as proper PowerPC cores is quite flawed, the means of random-access memory access just don't exist on that level. They are very clearly intended to work with their 256 kilobytes of private memory and to pass small pieces between each other. Other than that they can DMA in a large block with high latency, but doing general purpose computation with random access will cause horrible performance.
Neural networks don't scale up in any terribly interesting way though, at least not in low-dimension problems like the ones featured in games. So the problem is not that the Cell can't do it, the problem is that you don't need a Cell to do it.
Doing separate AI over the game-state as a whole on each SPE is not a good way to go either since the SPE's means of memory access isn't that great, and memory access is where it hurts. The intent of the SPE's is very clearly to operate a lot on its little piece of private memory (256 kilobytes) and the data-passing between the SPE's, doing random-access work over the whole gamestate will work poorly.
IMHO OoO execution is not at all important for an embedded processor such as that found in a game system. Since the physical processor and system is known, instructions can be reordered by the compiler.
Hoping that the compiler will manage to do much useful is much too optimistic, it is true though that the Cell is quite doable in a game system compared to more generic settings.
Additionally the Cell is not a traditional vector processor. Each of the 8 nodes can be made completely independent, and can function in a sort of SMP mode. I took a class in Parallel Computer Architecture last semester and we covered the Cell processor in detail.
The cell is a bit of a hybrid, for one each of the SPE's is a SIMD processor, which one can consider a short vector processor, in addition the SPE's are set up to be able to work in sequence on a piece of data, which is pretty obviously a vector setting.
While coding for the cell is very different from coding for other cpus I don't think it will require massive amounts of programmer work -- just careful research and design.
Careful research and design is what takes time. Writing for a single SIMD unit in one of the more normal general purpose CPU's of today is tricky enough, daisy-chaining 8 is pretty damn tough.
The kind of problems that are feasible on the Cell in the scope of a game is really only algorithms that can be picked up from parallel computing research. Being able to actually develop any useful algorithm within the relativly short development cycles of games seems very unlikely.
Training neural nets is heavy floating point work, but evaluating them really isn't (though of course some games might really go for training while playing, doubtful if it really is feasible from any perspective though), however any neural net problem in a game will almost certainly be very low-dimensional. On thing if there were machine vision or such, but for the typical tasks (less than a thousand variables say) the Cell really wont be required.
Other than things like actually training neural nets and support vector machines though I don't really see anything terribly useful in AI actually requiring any particularly impressive amount of FP performance.
The problems you already stated, no branch prediction and no OoO is a huge deal already. But more importantly any algorithm that is naturally branch-heavy tends to be hard to parallelize and near impossible to vectorize, and the Cell needs both to be very useful.
Of course one can run anything on the 8 cores, but the fact is that for that type of tasks the Cell will be far from impressive while requiring ridiculously much programmer work.
What the hell are they going to the 7 cores for? If the graphics are all going to be done by an external chip this leaves an awfull lot of power for doing the rest of the game. Super advanced and massive amounts of AI? Fear with a hundred soldiers? Sure sure you will still be limited to a dozen lights but who cares. It is the AI that has been sorely lacking in recent games.
The Cell won't be terribly well suited for AI either, so you probably don't have much to look forward to. Game AI is typically notoriously branch-heavy and often tends to be mostly integer code (seeing how it is mostly search problems and at worst a neural net or two, no heavy stuff like machine vision since all information is already available). Which the Cell is more or less worthless for.
It annoys me greatly that the Cell is getting the hype it does, not only it is very specialized and as such hard to use, it is not even very innovative. One of the very first proper vector computers, the ILLIAC IV, was based on pretty much exactly the same approach. The Cell would at any rate be absolutely horrible as a general computing chip.
This is an interesting point, a lot of people will stick on a higher level no matter what you define the interface in. On the other hand it would clearly be bad to define the platform interfaces in Python, sure it would perform fine for 95% of all tasks (these are system calls and such to a great extent after all), but it would still be too inflexible in implementation. It is troublesome trying to wrap a powerful Python interface in a lot of languages and systems, even when not considering the language and call model features Python still has a lot of runtime features that show through (garbage collection is already in itself very troublesome at the system interface level).
The historical lowest common denominator solution has been to define it in C (though C++ has slowly crept up in the last decade) and then use higher-level bindings to make it easy to use. Gnome is a very modern system that has taken this approach. Apple on the other hand has went one step up on the abstraction ladder, they have kept the basic C interface style and linking behaviour but used the OO added by Objective C. The strong point here is that a lot of higher-level languages can now wrap much closer to the interface (getting close to a natural 1:1 mapping) while still retaining most of the possibility to go with C-style to-the-metal stuff. Objective C is even a nice enough language to make taking another step in abstraction unnecessary for a lot of people.
Personally I really like this. Defining the platform in C has aged (though it is still useful for maximum flexibility of implementation, though very archaic to use) but going straight for a high-level garbage-collected language is a step too far still. For example I think it would be a mistake to enforce a garbage collection model on the system level, removes much too many possibilities from the application. Add to this proper function pointer objects, co-routines, "global" reflection, continuations and so on and it becomes clear that too much power at the interface becomes a liability when it has to be fitted into another system.
This extra power is of course then a good thing for Python users on OSX just as for Objective C programmers. A straight wrapper around Cocoa is a lot nicer than say a straight wrapper around GTK+. Some may argue that this is unimportant since a "good" wrapper around GTK+ will be just as good, but personally I find that a wrapper that stays close to the unerlying interface is a very good thing when possible. Less bugs, often much more clarity, more available documentation, the skills one learns carry over if one switches languages and so on.
Man this post is long and rambling. Better push "Submit".
On the other hand that is one of the strengths of using Objective C. There are a lot of very competent codebases in C and C++ which you might want to run on the platform. Writing the extra interface glue in Objective C is a very straightforward thing when the rest of the code is in C/C++, no special gains to be done from going "pure" one way or the other.
.NET does try to make it as simple as possible to work together C/C++ and such classic platforms, but Objective C really has the edge when it comes to interoperability there. Throw in a small Objective C module to make it work nice on OSX and you are done.
Assuming that the whole of the app is going to be tailored for your platform is a luxury that only Microsoft can afford (and I have my doubts there too). So Apple maximizes the pontential here; Use the most powerful language you can while still sticking close to C/C++ interfaces.
Re:Thats the whole point of the "puzzler"
on
Java Puzzlers
·
· Score: 1
Why should a primitive byte be signed, but not a primitive char?
Because all numeric types are signed in Java, whereas char is not intended as a numeric type but rather a direct mapping to UTF-16 (which uses codepoints 0 through 65535). It makes perfect sense.
And why can't I have an unsigned int primitive in Java?
Highly debatable issue, but I think the simplification in types is worth more than unsigned types are.
Right, in the same sense that it is more natural to take a swig of batrachotoxin than of coca cola.
You are favoring a method that makes a huge (and most likely quite unpredictive) change in ecology over one that has no effect on nature because it involving plankton means it is "natural".
IF they did they would be violating MS intellectual property. Not only could they get sued everybody who used OO could be sued for patent violation by MS. MS has so far refused to grant a blanket patent grant despite being asked to do so.
The whole point of all the posts I have made so far is that Microsoft has a quite generous license allowing people to write applications against the Office schema.
I suppose you can think whatever you want. It seems like facts don't really enter into your thought process.
Seems comprehending what you read don't really enter into yours.
Slashdot Mirror
The Conroe here is the E6700, TDP under 65 watts (max for the mid-end E series).
The Athlon64 is a FX60, TDP of 110 watts at 2.6 GHz (whereas it is run at 2.8 GHz in the benchmarks).
Well, some does, but I am referring to those that don't, which is the majority at that. They tell the user what it will do, but in terms that are too obscure for most user to know what it means. Like Google.
It is not hard to argue that this does not help all that much however. Notice how Firefox, IE and pretty much all browsers warn the first time you want to submit a form on a webpage (google web search perhaps) that this action will transmit data over the internet? Or pretty much all registration procedures for software, and tons of other little things. The fact is that people expect an application from a known vendor to not do something as stupid as copy the documents whole to their servers with only so little warning.
The fact is that the user did indeed choose it, however users also often install spyware. Yet we consider the spyware makers evil but Google good here.
I'd have to agree with the article that this feature was poor judgement on Google's part. Slashdot may consider it wrong to cater to the fact that people are a bit clueless with computers, but it is the truth and any serious software company must work with that in mind.
Do you see what you are saying here? A $6000 system, do you want people to live like animals? You are what is wrong with the world today, denying the common folk the very basics of civilized living.
Additionally DDR2 incurrs higher latencies than regular DDR, which is an advantage for Intel (although small) since the low-latency memory controllers on Athlon64's will have slightly less impact that way.
So: While Intels FSB situation might not have much headroom, while AMD has ample opportunity for bandwidth but no integrated controller that can use it. So the fact is that the whole of AMD's advantage is that they will be alone having 667MHz DDR2 between socket M2's release and the 1333MHz FSB Conroe, whereas Intel will have been alone with 533MHz DDR2 up until the release of socket M2 athlons.
It spreads via Windows shares if you run executables on other peoples shares. As in "stupidly run executables from untrusted sources". As in "it is a virus, not a worm". As in "stop spreading misinformation" :)
B) no one infected with this worm is willing to admit it?
Do we care which? As long as they either don't do it anymore, or are smart enough to understand it when they do something wrong I am happy.
In a similar way the usefulness of 64 bit variables over 32 bit variables for integers is a lot less than going to 32 bit over 16. While one has to keep track of values larger than 65535 a lot of the time, the four billion as a maximal value for 32 bit is comfortably far away for a lot of tasks. Making actually operating on 64 bit integers rare enough that it is a non-existent win to go with them.
The actual feature that x86-64 has an impact on the typical user is the increased number of directly accessible registers, which does give a nice performance boost. What it comes down to then however is some straight benchmarks of whatever heavy apps one plans to run on it, it is not a killer application but rather a nice performance advantage.
Easy to say that they should "solve it", as far as I know no other platform has solved it. Only possible thing I can think of would be to only allow the OS to run appropriately digitally signed applications, which they have worked on, but that appears slightly impopular around Slashdot.
Some may argue that Microsoft should release a removal tool before the patch cycle anyway, and there is some credibility to the idea, though the logical extreme is that Microsoft should include an anti-virus program for free with Windows.
Luckily beta 3 promises to fix the bug that inserts "..." randomly in any HTML forms sent.
Food for thought when your laptops integrated graphics chip is just starving for more frames to render.
If one does not manage to leverage the SIMD'ness though the performance suddenly becomes a whole lot less impressive even under ideal parallelized conditions. Even then considering the SPE's as proper PowerPC cores is quite flawed, the means of random-access memory access just don't exist on that level. They are very clearly intended to work with their 256 kilobytes of private memory and to pass small pieces between each other. Other than that they can DMA in a large block with high latency, but doing general purpose computation with random access will cause horrible performance.
Doing separate AI over the game-state as a whole on each SPE is not a good way to go either since the SPE's means of memory access isn't that great, and memory access is where it hurts. The intent of the SPE's is very clearly to operate a lot on its little piece of private memory (256 kilobytes) and the data-passing between the SPE's, doing random-access work over the whole gamestate will work poorly.
Hoping that the compiler will manage to do much useful is much too optimistic, it is true though that the Cell is quite doable in a game system compared to more generic settings.
Additionally the Cell is not a traditional vector processor. Each of the 8 nodes can be made completely independent, and can function in a sort of SMP mode. I took a class in Parallel Computer Architecture last semester and we covered the Cell processor in detail.
The cell is a bit of a hybrid, for one each of the SPE's is a SIMD processor, which one can consider a short vector processor, in addition the SPE's are set up to be able to work in sequence on a piece of data, which is pretty obviously a vector setting.
While coding for the cell is very different from coding for other cpus I don't think it will require massive amounts of programmer work -- just careful research and design.
Careful research and design is what takes time. Writing for a single SIMD unit in one of the more normal general purpose CPU's of today is tricky enough, daisy-chaining 8 is pretty damn tough.
The kind of problems that are feasible on the Cell in the scope of a game is really only algorithms that can be picked up from parallel computing research. Being able to actually develop any useful algorithm within the relativly short development cycles of games seems very unlikely.
Other than things like actually training neural nets and support vector machines though I don't really see anything terribly useful in AI actually requiring any particularly impressive amount of FP performance.
Of course one can run anything on the 8 cores, but the fact is that for that type of tasks the Cell will be far from impressive while requiring ridiculously much programmer work.
The Cell won't be terribly well suited for AI either, so you probably don't have much to look forward to. Game AI is typically notoriously branch-heavy and often tends to be mostly integer code (seeing how it is mostly search problems and at worst a neural net or two, no heavy stuff like machine vision since all information is already available). Which the Cell is more or less worthless for.
It annoys me greatly that the Cell is getting the hype it does, not only it is very specialized and as such hard to use, it is not even very innovative. One of the very first proper vector computers, the ILLIAC IV, was based on pretty much exactly the same approach. The Cell would at any rate be absolutely horrible as a general computing chip.
The "Pick whatever you prefer" approach to usability is an old OSS sophism that most Linux distributions have long since abandoned.
And just imagine how user-friendly that would be. The reviewer would be so very pleased.
The historical lowest common denominator solution has been to define it in C (though C++ has slowly crept up in the last decade) and then use higher-level bindings to make it easy to use. Gnome is a very modern system that has taken this approach. Apple on the other hand has went one step up on the abstraction ladder, they have kept the basic C interface style and linking behaviour but used the OO added by Objective C. The strong point here is that a lot of higher-level languages can now wrap much closer to the interface (getting close to a natural 1:1 mapping) while still retaining most of the possibility to go with C-style to-the-metal stuff. Objective C is even a nice enough language to make taking another step in abstraction unnecessary for a lot of people.
Personally I really like this. Defining the platform in C has aged (though it is still useful for maximum flexibility of implementation, though very archaic to use) but going straight for a high-level garbage-collected language is a step too far still. For example I think it would be a mistake to enforce a garbage collection model on the system level, removes much too many possibilities from the application. Add to this proper function pointer objects, co-routines, "global" reflection, continuations and so on and it becomes clear that too much power at the interface becomes a liability when it has to be fitted into another system.
This extra power is of course then a good thing for Python users on OSX just as for Objective C programmers. A straight wrapper around Cocoa is a lot nicer than say a straight wrapper around GTK+. Some may argue that this is unimportant since a "good" wrapper around GTK+ will be just as good, but personally I find that a wrapper that stays close to the unerlying interface is a very good thing when possible. Less bugs, often much more clarity, more available documentation, the skills one learns carry over if one switches languages and so on.
Man this post is long and rambling. Better push "Submit".
Assuming that the whole of the app is going to be tailored for your platform is a luxury that only Microsoft can afford (and I have my doubts there too). So Apple maximizes the pontential here; Use the most powerful language you can while still sticking close to C/C++ interfaces.
Because all numeric types are signed in Java, whereas char is not intended as a numeric type but rather a direct mapping to UTF-16 (which uses codepoints 0 through 65535). It makes perfect sense.
And why can't I have an unsigned int primitive in Java?
Highly debatable issue, but I think the simplification in types is worth more than unsigned types are.
You are favoring a method that makes a huge (and most likely quite unpredictive) change in ecology over one that has no effect on nature because it involving plankton means it is "natural".
The whole point of all the posts I have made so far is that Microsoft has a quite generous license allowing people to write applications against the Office schema.
I suppose you can think whatever you want. It seems like facts don't really enter into your thought process.
Seems comprehending what you read don't really enter into yours.