"...that isn't any better that free ones but was deliberately designed to be noninteroperable with any other office suite..."
Two things: 1) Microsoft Office is usualy better for the average user, it has go a load of functions (of which half have never been touched), nice intuit handling of tables and such, the ability to get layout done quick'n dirty *or* using stylesdefinitions and such, 2) it is one-way noninteroperable, this is to lock customers to the Microsoft product. Actually, this is the Microsoft idea, this is was gives them their huge loads of cash: 1) take a standard, 2) add nice features, 3) claim to support the standard (they do), 4) read all, output unreadable (to others)...
I agree that the DOJ settlement was too weak, but remember, money talks (otherwise Bush wouldn't be the president, but the village fool). The only purpose for protecting them is that they do not only dominate the US market, but also the European, Asian and all other markets, which brings money into the US.
I very much support the efforts to create free alternatives. My problem is the lack of features and lack of scriptability. Also, basic user training is missing and lots of nice educational material. You must remember that for a corporation $300 per user isn't much if they can avoid paying for training (most users have used Office and (at least claim to) know it fairly well).
The response rate is the key to the whole operation, said Ralsky. These days, it's about one-quarter of 1 percent.
"But you figure it out," said Ralsky. "When you're sending out 250 million e-mails, even a blind squirrel will find a nut."
Has he never figured out that if he spewed out less shit to people not wanting it, he would have to spend less dollars on hardware, bandwidth and personal security.
Also, it looks like he is trying to hide (stealth spam, etc.). Why does he do that as he is claiming that his business is legitimate. Why not admit that he is a shit-bag, sending loads of e-mails nobody wants, eating bandwidth from research and serious commercial sites.
As they say that they're going to do it in a "petri dish" I assume that we will not see Frankenstein, but rather Flubber.
I though that this has been done part-way in simulations of earths early atmosphere using electic discharges. At least they made aminoacids that way (I think they did that).
Maybe you saw the movie Hotshots or something, but Migs and such tend to a) fly around friendly cities or b) fly over and bomb enemy cities. I would not concider them apropriate for inner city applications.
"...particularly suited to inner city applications... it lacks any ability to glide in the event of an engine outage"
No way, bad idea! I've seen more people that I need to running out of gas to recognize this as a *bad* idea. The ability to glide is *important* and very useful when things seriously seizes to function
This shows the vunerability of putting all computers in one building. To have a safe network one needs to spread (duplicate) the information over several computer at several locations. How far apart these locations has to be is depending on how important you data is.
It is a shame that a building hosting so many good initiatives should be the one to go, but as always: there is no excuse for not have a backup. By that I don't only mean that tape that always seems to go missing when needed, but multiple sites (or at least buildings) that provide redundancy.
I quote my self: "with an proven case of spam". If my ISP would log the time and date for each sent mail, they could verify the authenticity even better.
If you've ever been to Italy and seen the way they handle their Vespas, and where they try to drive them knows that "Seven mostly rural states have no prohibitions on the use of powered vehicles on sidewalks." could mean trouble.
Except from that, I think that it is nice to see that this actually became a product (or looks close to becoming). I doubted it earlier.
Tolerate no spamming what so ever. If one complain about a customer with an proven case of spam would arrive at a abuse department, shut that account down. There is no need to allow this, and no need to "warn" users doing this.
My ISP limits me from commersial activities at my homepage, why not limit the e-mail account from spamming.
The biggest problem today is that the price of spam is not charged from the spammer, but the poor user who recieves the shit. For all you americans out there, sue a spammer, make him/her pay for all loss of productivity he/she has caused. It'll make you rich, and perhaps make spammers think twice before clicking that send button.
Intel X-Scale Processor at 400MHz/300MHz, 32-64MB SDRAM Memory, 32-48MB Flash. Looks like it could run Linux quite easily. I've got a similar design just next to me here running it quite happily.
I choose to register to/. At/. one can still read and even comment the articles without being registered. NYT forces me into registering if I want to read their articles. It is nice to them to supply articles for free, but I do not think that/. should refer to their articles, thus "forcing" users into registering to be able to follow the debate (intelligently).
Now I get really tired. Usually someone indicates that the article is in the NYT (i.e. registration is required). In that case, I simply ignore the article. Why hasn't the editor noted this fact this time? Is/. promoting NYT or something.
If you refer to an NYT article, simply copy it into your submission so that we who do not want to register can read it by clicking "read more...".
"Most of the compiler's knowledge can be encoded into proper selection of the CISC instructions."
Nope, not which results are worth keeping and which are not (as the core has more register than are externally visible).
As for your next point ("largely irrelevant"), it depends. As pretty much all CPUs are the same today and they can perform pretty much the same functions the ISAs are largely irrelevant. But still, direct access to the RISC core is better than having to suffer a CISC ISA.
"...but that benefit would be lost if the core changes with each version of the chip."
That is correct, but if one would entierly skip the CISC ISA and put power into extracting huge amounts of ILP for a RISC processor one would get the best CPU.
" It uses something called EPIC (Explicitly Parallel Instruction Computing) which is a kind of virtualized VLIW/RISC ISA."
EPIC removes some of the problems when extracting the ILP, which is good. I would still say that a simple RISC with massive multiple issue and speculative execution combined with lots of gp regs and register renaming would be the best solution. This would give us simple compilers and less complex CPUs (compared to CISC -> RISC u-ops based x86 monsters:P ).
After having read the previous comments I'd like to post a reply to all of you.
Trolltech is a company selling a cross platform library called Qt. It is freely available under GPL and QPL for the Unix/X11 platform. The licensing costs for other platforms are there since Trolltech tries to make money from their product.
Many claim the Qt is bloated. This is because they do not see what Qt is. Qt is not a UI toolkit, it is an entire cross platform toolkit. That is why it includes most problem areas: sockets, file system access, database access, UI and much more.
The next set of common complaints is concering the STL usage. From Qt 3.x you can use STL together with Qt. Qt does however provide its' own classes for text, values, etc. This is to provide better cross platform support, for example QString supports unicode on all platforms. The QList and other container classes contain useful extensions compared with the STL containers.
As for language dependence. In professional software development C++ is the most commonly used language and will be for quite some time. The other language bindings available are great for developers wanting to use other languages, but they do not render much (or any) revenues to trolltech and is thus not interesting.
The signal/slot architecture used in Qt is also a thing to complain about. What does it do? It makes the code more intuit and estetic. It also speeds up the development (no need to declare struct/classes to pass arguments). Qt provides good debugging support to find all the dynamic errors that can arise from this. The architecture is (now) well tested and proven to work.
To sum things up: 1) Qt is a cross platform toolkit, not only a UI toolkit, 2) Trolltech wants to make profit, noone forces them inte giving the open source community access to Qt, be grateful, 3) the signal/slot architecture works in real life even though it is not the optimal solution from a philosophical point of view.
Ok, I was wrong concerning the P4. But still, I can not agree with you when you claim that the ISA is "largely irrelevant".
A compiler has more knowledge of the code than the CPU scheduler, thus, a compiler, given access to the inner RISC-like core, would be able to produce better code. For example, the scheduler cannot skip the calculation of irrelevant results forced into the code by a limiting CISC ISA. Also, it would (probably) be easier to write a good compiler for the RISC-like core, since it is bound to be more symetric (more gp regs, less restrictions in what op can be applied to what reg etc.).
"I think you have the impression that the traces are nothing but concatenated sequences of u-ops translated dumbly from the CISC instructions. I was under the impression that the hardware was capable of doing some straightforward optimizations on them."
I think that u-ops are, as you say, translated dymbly from the CISC ISA into RISC like ops. I've seen this an a computer architecture seminair, but you may be right. In that case, my points are less valid, but still, not totaly invalid.
"do things like register renaming once, and store the result in the trace cache, making that operation essentially free."
I'm not sure what you mean. I know that Transmeta uses a cache for the translated (or morphed) code, but (I believe that) P4s do it instruction by instruction.
"In effect, there's no reason the chip couldn't do more and more of the work of the compiler. That's essentially what Transmeta did."
The Transmeta chip (Crusoe) is not an intelligent chip. It is an (for the task highly optimized) VLIW CPU. The code morphing is done in software (compiled for the VLIW). The translated instructions are stored in a cache to avoid recompilation. The most unique feature of the Crusoe is that it emulates the internal state of the x86 (or any other CPU that it tries to emulate) thus saving loads of instructions to build condition flags etc.
"why can't I store something on the stack for a long time?"
If you want to keep a result, but then use it in further calculations too, this can be a problem. Perhaps you can pop it and push it twice, but it is still not a nice operation.
"Overflowing the stack is a matter of register pressure, which affects non-stack-based ISAs too."
Yes, it applies to noo-stack-based ISAs, but having 16, 32 och 64 (or any other number) or available general purpose fp registers compared to one top-of-the-stack register to work with restricts the code.
"These should get translated into the appropriate u-ops."
The get translated into more u-ops than needed. I said "forced into using a more complex instruction than needed". This wastes CPU resources.
"as you say, caches should make that relatively cheap"
I did not say (or at least not mean) relatively cheap. Cheaper that direct RAM access, but that is *expensive*.
"Those would disappear in the traces, if they do any kind of register renaming."
Still, you'll lose at least one cycle to do the actual renaming and this increases compiler complexity *alot*.
"Can the traces not eliminate extra spills, dups, swaps, and other artifacts of stack-based computation?"
No, since you cannot use the stack registers to hold information for a long time, but have to put it somewhere else (or recalculate). Direct access to a register based fp unit would enable more efficient code, even though the implementation of the current fp unit(s) is nice and fast.
"...they get the code density of CISC with the register usage and ABI models of RISC."
I have to admit that the big advantage of CISC ISAs is the code density. As memory bandwidth is growing into a problem, this is one way out. You can see this in the ARM Thumbs instructions too.
"Perhaps you could give an example of how the P4's internal u-op traces are sub-optimal because of the CISC ISA?"
I don't have the time to dig up a real example, but I can give you some hints. 1) Each time the compiler is forced into using a more complex instruction than needed because the simpler instruction isn't available in the ISA, 2) Stack handling imposed on the code by the lack of general purpose registers (the effect of this is somewhat reduced by caches), 3) mov instructions forced into the code by special purpose registers. Just to mention a few issues I have with CISC!
I have to agree that the P4 is a monster when it comes to transistor count and the PowerPC and the derivates are amazing. However, there will always be idle parts of the CPU core that can be shut down during different periods (for example fp ops.). Just since you have a simple (as in beatiful, optimized, etc) architecture does not mean that you should not further improve it by using state of the art optimization methods.
Each CISC instruction is transformed into a set of RIST instructions. These u-ops (micro-ops, Intel lingo) are then dynamically resceduled and register renaming and all such techniques are applied. I don't know if the P4 can manage out of order comitting, but the instructions are issued and executed in arbitrary order.
This gives that the internal state of the CPU will be complex and dynamic. This does however not indicate the there are no optimizations that can be made by removing the CISC abstraction layer.
For example, all fp operations on x86 CPUs emulate a stack based maths co-processors, which is implemented with real registers. Direct access to these can improve quality of the code tremendeously. When saying this, one must remember that the P4 bashes most CPUs in fp benchmarks, and can, most likely be even better with direct access.
To sum things up: I do not understand how you can say that a CISC layer does not slow the system down and that the ISA is "almost irrelevant". I have interpret that as pure ignorance.
"dont expect the battery life of a portable device improve by 100% when the power the CPU consumes goes down by 50%"
I don't, but Amdahl's law apply here too, reduce the biggest factor. You probably get a better yeild if you attach the CPU than any other device. These companies tend to evaluate the problems before attacking them (even though it doesn't seem so all the time).
Slashdot Mirror
"...that isn't any better that free ones but was deliberately designed to be noninteroperable with any other office suite..."
Two things: 1) Microsoft Office is usualy better for the average user, it has go a load of functions (of which half have never been touched), nice intuit handling of tables and such, the ability to get layout done quick'n dirty *or* using stylesdefinitions and such, 2) it is one-way noninteroperable, this is to lock customers to the Microsoft product. Actually, this is the Microsoft idea, this is was gives them their huge loads of cash: 1) take a standard, 2) add nice features, 3) claim to support the standard (they do), 4) read all, output unreadable (to others)...
I agree that the DOJ settlement was too weak, but remember, money talks (otherwise Bush wouldn't be the president, but the village fool). The only purpose for protecting them is that they do not only dominate the US market, but also the European, Asian and all other markets, which brings money into the US.
I very much support the efforts to create free alternatives. My problem is the lack of features and lack of scriptability. Also, basic user training is missing and lots of nice educational material. You must remember that for a corporation $300 per user isn't much if they can avoid paying for training (most users have used Office and (at least claim to) know it fairly well).
The response rate is the key to the whole operation, said Ralsky. These days, it's about one-quarter of 1 percent.
"But you figure it out," said Ralsky. "When you're sending out 250 million e-mails, even a blind squirrel will find a nut."
Has he never figured out that if he spewed out less shit to people not wanting it, he would have to spend less dollars on hardware, bandwidth and personal security.
Also, it looks like he is trying to hide (stealth spam, etc.). Why does he do that as he is claiming that his business is legitimate. Why not admit that he is a shit-bag, sending loads of e-mails nobody wants, eating bandwidth from research and serious commercial sites.
As they say that they're going to do it in a "petri dish" I assume that we will not see Frankenstein, but rather Flubber.
I though that this has been done part-way in simulations of earths early atmosphere using electic discharges. At least they made aminoacids that way (I think they did that).
Great news! I hope that you'll recover quickly so that everything will be up and running!
Maybe you saw the movie Hotshots or something, but Migs and such tend to a) fly around friendly cities or b) fly over and bomb enemy cities. I would not concider them apropriate for inner city applications.
"...particularly suited to inner city applications ... it lacks any ability to glide in the event of an engine outage"
No way, bad idea! I've seen more people that I need to running out of gas to recognize this as a *bad* idea. The ability to glide is *important* and very useful when things seriously seizes to function
This shows the vunerability of putting all computers in one building. To have a safe network one needs to spread (duplicate) the information over several computer at several locations. How far apart these locations has to be is depending on how important you data is.
It is a shame that a building hosting so many good initiatives should be the one to go, but as always: there is no excuse for not have a backup. By that I don't only mean that tape that always seems to go missing when needed, but multiple sites (or at least buildings) that provide redundancy.
I quote my self: "with an proven case of spam". If my ISP would log the time and date for each sent mail, they could verify the authenticity even better.
I do 1-2 flops if I get easy numbers...
If you've ever been to Italy and seen the way they handle their Vespas, and where they try to drive them knows that "Seven mostly rural states have no prohibitions on the use of powered vehicles on sidewalks." could mean trouble.
Except from that, I think that it is nice to see that this actually became a product (or looks close to becoming). I doubted it earlier.
Tolerate no spamming what so ever. If one complain about a customer with an proven case of spam would arrive at a abuse department, shut that account down. There is no need to allow this, and no need to "warn" users doing this.
My ISP limits me from commersial activities at my homepage, why not limit the e-mail account from spamming.
The biggest problem today is that the price of spam is not charged from the spammer, but the poor user who recieves the shit. For all you americans out there, sue a spammer, make him/her pay for all loss of productivity he/she has caused. It'll make you rich, and perhaps make spammers think twice before clicking that send button.
Intel X-Scale Processor at 400MHz/300MHz, 32-64MB SDRAM Memory, 32-48MB Flash. Looks like it could run Linux quite easily. I've got a similar design just next to me here running it quite happily.
I've user ReiserFS since it first appeared in Mandrakes distro. I have never had any problems what so ever with it. It just keeps running.
I too enjoyed this discussion. See you next time the subject comes up! :-)
I choose to register to /. At /. one can still read and even comment the articles without being registered. NYT forces me into registering if I want to read their articles. It is nice to them to supply articles for free, but I do not think that /. should refer to their articles, thus "forcing" users into registering to be able to follow the debate (intelligently).
Now I get really tired. Usually someone indicates that the article is in the NYT (i.e. registration is required). In that case, I simply ignore the article. Why hasn't the editor noted this fact this time? Is /. promoting NYT or something.
If you refer to an NYT article, simply copy it into your submission so that we who do not want to register can read it by clicking "read more...".
"Most of the compiler's knowledge can be encoded into proper selection of the CISC instructions."
Nope, not which results are worth keeping and which are not (as the core has more register than are externally visible).
As for your next point ("largely irrelevant"), it depends. As pretty much all CPUs are the same today and they can perform pretty much the same functions the ISAs are largely irrelevant. But still, direct access to the RISC core is better than having to suffer a CISC ISA.
"...but that benefit would be lost if the core changes with each version of the chip."
That is correct, but if one would entierly skip the CISC ISA and put power into extracting huge amounts of ILP for a RISC processor one would get the best CPU.
" It uses something called EPIC (Explicitly Parallel Instruction Computing) which is a kind of virtualized VLIW/RISC ISA."
EPIC removes some of the problems when extracting the ILP, which is good. I would still say that a simple RISC with massive multiple issue and speculative execution combined with lots of gp regs and register renaming would be the best solution. This would give us simple compilers and less complex CPUs (compared to CISC -> RISC u-ops based x86 monsters :P ).
After having read the previous comments I'd like to post a reply to all of you.
Trolltech is a company selling a cross platform library called Qt. It is freely available under GPL and QPL for the Unix/X11 platform. The licensing costs for other platforms are there since Trolltech tries to make money from their product.
Many claim the Qt is bloated. This is because they do not see what Qt is. Qt is not a UI toolkit, it is an entire cross platform toolkit. That is why it includes most problem areas: sockets, file system access, database access, UI and much more.
The next set of common complaints is concering the STL usage. From Qt 3.x you can use STL together with Qt. Qt does however provide its' own classes for text, values, etc. This is to provide better cross platform support, for example QString supports unicode on all platforms. The QList and other container classes contain useful extensions compared with the STL containers.
As for language dependence. In professional software development C++ is the most commonly used language and will be for quite some time. The other language bindings available are great for developers wanting to use other languages, but they do not render much (or any) revenues to trolltech and is thus not interesting.
The signal/slot architecture used in Qt is also a thing to complain about. What does it do? It makes the code more intuit and estetic. It also speeds up the development (no need to declare struct/classes to pass arguments). Qt provides good debugging support to find all the dynamic errors that can arise from this. The architecture is (now) well tested and proven to work.
To sum things up: 1) Qt is a cross platform toolkit, not only a UI toolkit, 2) Trolltech wants to make profit, noone forces them inte giving the open source community access to Qt, be grateful, 3) the signal/slot architecture works in real life even though it is not the optimal solution from a philosophical point of view.
All above is MHO. I do not mean to flame anyone!
Ok, I was wrong concerning the P4. But still, I can not agree with you when you claim that the ISA is "largely irrelevant".
A compiler has more knowledge of the code than the CPU scheduler, thus, a compiler, given access to the inner RISC-like core, would be able to produce better code. For example, the scheduler cannot skip the calculation of irrelevant results forced into the code by a limiting CISC ISA. Also, it would (probably) be easier to write a good compiler for the RISC-like core, since it is bound to be more symetric (more gp regs, less restrictions in what op can be applied to what reg etc.).
"I think you have the impression that the traces are nothing but concatenated sequences of u-ops translated dumbly from the CISC instructions. I was under the impression that the hardware was capable of doing some straightforward optimizations on them."
I think that u-ops are, as you say, translated dymbly from the CISC ISA into RISC like ops. I've seen this an a computer architecture seminair, but you may be right. In that case, my points are less valid, but still, not totaly invalid.
"do things like register renaming once, and store the result in the trace cache, making that operation essentially free."
I'm not sure what you mean. I know that Transmeta uses a cache for the translated (or morphed) code, but (I believe that) P4s do it instruction by instruction.
"In effect, there's no reason the chip couldn't do more and more of the work of the compiler. That's essentially what Transmeta did."
The Transmeta chip (Crusoe) is not an intelligent chip. It is an (for the task highly optimized) VLIW CPU. The code morphing is done in software (compiled for the VLIW). The translated instructions are stored in a cache to avoid recompilation. The most unique feature of the Crusoe is that it emulates the internal state of the x86 (or any other CPU that it tries to emulate) thus saving loads of instructions to build condition flags etc.
"why can't I store something on the stack for a long time?"
If you want to keep a result, but then use it in further calculations too, this can be a problem. Perhaps you can pop it and push it twice, but it is still not a nice operation.
"Overflowing the stack is a matter of register pressure, which affects non-stack-based ISAs too."
Yes, it applies to noo-stack-based ISAs, but having 16, 32 och 64 (or any other number) or available general purpose fp registers compared to one top-of-the-stack register to work with restricts the code.
"These should get translated into the appropriate u-ops."
The get translated into more u-ops than needed. I said "forced into using a more complex instruction than needed". This wastes CPU resources.
"as you say, caches should make that relatively cheap"
I did not say (or at least not mean) relatively cheap. Cheaper that direct RAM access, but that is *expensive*.
"Those would disappear in the traces, if they do any kind of register renaming."
Still, you'll lose at least one cycle to do the actual renaming and this increases compiler complexity *alot*.
"Can the traces not eliminate extra spills, dups, swaps, and other artifacts of stack-based computation?"
No, since you cannot use the stack registers to hold information for a long time, but have to put it somewhere else (or recalculate). Direct access to a register based fp unit would enable more efficient code, even though the implementation of the current fp unit(s) is nice and fast.
"...they get the code density of CISC with the register usage and ABI models of RISC."
I have to admit that the big advantage of CISC ISAs is the code density. As memory bandwidth is growing into a problem, this is one way out. You can see this in the ARM Thumbs instructions too.
"Perhaps you could give an example of how the P4's internal u-op traces are sub-optimal because of the CISC ISA?"
I don't have the time to dig up a real example, but I can give you some hints. 1) Each time the compiler is forced into using a more complex instruction than needed because the simpler instruction isn't available in the ISA, 2) Stack handling imposed on the code by the lack of general purpose registers (the effect of this is somewhat reduced by caches), 3) mov instructions forced into the code by special purpose registers. Just to mention a few issues I have with CISC!
I have to agree that the P4 is a monster when it comes to transistor count and the PowerPC and the derivates are amazing. However, there will always be idle parts of the CPU core that can be shut down during different periods (for example fp ops.). Just since you have a simple (as in beatiful, optimized, etc) architecture does not mean that you should not further improve it by using state of the art optimization methods.
Each CISC instruction is transformed into a set of RIST instructions. These u-ops (micro-ops, Intel lingo) are then dynamically resceduled and register renaming and all such techniques are applied. I don't know if the P4 can manage out of order comitting, but the instructions are issued and executed in arbitrary order.
This gives that the internal state of the CPU will be complex and dynamic. This does however not indicate the there are no optimizations that can be made by removing the CISC abstraction layer.
For example, all fp operations on x86 CPUs emulate a stack based maths co-processors, which is implemented with real registers. Direct access to these can improve quality of the code tremendeously. When saying this, one must remember that the P4 bashes most CPUs in fp benchmarks, and can, most likely be even better with direct access.
To sum things up: I do not understand how you can say that a CISC layer does not slow the system down and that the ISA is "almost irrelevant". I have interpret that as pure ignorance.
"dont expect the battery life of a portable device improve by 100% when the power the CPU consumes goes down by 50%"
I don't, but Amdahl's law apply here too, reduce the biggest factor. You probably get a better yeild if you attach the CPU than any other device. These companies tend to evaluate the problems before attacking them (even though it doesn't seem so all the time).