The points were indicating the drawbacks from expanding instructions sets (further). I understand that it can be read as being a part of the conclusion, but I did not intend it that way.
When discussing what ISA the compiler sees I can't help wondering how efficient code a compiler could emit if it gained access to the risc cores of a P4 or a Tbird? Maybe it is time to introduce another mode (after protected mode of the 386): RISC mode (or, as intel's marketeers would call it PowerMode(tm):])
Another advantage of the ARM is the Thumb instructions that reduces the traffic over the memory bus. We must remember that driving memory bus is an expensive operation (power wise) compared to finding data in the cache. Smaller code means more code in the cache. One problem is that multimedia applications (such as movies, music, etc) fails to utilize the cache well (since the data isn't re-accessed). This is a problem area that needs more research.
How is it then that we do not see standard CPUs with custom portable devices?
You are correct when you say that backlit displays, disk drives, CD players and such consumer much power, but so does also all transistor switches (from on to off and the other way around). The sheer number of transistors and the incredible frequency of these switches makes the CPU one of the power hogs in a portable system today.
Very true. Look at this for a laugh. A minimal installation will take approx. 120MB of disk space and 40MB of RAM. I can't help wondering what they are doing over there (at M$).
I'd say that SPARC VI and VII will be more innovative (article here). I must say that ARM is not the *only* architecture used for innovative CPU designs. In academia I've seen both MIPS, SPARCs and custom designs to show/implement special innovations (vector co-processors, async logic, etc.) Usually small subsets of commersial CPUs are used for the truly innovate designs. (IMHO)
This lagging is not due to flaws in the ISA (instruction set architecture). Todays CISC cpus (atleast the post-Pentiums and Athlons) are RISCs with a CISC shell.
The expansion of instruction sets have two drawbacks: 1) bloated designs and 2) more and more complex compilers. That is why RISC is leading the way (in a CISC suite) and CISC is degraded into keyboard controllers etc.
That is one method of doing it (turning of clock trees to shut down a set of gates). One other way is to adjust the supply voltage and clock frequency to the CPU core. As ARM allready utilizes clock gating, the voltage/frequency technique is a very viable option for even more efficient CPUs. I'm usually not a big fan of Intel's, but look at their XScale and the measures they've taken to preserve energy. I have to say that I'm impressed!
When developing portable devices the most limiting factor today is not processing resources, memory or anything such. It is simply the power source.
Batteries of today are either too weak or too heavy. How ofter does one have to choose between a slim-line battery or an ultra-long life.
There have been many suggestions for competing technologies such as fuelcells, harvesting of motion energy and solar cells to mention a few. But still, they have proven to be too expensive, large or have some other problem (such as not being ready for production use yet). Hopefully these one of these, or any other, portable power sources will make it possible to carry real computing power without having to carry a heavy battery pack.
The solution today is to reduce the power usage. This can be done by shutting down parts of the clock trees in the CPUs, or by using Intel's PowerStep (i.e. two working speeds), or Transmetas's variable voltage and frequency technology, LongRun. As the article lacks technical details we can only guess about the techniques used behind the PowerWise solution. Also, the figures 25-75% efficiency gain is most probably measured under special conditions.
But, in order to avoid sounding too negative, it seems like the industry has realized the problem and are working for a solution. I feel that most of today's solutions (power saving) are just a cure for the symptoms (bad battery time), not for the cause (bad battery technology).
If you would supply me with contact information, maybe we could discuss this. I feel that moderators should not doubt he facts supplied by the submitters, but rather value the information as if it is true.
I think that it is nice to see moderators yelling, flaming and behaving generally bad (yes, I mean that you do that). Tell me who you are and we can have a discussion concerning me working or not.
As for your comments about my employment. I have not said that the company I work for is "Extremely Important(tm)", I just said that we have needs for lagre computations and have invested in a Linux-based system. I am not " karma whoring by spouting bullshit", if you do not like my comments, simply mark me as a foe, and add -2 to my comments, do not mod me down simply because you have problems trusting people!
Yes! I used the cluster to compute the correct amount of water for each plant, considering cloudiness, temperature, time in direct sun light and how far each particular plant had grown.:)
Were I work (I can't say where... I've signed papers...) we have replaced an SGI 'super computer' (or mini computer, whatever, a big number crunching beast of silicon!) with a Beowulf cluster. This not only gives us great scaleability, but also lots of FLOPS per dollar (or rather, krona:^P).
To say that 'I do not need to know that' or 'that will not make me a better professional' is just ignorance. Even though you might just squeeze out a small speedup, you can probably make your software more valuable to your users (who can keep their old hardware a bit longer).
I find the (today) common attitude of bloated code being ok, and abstraction for the developers instead of performance for the users being the priorities a bit annoying. It might be because I do much work in real time environments, but also because I fail to see why people accept the they need the latest hardware to run a simple word processor at decent speed.
Please do not take me wrong. Nothing that I say is not meant personally. But I have to insist the knowledge of hardware, at least how caches, TLBs, branch predictions, ILP works, but also insight into the penalties and benfits of threads and separate processes, is required if one is to make a good software engineer. This may not be a requirement in the administrative computing sector, but will greatly help to improve the code quality.
I hope that we can stop this flamewar here and now, since we have totaly lost track of the original discussion: whether a good UI is an abstraction of everyday things and tools, or a layer over the actual computer hardware reflecting its internal workings.
"most OS projects are better off without a pointy-haired boss and his bureaucracy"
I'd say that most projects would benefit from a general plan stating which features that are wanted and for whom the project is intended. As soon as a project grows from 5-10 developers a more controlled development process will be needed if to avoid bloat and general confusion about what the project is supposed to do.
One of the main problems when bringing GNU/Linux to the desktop is actually the huge number of options. If projects were better narrowed down, and more structured, most of these options could be hidden, or atleast bundled. Open source does need far better project management than is common today!
Looks nice! Can it run linux, it seems to have the required HW. I wounder if it has a bitmapped screen, or some custom. I'd love to run bash from it and have an IrDA keyboard...
Lack of predictability (both feature and time wise).
There are many points here, but one of the most important is the lack of a plan. It would greatly benefit most OSS projects if there was a plan of features to be implemented. This would not only tell users and project members where the project is heading, but also prevents eyecandy and other code bloating problems to enter the project too early. It would be good if a feature had to be on the TO-DO list to be included into the project source tree. This way each feature has to be discussed, specified and granted before being implemented. This helps building more consistent software.
The second problem, peer reviewing, could be solved by including it in the code versioning system (hense the subject of this reply...). All code must be tested and reviewed by an independen peer before included in the source tree. By introducing automatic testing, such as a small test bench application showing that the submission works, modularity is encouraged. By introducing good modularity, new patches are more easily tested and included in the source tree.
The last point is mainly a project management issue. Someone has to say that these features will be available at this date in this release. This problem is simply the addition of time to the first problem (a plan). This is the thoughest challenge when working with spare-time programmers. Not many will be happy about commiting to a project, then being forced to keep a time plan. Anyway, this can be enforced in the big, with partially paid work-time, projects.
"I don't need to know this stuff for the application development I do in Java or C++."
But you'll be able to produce better code if you do know this stuff.
"...I don't think it is at all obvious to joe user how it works. All they know is that they can set it for a specific length of time, and maybe different power levels..."
And this is how it works, to average Joe.
"they don't need to know about disk caches, or saving in blocks rather than bytes, or CPU cycles"
No need to bring in caches etc. But it helps if they understand that you have to save files, etc. It would make it easier to understand that somethings are missing after a power failure etc. Also, this is a power, since you can edit a document and then save it in another name or discard it. It helps the user take advantage of benefits of the computer approach. I think that this is good, compared to limiting the user to 'real world operations.'
I know that this can turn into a heated discussion, but I feel that some usability guys need to cool down a bit and let computers have a certain technical level (perhaps the one of today). This gives advantages since you don't have to limit your self to the real world metaphor, but can introduce certain advantages of the technology.
I think that the interface of a microwave oven pretty much shows how the machine works, as does the interface of TVs, VCRs, etc. Why must we go to such length to make a computer look more like things it is not. It will not reduce the need for training before use, but reduce the understanding, and thus the ability to cope with new situations and applications.
The interfaces of today represent how a computer actually work. For example, the need to save a document. This is not a bad thing if done properly, in fact, it helps (forces) the users to understand how the actual machine works (it writes periodically to the disk, and not one character at a time).
When saying this I'm not saying that there are flaws in the interfaces of today, and I do agree on that the open source movement lack much of the initiative to make things better. However, making all computer tasks behave as things in 'the real world' will not work. I'm not even sure if all metaphors used today are good. It's better to reflect the actual tool, than try to make it look like something that it is not, this will only result in disapointed and surprised users.
This guy can't be real. No-one can be *that* stupid! How does he intend to recieve his 3D files without an OS? Does he know how a computer work? Is he on drugs? What's his "education"? Does he actually get paid for saying these things?
As for publishing links NYT articles here on slashdot, why-o-why is it allowed. I urge the inclusion of a bypass link too, or a link to the article somewhere else!
Slashdot Mirror
The points were indicating the drawbacks from expanding instructions sets (further). I understand that it can be read as being a part of the conclusion, but I did not intend it that way.
When discussing what ISA the compiler sees I can't help wondering how efficient code a compiler could emit if it gained access to the risc cores of a P4 or a Tbird? Maybe it is time to introduce another mode (after protected mode of the 386): RISC mode (or, as intel's marketeers would call it PowerMode(tm) :])
Another advantage of the ARM is the Thumb instructions that reduces the traffic over the memory bus. We must remember that driving memory bus is an expensive operation (power wise) compared to finding data in the cache. Smaller code means more code in the cache. One problem is that multimedia applications (such as movies, music, etc) fails to utilize the cache well (since the data isn't re-accessed). This is a problem area that needs more research.
How is it then that we do not see standard CPUs with custom portable devices?
You are correct when you say that backlit displays, disk drives, CD players and such consumer much power, but so does also all transistor switches (from on to off and the other way around). The sheer number of transistors and the incredible frequency of these switches makes the CPU one of the power hogs in a portable system today.
Very true. Look at this for a laugh. A minimal installation will take approx. 120MB of disk space and 40MB of RAM. I can't help wondering what they are doing over there (at M$).
I'd say that SPARC VI and VII will be more innovative (article here). I must say that ARM is not the *only* architecture used for innovative CPU designs. In academia I've seen both MIPS, SPARCs and custom designs to show/implement special innovations (vector co-processors, async logic, etc.) Usually small subsets of commersial CPUs are used for the truly innovate designs. (IMHO)
"always lagged in the floating point benchmarks"
This lagging is not due to flaws in the ISA (instruction set architecture). Todays CISC cpus (atleast the post-Pentiums and Athlons) are RISCs with a CISC shell.
The expansion of instruction sets have two drawbacks: 1) bloated designs and 2) more and more complex compilers. That is why RISC is leading the way (in a CISC suite) and CISC is degraded into keyboard controllers etc.
That is one method of doing it (turning of clock trees to shut down a set of gates). One other way is to adjust the supply voltage and clock frequency to the CPU core. As ARM allready utilizes clock gating, the voltage/frequency technique is a very viable option for even more efficient CPUs. I'm usually not a big fan of Intel's, but look at their XScale and the measures they've taken to preserve energy. I have to say that I'm impressed!
When developing portable devices the most limiting factor today is not processing resources, memory or anything such. It is simply the power source.
Batteries of today are either too weak or too heavy. How ofter does one have to choose between a slim-line battery or an ultra-long life.
There have been many suggestions for competing technologies such as fuelcells, harvesting of motion energy and solar cells to mention a few. But still, they have proven to be too expensive, large or have some other problem (such as not being ready for production use yet). Hopefully these one of these, or any other, portable power sources will make it possible to carry real computing power without having to carry a heavy battery pack.
The solution today is to reduce the power usage. This can be done by shutting down parts of the clock trees in the CPUs, or by using Intel's PowerStep (i.e. two working speeds), or Transmetas's variable voltage and frequency technology, LongRun. As the article lacks technical details we can only guess about the techniques used behind the PowerWise solution. Also, the figures 25-75% efficiency gain is most probably measured under special conditions.
But, in order to avoid sounding too negative, it seems like the industry has realized the problem and are working for a solution. I feel that most of today's solutions (power saving) are just a cure for the symptoms (bad battery time), not for the cause (bad battery technology).
"I think this isn't so important anymore"
I'd like to say that compression is more important now than ever before. Just imagine your disk space requirements without DivX...
- global password (for the filelist)
- per file(s) password(s) (for groups or individual files)
- version management (store changes, but keep the original)
- signing (both global and for file(s))
- execution abilities (oops, could trigger viruses, must be signed, but for example decompress files and compile 'em)
What I would also like is for them to go open source and actively support *nix (including Linux and MacOS X).If you would supply me with contact information, maybe we could discuss this. I feel that moderators should not doubt he facts supplied by the submitters, but rather value the information as if it is true.
I think that it is nice to see moderators yelling, flaming and behaving generally bad (yes, I mean that you do that). Tell me who you are and we can have a discussion concerning me working or not.
As for your comments about my employment. I have not said that the company I work for is "Extremely Important(tm)", I just said that we have needs for lagre computations and have invested in a Linux-based system. I am not " karma whoring by spouting bullshit", if you do not like my comments, simply mark me as a foe, and add -2 to my comments, do not mod me down simply because you have problems trusting people!
Yes! I used the cluster to compute the correct amount of water for each plant, considering cloudiness, temperature, time in direct sun light and how far each particular plant had grown. :)
Were I work (I can't say where... I've signed papers...) we have replaced an SGI 'super computer' (or mini computer, whatever, a big number crunching beast of silicon!) with a Beowulf cluster. This not only gives us great scaleability, but also lots of FLOPS per dollar (or rather, krona :^P).
To say that 'I do not need to know that' or 'that will not make me a better professional' is just ignorance. Even though you might just squeeze out a small speedup, you can probably make your software more valuable to your users (who can keep their old hardware a bit longer).
I find the (today) common attitude of bloated code being ok, and abstraction for the developers instead of performance for the users being the priorities a bit annoying. It might be because I do much work in real time environments, but also because I fail to see why people accept the they need the latest hardware to run a simple word processor at decent speed.
Please do not take me wrong. Nothing that I say is not meant personally. But I have to insist the knowledge of hardware, at least how caches, TLBs, branch predictions, ILP works, but also insight into the penalties and benfits of threads and separate processes, is required if one is to make a good software engineer. This may not be a requirement in the administrative computing sector, but will greatly help to improve the code quality.
I hope that we can stop this flamewar here and now, since we have totaly lost track of the original discussion: whether a good UI is an abstraction of everyday things and tools, or a layer over the actual computer hardware reflecting its internal workings.
More efficient!
I don't want a Linux Sync Manager, but rather, I want to run Linux on the actual device!
"most OS projects are better off without a pointy-haired boss and his bureaucracy"
I'd say that most projects would benefit from a general plan stating which features that are wanted and for whom the project is intended. As soon as a project grows from 5-10 developers a more controlled development process will be needed if to avoid bloat and general confusion about what the project is supposed to do.
One of the main problems when bringing GNU/Linux to the desktop is actually the huge number of options. If projects were better narrowed down, and more structured, most of these options could be hidden, or atleast bundled. Open source does need far better project management than is common today!
As the firmware is updateable, all we need to know now is what CPU it uses and have a memory map. Lets have tux on this gadget too!
Looks nice! Can it run linux, it seems to have the required HW. I wounder if it has a bitmapped screen, or some custom. I'd love to run bash from it and have an IrDA keyboard...
- Lack of a plan.
- Lack of peer reviewing.
- Lack of predictability (both feature and time wise).
There are many points here, but one of the most important is the lack of a plan. It would greatly benefit most OSS projects if there was a plan of features to be implemented. This would not only tell users and project members where the project is heading, but also prevents eyecandy and other code bloating problems to enter the project too early. It would be good if a feature had to be on the TO-DO list to be included into the project source tree. This way each feature has to be discussed, specified and granted before being implemented. This helps building more consistent software.The second problem, peer reviewing, could be solved by including it in the code versioning system (hense the subject of this reply...). All code must be tested and reviewed by an independen peer before included in the source tree. By introducing automatic testing, such as a small test bench application showing that the submission works, modularity is encouraged. By introducing good modularity, new patches are more easily tested and included in the source tree.
The last point is mainly a project management issue. Someone has to say that these features will be available at this date in this release. This problem is simply the addition of time to the first problem (a plan). This is the thoughest challenge when working with spare-time programmers. Not many will be happy about commiting to a project, then being forced to keep a time plan. Anyway, this can be enforced in the big, with partially paid work-time, projects.
Oh, I though P3P was P2P, just cooler! :]
"I don't need to know this stuff for the application development I do in Java or C++."
But you'll be able to produce better code if you do know this stuff.
"...I don't think it is at all obvious to joe user how it works. All they know is that they can set it for a specific length of time, and maybe different power levels..."
And this is how it works, to average Joe.
"they don't need to know about disk caches, or saving in blocks rather than bytes, or CPU cycles"
No need to bring in caches etc. But it helps if they understand that you have to save files, etc. It would make it easier to understand that somethings are missing after a power failure etc. Also, this is a power, since you can edit a document and then save it in another name or discard it. It helps the user take advantage of benefits of the computer approach. I think that this is good, compared to limiting the user to 'real world operations.'
I know that this can turn into a heated discussion, but I feel that some usability guys need to cool down a bit and let computers have a certain technical level (perhaps the one of today). This gives advantages since you don't have to limit your self to the real world metaphor, but can introduce certain advantages of the technology.
I think that the interface of a microwave oven pretty much shows how the machine works, as does the interface of TVs, VCRs, etc. Why must we go to such length to make a computer look more like things it is not. It will not reduce the need for training before use, but reduce the understanding, and thus the ability to cope with new situations and applications.
The interfaces of today represent how a computer actually work. For example, the need to save a document. This is not a bad thing if done properly, in fact, it helps (forces) the users to understand how the actual machine works (it writes periodically to the disk, and not one character at a time).
When saying this I'm not saying that there are flaws in the interfaces of today, and I do agree on that the open source movement lack much of the initiative to make things better. However, making all computer tasks behave as things in 'the real world' will not work. I'm not even sure if all metaphors used today are good. It's better to reflect the actual tool, than try to make it look like something that it is not, this will only result in disapointed and surprised users.
This guy can't be real. No-one can be *that* stupid! How does he intend to recieve his 3D files without an OS? Does he know how a computer work? Is he on drugs? What's his "education"? Does he actually get paid for saying these things?
As for publishing links NYT articles here on slashdot, why-o-why is it allowed. I urge the inclusion of a bypass link too, or a link to the article somewhere else!