frequent ?
well, it is a highly sophisticated approach to extend the usage ratio of the silicon. But speculative and out of orcer execution give a relatively slow performance gain, and depend on the compiled program.
If the program itself makes good use of the silicon, such features are a waste of space.
So much to that. Replacing such highly time critical units with more or less unpredictable (with reasonable effort) units, would greatly jeopardize functional correctness of a design.
Out of order and speculative executions only can take place when its absolutely certain that the outcome remains unchanged, and it is difficult enough with predictable execution times.
Besides, the whole pipeline issue is highly tricky when applied to asynchronous cores. While command A would need 5 times longer to decode than command B, simply because they are different, would mean that command B would "overtake" command A in the pipeline and thus change the execution order.
In a way, this _is_ out of order.;)
well, on a more serious note, and as it is probably covered by the article, I set up quite some server boxes and countless PCs, and never had problems or issues with cables. I however, had some problems to "loose" cables installed by previous techies.
I only experienced PCs with SCSI disks (or cables, for that matter) creating a somewhat noise airflow.
Or, worse, they stalled the air so the heat dissipation wasnt fully functional.
But I dont expect this to be a problem for "normal" PCs.
I dont know why everyone jumps off the horse as soon as they hear the magic word "assembly".
Seriously.
If you want to get 110% out of your hardware, you have to put effort in, to get effort out. Makes sense, doesnt it ?
Im not saying people who dont like ASM are sissies, not at all. But Im saying that assembly has its right, just as so many other programing languages.
Preemption is a "dirty hack" to achieve nice behaviour in a timely manner.
For embedded systems where interrupt latency is the primary aspect, other approaches have to be found. also, if the CPU checks after every x instructions if there is an interrupt to process, you get a margin of the timely behaviour. I am no embedded / safety critical developer, but I know that the fastest response times on interrupts and worst-case response times vary greatly depending solely on the (RT)OS used.
the very first drafts of microprocessors were clockless.
just with higher speed and hence, brute force, performance could be achieved easily.
The problems which could not be solved back then were the obvious synchronisation issues. Setting up a common clock seemed the only way to resolve them.
The idea behind clockless designs is less a "back-to-the-roots" idea, but more a step to gain the advantages of such a design, which are, amongst others:
Reduced Power Consumption
Higher Operation Speed
Moreover, highly sophisticated compilers could tune program code to match a given performance/power ratio.
Yet, I would not bet on clockless cores to become the new mainstream, by far not. Clockless cores will most likely be aimed at embedded design appliances, and low- and ultra-low-power applications.
Tagged Command Queuing is supported since the early days of SCSI.
modern drives support up to 255 entries.
So, from my understanding, the drive optimizes it for low seek time and high throughput, so this new kernel feature of 2.6 might either double the effort on SCSI drives for the same output, or, what I presume, these two features might even conflict. sure, TCQ can be disabled, but why implement in software what already exists (and works) in hardware ?
In terms of visual programming, I used to work a lot with LabView and Mentor's VHDL Design Suite.
Both are very graphically contained, but what you design is yet the dataflow, and the methods.
Be it a top-down, or a bottom-up process, you have to think of how to implement methods and actual data processing.
Yet, I think that the amount of work that is put in projects, especially bigger ones, is bigger in the design-methology-dataflow part (which can be graphical), than in the actual coding work.
Moreover, teamwork is much easier if the code design (whatever it be) is graphical.
Think of the many many possobilities you have to achieve a task in C, and its very hard for even a team-member to read and understand your code at once, be it well documented as is, yet it is a LOT easier to read graphics.
The site is indeed interesting, but the casual from time-to-time gamer will most unlikely exercise at such an extend.
Much more appreciated would really be sites with online communities that just help u improve cross-gaming-wise.
Such as it is done prior to some games on LANs. Its just much more fun to face an enemy that knows HOW to fire a gun, at least in your direction.;)
the same principle can be used for vehicels and traffic as well - with proper protocols anything could be implemented, from GPS to communications....
I look forward to a future when I _know_ the exact positions of all vehicels on the road in a 3 or 4 mile radius... that would really improve security (and driving fun)
Slashdot Mirror
wow, the early /. effect seems to be quite popular these days. no comments by now, and almost slashdotted already.....
frequent ?
;)
well, it is a highly sophisticated approach to extend the usage ratio of the silicon. But speculative and out of orcer execution give a relatively slow performance gain, and depend on the compiled program.
If the program itself makes good use of the silicon, such features are a waste of space.
So much to that. Replacing such highly time critical units with more or less unpredictable (with reasonable effort) units, would greatly jeopardize functional correctness of a design.
Out of order and speculative executions only can take place when its absolutely certain that the outcome remains unchanged, and it is difficult enough with predictable execution times.
Besides, the whole pipeline issue is highly tricky when applied to asynchronous cores. While command A would need 5 times longer to decode than command B, simply because they are different, would mean that command B would "overtake" command A in the pipeline and thus change the execution order.
In a way, this _is_ out of order.
agreed, in terms of numbers. ;)
But its those GP-workstations etc. that an extensive bigger amount of money is being made with.
well, on a more serious note, and as it is probably covered by the article, I set up quite some server boxes and countless PCs, and never had problems or issues with cables.
I however, had some problems to "loose" cables installed by previous techies.
I only experienced PCs with SCSI disks (or cables, for that matter) creating a somewhat noise airflow.
Or, worse, they stalled the air so the heat dissipation wasnt fully functional.
But I dont expect this to be a problem for "normal" PCs.
I dont know why everyone jumps off the horse as soon as they hear the magic word "assembly".
Seriously.
If you want to get 110% out of your hardware, you have to put effort in, to get effort out. Makes sense, doesnt it ?
Im not saying people who dont like ASM are sissies, not at all. But Im saying that assembly has its right, just as so many other programing languages.
Preemption is a "dirty hack" to achieve nice behaviour in a timely manner.
For embedded systems where interrupt latency is the primary aspect, other approaches have to be found. also, if the CPU checks after every x instructions if there is an interrupt to process, you get a margin of the timely behaviour.
I am no embedded / safety critical developer, but I know that the fastest response times on interrupts and worst-case response times vary greatly depending solely on the (RT)OS used.
the very first drafts of microprocessors were clockless.
just with higher speed and hence, brute force, performance could be achieved easily.
The problems which could not be solved back then were the obvious synchronisation issues. Setting up a common clock seemed the only way to resolve them.
The idea behind clockless designs is less a "back-to-the-roots" idea, but more a step to gain the advantages of such a design, which are, amongst others:
Reduced Power Consumption
Higher Operation Speed
Moreover, highly sophisticated compilers could tune program code to match a given performance/power ratio.
Yet, I would not bet on clockless cores to become the new mainstream, by far not. Clockless cores will most likely be aimed at embedded design appliances, and low- and ultra-low-power applications.
And currently is being slashdotted too. I wonder wether they stole /. account data ? o.O
Wait, didn't my karma drop considerably recently ?
and a new version has just been released :)
freshmeat.net is your daddy :D
I use the metric system, you insensitive clod.
I havent even started understanding vi's modes you insensitive clod!
Tagged Command Queuing is supported since the early days of SCSI. modern drives support up to 255 entries. So, from my understanding, the drive optimizes it for low seek time and high throughput, so this new kernel feature of 2.6 might either double the effort on SCSI drives for the same output, or, what I presume, these two features might even conflict. sure, TCQ can be disabled, but why implement in software what already exists (and works) in hardware ?
In terms of visual programming, I used to work a lot with LabView and Mentor's VHDL Design Suite.
Both are very graphically contained, but what you design is yet the dataflow, and the methods.
Be it a top-down, or a bottom-up process, you have to think of how to implement methods and actual data processing.
Yet, I think that the amount of work that is put in projects, especially bigger ones, is bigger in the design-methology-dataflow part (which can be graphical), than in the actual coding work.
Moreover, teamwork is much easier if the code design (whatever it be) is graphical.
Think of the many many possobilities you have to achieve a task in C, and its very hard for even a team-member to read and understand your code at once, be it well documented as is, yet it is a LOT easier to read graphics.
The site is indeed interesting, but the casual from time-to-time gamer will most unlikely exercise at such an extend. ;)
Much more appreciated would really be sites with online communities that just help u improve cross-gaming-wise. Such as it is done prior to some games on LANs.
Its just much more fun to face an enemy that knows HOW to fire a gun, at least in your direction.
Those lamers on publics can really piss one off.
Mantrid Mantis ? http://everything2.net/index.pl
the same principle can be used for vehicels and traffic as well - with proper protocols anything could be implemented, from GPS to communications.... I look forward to a future when I _know_ the exact positions of all vehicels on the road in a 3 or 4 mile radius... that would really improve security (and driving fun)