Free-riding spares people's bandwidth... I never purchased anything from banner ads before adopting ad-blockers and am extremely unlikely to ever do. By free-riding, I am sparing the advertiser/host's bandwidth along with my own.
When advertisers started using Flash animations with SOUND, I snapped and decided to go on a quest for absolute free-loading. The only ads I am willing to tolerate are google-style text-only ads and static images.
Advertisers are going too far and I see freeloading as one way of protesting... and definitely a necessary thing for dial-ups.
Vander may have some performance issues though since much of the memory management is done in software.
AMD pulled an ace on Intel with x86-64 and it seems AMD will also have the better deal on virtualization with more of it being transparently handled by hardware.
To me, it seems Intel severely dulled its edge on the P4 anvil. I wonder how many years it will take for it to be solidly back on tracks... I am guessing 3-5 years as a minimum unless something truly ground-breaking failed to leak through the usual rumour channels.
A PowerPC is just a single core... a POWER4 is a multi-chip module featuring four qual-core CPUs with integrated RAM controller, insane internal and external interconnects and 36MB L3 cache. The POWER4 MCM itself has >5000 pins and peak power dissipation around 400W... not quite in the same league as off-the-shelf PowerPC cores.
The POWER4's PPC is different from the Cell's PPC which is different from G4/G5's PPC and the PPC that will end up into the XBox360... IBM likes to customize the PPC to meet big accounts' requirements.
Unless something is done soon to sanitize the patent systems (software patents being one of the greatest insanities ever, seeing that patent systems already had major issues coping with more tangible stuff), it will become practically impossible for "backyard" inventors to do anything without significant risk of getting trampled by (law-)suits. Invent something and get sued to bankruptcy for it. Now, write some software and risk the same... most software probably infringes dozens if not hundreds of such frivolous patents now.
I wonder how many cases like this one will be necessary before it becomes an accepted reality that software patents (and much of the intellectual property stuff) is a really dumb idea in practice.
The length of your antenna is not going to magically boost your TX power beyond the 20dBm maximum provided by the source feeding it. A proper half-wave vertical dipole is the optimal simple antenna for most WiFi needs.
Having hardware capable of doing illegal stuff can be a liability in some countries. It can be a licensing nightmare in others, etc.
IIRC, the Linksys firmware (WRT*/WAP*) does not include the actual code for the WiFi chipset driver due to licensing issues.
For off-the-shelf laptops, manufacturers often have multiple sources for their miniPCI cards and the specs say something like "WiFi is provided by either A's model X, B's model Y or C's model Z miniPCI card" so the exact hardware is unknown until after purchase - though the serial number may contain a hint.
At least, most laptops still come with e100 or rt8139 ethernet.
Not buying broadcom hardware is a tall order when it comes integrated in a laptop... and replacing it afterwards is a tall order since aftermarket WiFi cards are somewhat rare, overpriced and might not be on the laptop's whitelist.
Look at WiFi cards, radio transmitters are subjected to local legislation specifying which channels are available and what powers are allowed. WiFi manufacturers use the closed-source nature of their driver to (sort of) enforce local restrictions.
For WinModems, the software/driver is the modem, the card is only some sort of PCI-based CODEC. Even there, local legislation also imposes maximum signal powers and bandwidth, which is why 57.6kbps modem will never go beyond 48-54kbps in most places.
In short, the hardware is often capable of more than what the drivers allow due to legislation.
For stuff like video cards, part of it is industrial secret - prevent competitors from duplicating new ways of handling portable driver-level optimizations. Another reason may be weak against unexpected IO sequences or other stuff along that line.
Another general possibility is that parts of the drivers are so badly written as to be humiliating and potentially damaging to the companies' repuration... but I hope this is generally not the case.
For me, this sort of activity is like free training, marketable skills for job-hunting and potential free publicity for the 'victims' when procurement roll-ups come up.
FireWire is 400Mbps full-duplex while USB2 is 480Mbps simplex with 10% reserved for arbitration/scheduling/etc.
With FireWire, speed is independent of cable length while on USB2, length directly affects propagation delays which are a killer on simplex lines since it forces longer pauses between packets.
While USB2 may be 20% faster than FireWire in marketspeak, under real-world circumstances is only 50-60% as fast for one-way file transfers. When I got my first USB2 and FW HDD boxes, I did some benchmarking... 1- USB2 box with 3' cable: 23MB/s 2- USB2 box with 6' cable: 18MB/s 3- USB2 to USB2 with 3' cables on same root hub: 10MB/s 4- FW box with 3/6/9' cable: 32MB/s (FW/IDE bridge maximum) 5- FW box to FW box, independent ports: 30MB/s 6- FW box to FW box, stringed to same port: 25MB/s
USB's usable bandwidth suffers horribly as bus load increases. FireWire is much steadier under heavy loads. This is exactly the same story as 10/100Mbps Ethernet's hub VS switch... nobody sees the difference until network load exceeds 10%, beyond which point the switched/duplex alternative quickly becomes clearly superior.
Application-specific architectures are in completely different leagues from general-purpose.
A genera-purpose CPU can pump out up to two multiplications per cycle assuming the code consists entirely of MUL instructions (unrealistic) and with a 4GHz CPU, this amounts to only 8 bilion 32bits multiplications per second.
GPUs are optimized to pump out 4x4 matrix multiplications and the current models have an effective throughput well over 100 bilion multiply-add operations per second.
On a CPU, the coder/compiler has to specify how data is shuffled and transformed. On GPUs, the hardware already knows how the data is going to be loaded and saved so the programmer only needs to define the transformations based on architectural (register) data.
As for the PhysX accelerator, most of the physics calculations could probably be offloaded to the graphics card's vertex shader so I am much more sceptical about that one.
It would be funny if Intel apples came with "Designed for Microsoft Windows XP64" stickers.
Unless Apple is planning to let OSX-x86(-64) run on normal PCs, I have a hard time believing they would make standards-compliant PCs able to run Windows... at least not without some hacking.
Hardware threading has been mainstream for more than two years in the form of HyperThreading.
Simultaneous Multi-Threading is a CPU's ability to concurrently execute mixed instructions from multiple threads. Intel's HT simply 2-ways SMT.
Chip Multi-Threading is a CPU's ability to hold execution states for multiple threads, executing instructions from only one of them at a time unless the chip is also SMT.
In Sun's case, the mid-term plan is to eventually offer 8-ways SMT with 32-ways CMT: the CPU can hold states for up to 32 threads and have in-flight instructions from as many as eight of them.
BTW, about doing context switches on conditional branches, a context switch costs ~1k cycles, a cache miss costs ~100 cycles and a mispredict costs 10-20 cycles. Adding a mechanism to signal the OS to swap threads on misses and mispredicts would, as you said (but in other words), be insane:)
What about applications where substantial parts are inherently sequential? If you need to run this sequential task multiple times, an SMT CPU can run multiples of it simultaneously. Alternatively, the sequential task could be split into sub-parts with some threads handling each stage to optimize overall RAM/IO access patterns and limit cache trashing.
Also, I'm not sure that even ignoring that if you'd get the performance benefits you claim. You're ignoring the overhead of switching threads for instance. I was proposing trading single-threaded performance for multi-threaded throughput and efficiency by widening hardware simultaneous multi-threading (SMT) to something like eight-ways. (Intel's HyperThreading is two-ways SMT)
On an eight-way SMT CPU, up to eight threads can be running concurrently within one physical CPU, with the OS/apps seeing eight logical CPUs. Because threads have no (or very few) interdependencies, it should be very easy to keep the CPU's execution pipelines filled and producing only useful results.
With current x86 CPUs, cache misses and branch mispredicts cause lots of work to be wasted and duplicated. On a CPU that sacrices single-thread performance, it would be possible to practically guarantee that every cycle would produce the maximum amount of useful work, no duplicate, no waste, very few idle or sub-optimal cycles.
Since this threading stuff is occuring within the CPU, the OS's thread-switching does not apply - the part discussed here is HARDWARE threads. If anything, this could REDUCE the actual number of context switches since the OS would have many virtual CPUs to dispatch threads to, meaning it would have to boot threads off a virtual CPU less often.
Again, such a CPU would be so-so for single-threaded stuff and really if that stuff happened to be branch-heavy... but it would be a marvel for massively multi-threaded environments.
on average, every 6-8 instructions there's a conditional branch So, 6 instructions * 8 threads = 48 instructions to toss around while waiting for some dependencies to be resolved. The likelyhood that all eight threads would simultaneously stall on a branch or RAM/IO is very low. Even if half the threads stall on something, the remaining half should still be able to provide enough OPs to keep the execution pipelines loaded.
I'm not sure if you meant that instead of waiting for a branch to resolve it could start working on another thread; if you didn't, please ignore my other reply. What SMT means is that the CPU is working on multiple threads simultaneously. The more hardware threads there are, the more likely the CPU would be to find something else to do while it waits for dependencies to be resolved, reducing wasted cycles and reliance on killer branch predictors, memory prefetching and other fancy tricks necessary to maximize single-thread performance. My bet is that with enough thread-level parallelism, most of these tricks could be dumped... only instruction reordering buffers and the renamed register file would still be absolutely necessary.
On the other hand, I don't see any other way to achieve what you suggest. You obviously misunderstood the nature of my proposal - you have mistaken OS threads and hardware (SMT) threads... though related, they are two very different matters.
That would also shed off 20+ years of backwards-compatibility which is the prime reason why x86 survived the 32bits transition and held off up to now and for the foreseeable future.
Anyway, since x86 and RISC are only wrappers to the internal RISC-like microcode engine, CISC and RISC are pretty much only historic artifact now.
The only thing to gain from ditching the x86 instruction set is instruction decoder simplicity. Intel and AMD have been building x86 instruction decoders for 20+ years so x86's quirks are non-issues for them, thereby making decoder simplicity insignificant compared to backwards compatibility.
As long as x86 can continue undercutting and scaling beyond surviving/competing alternatives, x86 will keep on leading and spreading.
Re:Ah... history fails to be remembered again...
on
AMD Quad Cores, Oh My
·
· Score: 1
I am not questioning the usefulness of being able to run multiple threads concurrently on multiple physical or logical execution units... the software I personally write has a tendency to become heavily multithreaded.
In my limited multi-threaded software writing experience, the easiest way to deal with deadlocks in critical paths is to spin off the locking parts into their own threads. With thread pools, this can be done almost completely transparently and with nearly no performance penalty.
Going for wider multithreading cores would have a similar effect.
After multi-threading becomes commonplace, CPU manufacturers could drop branch prediction and related fancy logic: simply defer issuing instructions from the reorder buffer until all dependencies are resolved or guaranteed to be by the time they are used. With 4-8 threads, the execution pipeline would be operating at maximum throughput under most circumstances. Such a CPU would have abysmal performance on conditional branches but would also approach 100% processing efficiency (no wasted work or idle cycles) in extensively multithreaded environments. Getting rid of all the speculative stuff would probably extensively simplify much (and completely eliminate some) of the management logic.
Re:Ah... history fails to be remembered again...
on
AMD Quad Cores, Oh My
·
· Score: 1
Once upon a time, 640_KB_ ought to be enough for everybody... today, >640_MB_ is common.
Me, my laptop has 1.25GB, my desktop has 1GB, my backup PC has 512MB and anything below 512MB is marginally usable as far as I am concerned.
Structure design, power and gas distribution are tightly regulated in most countries' building code. Most of interior design is completely unregulated since very little of it has safety-critical elements.
Most software is non-critical and is running on non-mission-critical systems. Hardware and software going into life-support or comparably critical systems usually go through horribly thorough audits and testing.
Most shareware/freeware/hobby software writers have little to no hardened software development experience or even basic knowledge about it. Algorithms that are fundamentally correct often go bad for non-obvious reasons. As a mostly hobby coder, I have run my fair share of fundamentally correct stuff that mysteriously breaks... stuff like spinlocks remaining set even though the locks are implemented atomically ([lock] cmpxchg) and I am not forgetting to clear them before returning.
Software design has catches around every corner, common practice and patterns provide a foundation to avoid many of them but this many is still only a tiny subset of hypothetically infinite possibilities.
For a basic single-floor house without basement and pre-laid foundation, the Guiness record is well under a week using a team of 40-50 (semi-)professional volunteers and good planning. (IIRC, the actual record is even under 24h.)
Slashdot Mirror
Free-riding spares people's bandwidth... I never purchased anything from banner ads before adopting ad-blockers and am extremely unlikely to ever do. By free-riding, I am sparing the advertiser/host's bandwidth along with my own.
When advertisers started using Flash animations with SOUND, I snapped and decided to go on a quest for absolute free-loading. The only ads I am willing to tolerate are google-style text-only ads and static images.
Advertisers are going too far and I see freeloading as one way of protesting... and definitely a necessary thing for dial-ups.
Vander may have some performance issues though since much of the memory management is done in software.
AMD pulled an ace on Intel with x86-64 and it seems AMD will also have the better deal on virtualization with more of it being transparently handled by hardware.
To me, it seems Intel severely dulled its edge on the P4 anvil. I wonder how many years it will take for it to be solidly back on tracks... I am guessing 3-5 years as a minimum unless something truly ground-breaking failed to leak through the usual rumour channels.
A PowerPC is just a single core... a POWER4 is a multi-chip module featuring four qual-core CPUs with integrated RAM controller, insane internal and external interconnects and 36MB L3 cache. The POWER4 MCM itself has >5000 pins and peak power dissipation around 400W... not quite in the same league as off-the-shelf PowerPC cores.
The POWER4's PPC is different from the Cell's PPC which is different from G4/G5's PPC and the PPC that will end up into the XBox360... IBM likes to customize the PPC to meet big accounts' requirements.
My fears exactly.
Unless something is done soon to sanitize the patent systems (software patents being one of the greatest insanities ever, seeing that patent systems already had major issues coping with more tangible stuff), it will become practically impossible for "backyard" inventors to do anything without significant risk of getting trampled by (law-)suits. Invent something and get sued to bankruptcy for it. Now, write some software and risk the same... most software probably infringes dozens if not hundreds of such frivolous patents now.
I wonder how many cases like this one will be necessary before it becomes an accepted reality that software patents (and much of the intellectual property stuff) is a really dumb idea in practice.
Imagine a world without lawyers...
The length of your antenna is not going to magically boost your TX power beyond the 20dBm maximum provided by the source feeding it. A proper half-wave vertical dipole is the optimal simple antenna for most WiFi needs.
Having hardware capable of doing illegal stuff can be a liability in some countries. It can be a licensing nightmare in others, etc.
IIRC, the Linksys firmware (WRT*/WAP*) does not include the actual code for the WiFi chipset driver due to licensing issues.
For off-the-shelf laptops, manufacturers often have multiple sources for their miniPCI cards and the specs say something like "WiFi is provided by either A's model X, B's model Y or C's model Z miniPCI card" so the exact hardware is unknown until after purchase - though the serial number may contain a hint.
At least, most laptops still come with e100 or rt8139 ethernet.
Not buying broadcom hardware is a tall order when it comes integrated in a laptop... and replacing it afterwards is a tall order since aftermarket WiFi cards are somewhat rare, overpriced and might not be on the laptop's whitelist.
There are a few simple reasons for this.
Look at WiFi cards, radio transmitters are subjected to local legislation specifying which channels are available and what powers are allowed. WiFi manufacturers use the closed-source nature of their driver to (sort of) enforce local restrictions.
For WinModems, the software/driver is the modem, the card is only some sort of PCI-based CODEC. Even there, local legislation also imposes maximum signal powers and bandwidth, which is why 57.6kbps modem will never go beyond 48-54kbps in most places.
In short, the hardware is often capable of more than what the drivers allow due to legislation.
For stuff like video cards, part of it is industrial secret - prevent competitors from duplicating new ways of handling portable driver-level optimizations. Another reason may be weak against unexpected IO sequences or other stuff along that line.
Another general possibility is that parts of the drivers are so badly written as to be humiliating and potentially damaging to the companies' repuration... but I hope this is generally not the case.
Exactly... and I do the exact same.
For me, this sort of activity is like free training, marketable skills for job-hunting and potential free publicity for the 'victims' when procurement roll-ups come up.
True by the strictest/correct definition of simplex.
If Intel was given a chance to rewrite USB's history, I wonder if they would include separate RX and TX pairs.
Equivalent decent?
I seriously doubt the water setup would come anywhere close to cheap 5000BTU air conditionners that cost around $100 and have a COP > 9.
He might be better off pulling a Homer: setup a tent in front of the fridge's door - this reduces the large T delta...
FireWire is 400Mbps full-duplex while USB2 is 480Mbps simplex with 10% reserved for arbitration/scheduling/etc.
With FireWire, speed is independent of cable length while on USB2, length directly affects propagation delays which are a killer on simplex lines since it forces longer pauses between packets.
While USB2 may be 20% faster than FireWire in marketspeak, under real-world circumstances is only 50-60% as fast for one-way file transfers. When I got my first USB2 and FW HDD boxes, I did some benchmarking...
1- USB2 box with 3' cable: 23MB/s
2- USB2 box with 6' cable: 18MB/s
3- USB2 to USB2 with 3' cables on same root hub: 10MB/s
4- FW box with 3/6/9' cable: 32MB/s (FW/IDE bridge maximum)
5- FW box to FW box, independent ports: 30MB/s
6- FW box to FW box, stringed to same port: 25MB/s
USB's usable bandwidth suffers horribly as bus load increases. FireWire is much steadier under heavy loads. This is exactly the same story as 10/100Mbps Ethernet's hub VS switch... nobody sees the difference until network load exceeds 10%, beyond which point the switched/duplex alternative quickly becomes clearly superior.
I thought this was:
"Attempted (and generally successful) butchery."
I know I have a habit of rashly axing stuff when I visit a registry.
Application-specific architectures are in completely different leagues from general-purpose.
A genera-purpose CPU can pump out up to two multiplications per cycle assuming the code consists entirely of MUL instructions (unrealistic) and with a 4GHz CPU, this amounts to only 8 bilion 32bits multiplications per second.
GPUs are optimized to pump out 4x4 matrix multiplications and the current models have an effective throughput well over 100 bilion multiply-add operations per second.
On a CPU, the coder/compiler has to specify how data is shuffled and transformed. On GPUs, the hardware already knows how the data is going to be loaded and saved so the programmer only needs to define the transformations based on architectural (register) data.
As for the PhysX accelerator, most of the physics calculations could probably be offloaded to the graphics card's vertex shader so I am much more sceptical about that one.
It would be funny if Intel apples came with "Designed for Microsoft Windows XP64" stickers.
Unless Apple is planning to let OSX-x86(-64) run on normal PCs, I have a hard time believing they would make standards-compliant PCs able to run Windows... at least not without some hacking.
Hardware threading has been mainstream for more than two years in the form of HyperThreading.
Simultaneous Multi-Threading is a CPU's ability to concurrently execute mixed instructions from multiple threads. Intel's HT simply 2-ways SMT.
Chip Multi-Threading is a CPU's ability to hold execution states for multiple threads, executing instructions from only one of them at a time unless the chip is also SMT.
In Sun's case, the mid-term plan is to eventually offer 8-ways SMT with 32-ways CMT: the CPU can hold states for up to 32 threads and have in-flight instructions from as many as eight of them.
Glad to have cleared that up.
:)
BTW, about doing context switches on conditional branches, a context switch costs ~1k cycles, a cache miss costs ~100 cycles and a mispredict costs 10-20 cycles. Adding a mechanism to signal the OS to swap threads on misses and mispredicts would, as you said (but in other words), be insane
What about applications where substantial parts are inherently sequential?
If you need to run this sequential task multiple times, an SMT CPU can run multiples of it simultaneously. Alternatively, the sequential task could be split into sub-parts with some threads handling each stage to optimize overall RAM/IO access patterns and limit cache trashing.
Also, I'm not sure that even ignoring that if you'd get the performance benefits you claim. You're ignoring the overhead of switching threads for instance.
I was proposing trading single-threaded performance for multi-threaded throughput and efficiency by widening hardware simultaneous multi-threading (SMT) to something like eight-ways. (Intel's HyperThreading is two-ways SMT)
On an eight-way SMT CPU, up to eight threads can be running concurrently within one physical CPU, with the OS/apps seeing eight logical CPUs. Because threads have no (or very few) interdependencies, it should be very easy to keep the CPU's execution pipelines filled and producing only useful results.
With current x86 CPUs, cache misses and branch mispredicts cause lots of work to be wasted and duplicated. On a CPU that sacrices single-thread performance, it would be possible to practically guarantee that every cycle would produce the maximum amount of useful work, no duplicate, no waste, very few idle or sub-optimal cycles.
Since this threading stuff is occuring within the CPU, the OS's thread-switching does not apply - the part discussed here is HARDWARE threads. If anything, this could REDUCE the actual number of context switches since the OS would have many virtual CPUs to dispatch threads to, meaning it would have to boot threads off a virtual CPU less often.
Again, such a CPU would be so-so for single-threaded stuff and really if that stuff happened to be branch-heavy... but it would be a marvel for massively multi-threaded environments.
on average, every 6-8 instructions there's a conditional branch
So, 6 instructions * 8 threads = 48 instructions to toss around while waiting for some dependencies to be resolved. The likelyhood that all eight threads would simultaneously stall on a branch or RAM/IO is very low. Even if half the threads stall on something, the remaining half should still be able to provide enough OPs to keep the execution pipelines loaded.
I'm not sure if you meant that instead of waiting for a branch to resolve it could start working on another thread; if you didn't, please ignore my other reply.
What SMT means is that the CPU is working on multiple threads simultaneously. The more hardware threads there are, the more likely the CPU would be to find something else to do while it waits for dependencies to be resolved, reducing wasted cycles and reliance on killer branch predictors, memory prefetching and other fancy tricks necessary to maximize single-thread performance. My bet is that with enough thread-level parallelism, most of these tricks could be dumped... only instruction reordering buffers and the renamed register file would still be absolutely necessary.
On the other hand, I don't see any other way to achieve what you suggest.
You obviously misunderstood the nature of my proposal - you have mistaken OS threads and hardware (SMT) threads... though related, they are two very different matters.
That would also shed off 20+ years of backwards-compatibility which is the prime reason why x86 survived the 32bits transition and held off up to now and for the foreseeable future.
Anyway, since x86 and RISC are only wrappers to the internal RISC-like microcode engine, CISC and RISC are pretty much only historic artifact now.
The only thing to gain from ditching the x86 instruction set is instruction decoder simplicity. Intel and AMD have been building x86 instruction decoders for 20+ years so x86's quirks are non-issues for them, thereby making decoder simplicity insignificant compared to backwards compatibility.
As long as x86 can continue undercutting and scaling beyond surviving/competing alternatives, x86 will keep on leading and spreading.
I am not questioning the usefulness of being able to run multiple threads concurrently on multiple physical or logical execution units... the software I personally write has a tendency to become heavily multithreaded.
In my limited multi-threaded software writing experience, the easiest way to deal with deadlocks in critical paths is to spin off the locking parts into their own threads. With thread pools, this can be done almost completely transparently and with nearly no performance penalty.
Going for wider multithreading cores would have a similar effect.
After multi-threading becomes commonplace, CPU manufacturers could drop branch prediction and related fancy logic: simply defer issuing instructions from the reorder buffer until all dependencies are resolved or guaranteed to be by the time they are used. With 4-8 threads, the execution pipeline would be operating at maximum throughput under most circumstances. Such a CPU would have abysmal performance on conditional branches but would also approach 100% processing efficiency (no wasted work or idle cycles) in extensively multithreaded environments. Getting rid of all the speculative stuff would probably extensively simplify much (and completely eliminate some) of the management logic.
Once upon a time, 640_KB_ ought to be enough for everybody... today, >640_MB_ is common.
Me, my laptop has 1.25GB, my desktop has 1GB, my backup PC has 512MB and anything below 512MB is marginally usable as far as I am concerned.
... and ability to stay focused on anybody but ourselves. ... or specific parts thereof.
Structure design, power and gas distribution are tightly regulated in most countries' building code. Most of interior design is completely unregulated since very little of it has safety-critical elements.
Most software is non-critical and is running on non-mission-critical systems. Hardware and software going into life-support or comparably critical systems usually go through horribly thorough audits and testing.
Most shareware/freeware/hobby software writers have little to no hardened software development experience or even basic knowledge about it. Algorithms that are fundamentally correct often go bad for non-obvious reasons. As a mostly hobby coder, I have run my fair share of fundamentally correct stuff that mysteriously breaks... stuff like spinlocks remaining set even though the locks are implemented atomically ([lock] cmpxchg) and I am not forgetting to clear them before returning.
Software design has catches around every corner, common practice and patterns provide a foundation to avoid many of them but this many is still only a tiny subset of hypothetically infinite possibilities.
For a basic single-floor house without basement and pre-laid foundation, the Guiness record is well under a week using a team of 40-50 (semi-)professional volunteers and good planning. (IIRC, the actual record is even under 24h.)