Yeah, I tried GRUB once on my PC, and resolved to go back to it once it became more mature. I liked the concept, but at the time it didn't work very well. That was quite a while ago, so perhaps now's the time.
As for the question of whether firmware should implement an OS, I'm undecided. As a hardware designer, my expectations are probably very different to yours, because I think mostly in terms of system hardware validation, bringup, debug, and production test.
Much of this code wants to run as close to the "bare metal" as possible. When something fails, I don't want to dig through any more layers of software than I have to, to find the root cause. So there's a lot to be said for using the lowest level environment that just provides enough functionality to abstract away differences in devices, networking stack, and access to filesystems. EFI isn't ideal, but it's sure better than nothing, and it's way better than Linux or (groan) Windows for this purpose.
Misleading statement about no text-only
on
BIOS' Days Are Numbered
·
· Score: 4, Informative
EFI my be a new thing to most IA-32 users, but it's already the established standard for IA-64 firmware. So, I have hands on experience using it.
I beleive the statement about getting rid of text-mode-only startup is incorrect. I've used EFI extensively in systems that don't even have a graphics card installed, and it works just fine over a serial console.
EFI is like a little mini-OS that serves mainly as a boot loader environment, but can also be used for running simple batch scripts and executables. System configuration utilities, OS installers, and diagnostic programs are all good candidates to build as EFI executables. For example, "elilo" is a Linux boot loader built as an EFI executable. To me, EFI seems more like MS-DOS than anything else.
EFI has modular drivers, so you can support different boot devices, network stacks, etc., and use them for pre-OS-boot tasks such as installation, configuration, etc.
Since EFI can mount (some) filesystems, and the booted OS can subsequently mount the same filesystem, an EFI partition is a useful place. For example, when you build a new linux kernel, you just copy it into the mounted EFI partition, modify the elilo.conf file (also in this partition), and the next boot will boot from the new file. No more scribbling to boot records.
If you travel a fairly normal itinerary, i.e. one lots of other people also travel, Travelocity et al are great. Not sure about the auction type sites (e.g. Priceline), though.
They fall down badly if you travel a slightly unusual itinerary such as:
Multi-segment with different stops each direction, or with a stop one direction only -- especially in cases with airline changes needed. E.g. DEN-LHR-CPT-DEN.
Discontinuous, e.g. LHR-LED (discontinuity) MOW-LHR.
Routes where the best fare involves rolling your own connection rather than accepting a mainstream connection, e.g. DEN-LHR-CPT. Travelocity offers you DEN-ATL-CPT which is much more direct, but costs twice as much. But Travelocity won't find the DEN-LHR-CPT even if you explicitly call out the LHR stop. They will only find it if you search twice, once for DEN-LHR, and once for LHR-CPT. (Haven't checked this recently, though. Maybe they've fixed it).
For this type of route, with enough patience, you can still do much of your research on Travelocity. But you need to apply trial and error combinations of individual segments, then call the airline to get the REAL price, which is often quite a bit lower, especially in the discontinuous example.
Another reason to actually call the airline rather than book online, is that they occasionally offer you a lower fare that is technically unavalable because the cutoff date has passed. I guess they have some discretionary flexibility. I don't know why they voluntarily do this, but it's happend to me more than once. British Airways is particularly good about this.
Menus and keys/buttons with multiple functions are not very intuitive.
If your feature list is so long that menus and multi-function buttons are unavoidable, try to use them only for the more exotic frills. Dedicate a few buttons to the basic functionality, and perhaps a few to the more basic of the frills. Multiplex the remaining frills onto the remaining buttons. Above all, make sure that the basic stuff remains accessible at all times, and it's operation is not interrupted or modified in any way by the current state of the menuing system.
The best candidates for menus and multifunction buttons, if unavoidable, are things that are typically accessed very seldom or once only -- like setup features.
Sorry, I don't know of such a book. I'll just make one 2 cent suggestion.
Divide all the features into two piles: basic functionality, and frills: Basic functionality is the stuff that defines your product. Without this, your product isn't useful. Frills are the other stuff that may be useful, cool, and possibly even set your product apart from the competition, but doesn't define the product.
For example, if you were designing a phone, basic funtionality is dialing numbers to make outgoing calls, and receiving incoming calls. Period. That's it. Frills include everything else: speed dialing, programmable ring tones, redial, phone book, call log, etc.
Now stick to this simple rule: No frill should ever, in any way, make a basic functionality feature any more difficult to use, harder to find, or less intuitive. Never!
For a classic example, consider those Nokia phones that have a single, multifunction button, that serves a SEND, END, MENU, and a zillion other multiplexed functions. You can be on a call, and need to hang up, but because of other unrelated features (e.g. address book access, volume control, etc.), the multi-function button doesn't happen to be behaving as an END button at the time. You've got to look at the screen and back out of menus, until you see END, and then push the button. That's ugly, and it's all because frills were multiplexed onto the same contols as basic functionality, in a way that interfered with the basic functionality.
I suppose a more sophisticated strategy would involve multiple categories of features, ordered from most basic to most frilly. In that case, no feature may ever be allowed to cause any feature in a "more basic" category to be any more difficult, or less intuitive. But with just 2 categories and a strict adherence to this rule, you'll already be ahead of 90% of the gizmos on the market.
Do commercial freight ships even use magnetic compasses any more..
No first-hand knowledge, but I'd be very surprised if they didn't use them.
At least in aviation, the general philosophy is that instruments can get as complex and sophisticated as you like, but the basic "fallback" low-tech instruments must be present to use when all else fails, and they must be routinely checked for functionality even if they are hardly ever used.
For an airplane, that's altitude, airspeed, and magnetic compass. (And others if IFR). I don't know what the list would be for a container ship or supertanker, but I'd bet it includes a low-tech magnetic compass.
Sure, there won't be enough residual that it sticks to other passing ships, or anything, but what about interference with magnetic compasses.
I had a steel-tube frame airplane, and it got so magnetized from arc welding that the mag compass was totally useless. No amount of swinging could correct the compass deviation. Nor did it help to replace the mag compass with a new one. I ended up degaussing the whole fuselage with a degauss coil designed for TV sets, and never had the problem again.
But I can't see doing that on the scale of a container ship!
Replying to my own post.... I forgot to mention a few things.
Given that a multi/hyper thread CPU is closer in complexity and cost to a single core CPU than a dual core one, it's more meaningful to compare it to a single CPU:
When a "context switch" occurs in a single CPU, the context that has to be saved is quite large: The entire application register space for starters. All of this gets copied to memory (OK, to the cache, and maybe eventually to memory as the new running context crowds it out of the cache.) Context switches between threads are handled by the OS.
When a similar "context switch" occurs between the two threads in a multi-threading CPU, the application registers are already duplicated, so no copy to memory is needed. Less context switch overhead. The OS sees the chip as if it were two CPUs, both making forward progress. The context switching happens at a hardware level, below and invisible to the OS, and on a much finer-grained timeline.
In a hyper-threaded (as opposed to multi-threaded) CPU, there's not even an exact identifyable moment when a context switch occurs. In many clock cycles, both threads REALLY DO make concurrent forward progress.
Eventually a real OS context switch has to occur of course (the CPU probably supports only two threads, but the OS supports more than two). When a real OS context switch does have to happen, i.e. you were running threads A and B, and you now want to run threads C and B, the multithread CPU offers another advantage. During all the context save (thread A) and context load (thread C), good old thread B continues to make useful forward progress during all the time thread A and then thread C are blocked on slow loads and stores. In the absence of multithreading, nobody would be making forward progress.
One final observation. A lot of people seem to be thinking that multi/hyper-thread is somehow an alternative to multiple core, as though the two technologies are mutually exclusive: They are not. We WILL be seeing CPUs in the future that contain multiple cores, each of which is multi-threading. And, of course, we'll be seeing multi-socket systems with several of these chips installed.
Don't think of hyperthreading as an alternative to dual-core or 2-way SMP. It isn't. Think of hyperthreading as a way of squeaking out more usage from the existing execution units in your CPU.
Lets say you have a hypothetical CPU with n execution units. (For simplicity, we won't distinguish between types of execution unit, such as integer, floating point, branch, etc).
You fetch and decode a bunch of instructions, and then issue them n-at-a-time to these execution units, for maximum performance.
But, the instruciton stream has some inherent limitations on which instructions can be issued concurrently, due to dependencies between instructions, instruction type mix mismatching available execution unit type mix, and instructions waiting on loads, etc. Even with control and data speculation, there may be fewer than n instructions READY to issue on the next clock cycle.
So, you have three choices:
1. Just issue the ready instructions, and let the other execution units go to waste.
2. Switch to another thread, maybe it has n instructions READY to run. (This is usually called on-chip multithreading).
3. Issue a mix of READY instructions, some from one thread, and some from another thread, which combined together use all n execution units. Both threads get to make some forward progress, and no execution units are "wasted". (This is usually called on-chip hyperthreading).
So, back to the big picture: Hyperthreading isn't a replacement for a second CPU or core, because it does not provide any more computation resources. It's a way of using the available resources in a CPU more efficiently, so that fewer computation units are likely to go to waste on any given clock cycle.
A dual core chip typically duplicates almost ALL the circuitry on the chip, often even including the caches. Big chips have low yields and cost a lot. Dual core is a way of throwing a lot of money at getting more parallelism. Kind of like having multiple CPUs in separate sockets, but with both advantages and disadvantages coming from the closer coupling. Hyperthreading is a way of throwing far less money at the problem of squeaking out some of the wasted performance in an existing CPU design.
It isn't free, by the way. Hyperthreaded CPUs do have to duplicate some hardware on a per-thread basis. Obviously, thread context registers like program counter and stack pointer have to be duplicated, as do application registers. But they share caches, execution units, decoders, memory management units (mostly), bus interface logic, etc.
Plenty of memories from when I was 3. My parents moved to a new home and neighborhood before I turned 4, so I know these memories predate that. They include walks in the neighborhood, the arrival of the ice-cream truck, some very detailed memories of the architecture of the house, etc.
Perhaps the earliest was waking up in the night, and bugging my parents about "when will it be daytime again?". Their answer, "tomorrow", didn't make sense for a few minutes, but then I understood for the first time the concept of a succession of days alternating with nights, and the words "yesterday", "today" and "tomorrow" stared to gel meaningfully in my vocabluary.
That memory seems much earlier than the others I mentioned, so perhaps it predates 3. Perhaps I was 2, I dunno.
Nonsense. You can bring a light airplane down on any flat surface that is a couple hundred feet long
Maybe true. That depends a lot on what you fly: I've logged thousands of hours in gliders, and very light singles, and have landed off-airport in farm fields, pastures, etc., many many times, with never a scratch.
On the other hand, I had an engine failure in my Pitts S1-E once. It was in the US northeast, where there are nothing but trees as far as the eye can see. Very luckily, I was close to an airport, and made it onto a runway OK. Had I been a mile further from the airport, I'd probably have taken my chances hitting the silk, rather than risk putting the Pitts into the trees.
As for a "couple hundred feet", forget it: The Pitts is a very light airplane, but it also has a very high stall speed, tiny wheels, poor forward visibility, and a high likelihood of flipping inverted if you land in soft or excessively rough ground. And egress from an inverted Pitts can be problematic.
As for "skimming the top of trees", I've seen that go both ways: The plane typically does NOT end up hanging from the treetops. It but usually either slows, pitches down and hits the underlying ground nose-first, or one wing catches something solid while there is still significant airspeed, and you get a sort of cartwheel effect.
I've only witnessed, first hand, two landings into trees. Both involved servere damage but only minor injuries. But in one case, it came very close to being a trajedy. The plane was slowed by the treetops, pitched down, and hit the underlying swamp nose-first. It ended up with its nose burried so deep in mud that even when the supporting trees were cut down, it remained upright, tail in the air, all by itsself. Had this same accident occurred over harder ground, it would have undoubtedly been fatal.
The day I quit, my employer went ballistic because he found out that I was going to work for a company he perceived as being a competitor. He chewed me out for being "unethical" by taking all my hard-earned knowledge off to a competing company, and threatened to sue me (on unspecified grounds).
Time went by. No lawsuit. Then I got a call from a friend and former co-worker, still working my former boss. He wanted help with a project. I gave him the help he needed, no charge. I didn't do it out of loyalty to my ex-employer, of course, but rather out of personal loyalty to my ex coworker who would have been in a bind otherwise.
My friend told me later that, for months afterwards, my ex-employer went around bragging about his good judgement in choosing to "overlook" my ethical lapse, and not sue. (In reality, I suspect that he didn't choose not to sue, but was told by his lawyers that he didn't have a case.)
Since then, I've had a call at least once a year from the ex-employer, trying to entice me back to the company. Fat chance.
How can an article about frontside bus and memory latency entirely ignore the concept of request pipelining? Huh?
And why all that complex hand-waving about practical upper limits to burst length. He gave all kinds of secondary limiting factors, but missed the obvious one: How about the simple arguement that long bursts are useless unless you have a reasonable expectation that the speculativly fetched portion of the data will be consumed. Moving lots of data fast is only useful if a substantial fraction of it is data that you care about.
(It's the same reason that there's an upper bound on the useful cache line size.)
The strangest one I ever saw was the application written in object-oriented K shell! It was a complex run-script for a Verilog simulation environment. To protect the guilty, I won't identify where I saw it. (NO, I wasn't the guilty party, even though I am the worlds worst programmer!) The person who showed it to me was the current maintainer, who had inherrited it from a former collegue, since departed from the company. He wasn't too thrilled with being responsible for its maintenence, but admitted that it worked "remarkably well". The program has since been retired.
I forget the details, but the basic idea was something like...
Object instances were represented by directories. Methods were represented by shell scripts named for the methods. Derived objects were represented by subdirectories. Overlaid methods would be scripts in the subdirecrory, and inherited methods (from the parent directory) would be used if the script wasn't present. Instance variables were data files in the corresponding object directory. I think class and global variables were stored in environment variables, but I'm a little hazy on that. The whole scheme relied heavily on scripts that walk directory trees, programs that exec each other, inherited environment variables, and scripts inheriting settings from other scripts by sourcing them.
I'm also hazy on how fullly it really implemented the concept of classes independent of class instances (i.e. objects).
As for the big question: Why??? I was never able to find an answer.
Counting only first-level cache is very misleading. For example, Itanium 2 has 3 levels of on-chip cache.
The first level (L0) is 16k data + 16k instruction.
The second level (L1) is 256k unified.
The third level (L2) is 3MB unified.
At any given time, you have several instruction bundles being fetched from the L0 instruction cache, and several data operands being read or read+invalidated (for writes) from the L0 data cache. These represent simultaneous processing on multiple instructions (due to 'explicit parallelism' in the architecture), and also speculative fetching and execution, even past a control transfer.
If an L0 miss on any of these cycles were to automatically cause a pipeline stall, then I'd agree with your assertion that the first level cache is all-important. But it doesn't work that way! The exact mix of L0 hits & misses only determines which subset of the outstanding instructions make forward progress first -- while waiting for the other L0 miss cycles to complete from L1 or L2.
In fact, what really matters is that a high enough percentage of the outstanding cycles hit L0 to ensure that useful work can continue during the L1 or L2 latency. Beyond that percentage, a higher L0 hit rate is not required!
So, L0 misses aren't such a big deal. Now, L2 misses are a huge deal!
Comparing only first level cache sizes does an injustice to modern CPUs like Itanium 2 that can exploit parallelism and speculative execution.
(By the way, this wasn't a paid advertisement for Itanium 2. It just happens that it's the architecture I'm familiar with.)
"Assuming there are approximately 300 million Americans, with 2/3 having upwards of 2 TV sets, that amounts to close to 500 million or more perfectly functional TVs that will..."
I know it's tangential to your main point, but I can't let those numbers stand. Since the FCC jusrisdiction is the USA, I'll interpret your reference to "Americans" to refer to those in the USA only. As you stated, that's a little under 300 million people total. So far so good.
I'll also assume most TVs are in homes. I think it's fairly safe to ignore other locations as an insignigicant fraction of the total.
So, by your numbers, an average family of five should have eight TV sets(!)
I don't know where you got the 1.75+ per person figure, but it can't be real. 1.75 per *household* MIGHT be true in some circles, but even that I doubt it very much as an average for the US. Even if so, it's meaningless without taking into account the average household size.
With the exception of a few single individuals living alone, I don't remeber ever walking into someone's home, and seen as many as 1.75 TVs per resident.
You don't appear to have actually read my post: Far from advocating 20kHz (as you suggest I was doing), in fact I explicitly said that 20kHz was a bad idea, but for other reasons. My post ONLY concerned the fallacy of assuming that iron cores would be used at 20kHz.
So bear with me, and please give a substantive answer based upon the physics of transformers, not some flip comment about my ignorance -- which I readily admit. I'm not going to go back to school -- I'm closer to retirement age than college age.
I admit that I know nothing about scaling ferrite transformers to large scales. I have designed dozens of switchmode power converters in my career, but only up to about 500W. I've used frequencies from 20kHz to about 500kHz. But, I've never designed a 50/60Hz transformer in my life, so I know only one side of the coin.
In that low power regime, there is no inherent "size limitation" mitigating against 20kHz/ferrite versus 50Hz/iron. On the contrary, both the size and weight (both core and copper), strongly favor the higher frequency solution. Cost typically favors low frequency iron, of course.
So, the "obvious" size limitations to which you refer must be some factor that becomes dominant as sizes are scaled up. I can think of some possible factors, but none that are compelling.
Perhaps you can give a simple explaination of the physics of why large-scale ferrite transformers should are impractical.
But if, instead, you choose to post another disparaging comment about my lack of education, that's OK too. I can take it.
If you increase the frequency by a factor f, you end up increasing hysteresis losses by f as well, and this is a *very* big deal. In short, transformers would be much less efficient.
I can think of plenty of reasons why 20kHz may not be ideal, but transformer efficiency is definitely not one: Transformers would be way more efficient, lighter, and more compact, because they'd no longer require iron cores.
Sure, iron laminate core transformers would suck bug time at 20kHz, but the only reason we now use those monstrosities is because of the choice of such a low AC line frequency, 50~60 Hz. If we used 20kHz, just substitute ferrite cores instead of iron laminate, and you instantly have smaller, lighter, way more efficient transdormers.
Slashdot Mirror
I don't know what standards of proof apply, but whatever they are, they appear to be a suitable deterrent -- at least in Colorado.
The Colorado version of this law has been VERY effective. I've gone from receiving several calls per day, to one or two per month.
I've never tried to actually prosecute one of the few remaining telemarketers, though. I just tell them never to call again, and I hang up.
On the other hand, HPUX is a high-octane commercial UNIX that has somehow managed to get by for years with the world's worst NFS implimentation.
I don't know how or why HP's customers have put up with it, but somehow, they have.
Yeah, I tried GRUB once on my PC, and resolved to go back to it once it became more mature. I liked the concept, but at the time it didn't work very well. That was quite a while ago, so perhaps now's the time.
As for the question of whether firmware should implement an OS, I'm undecided. As a hardware designer, my expectations are probably very different to yours, because I think mostly in terms of system hardware validation, bringup, debug, and production test.
Much of this code wants to run as close to the "bare metal" as possible. When something fails, I don't want to dig through any more layers of software than I have to, to find the root cause. So there's a lot to be said for using the lowest level environment that just provides enough functionality to abstract away differences in devices, networking stack, and access to filesystems. EFI isn't ideal, but it's sure better than nothing, and it's way better than Linux or (groan) Windows for this purpose.
EFI my be a new thing to most IA-32 users, but it's already the established standard for IA-64 firmware. So, I have hands on experience using it.
I beleive the statement about getting rid of text-mode-only startup is incorrect. I've used EFI extensively in systems that don't even have a graphics card installed, and it works just fine over a serial console.
EFI is like a little mini-OS that serves mainly as a boot loader environment, but can also be used for running simple batch scripts and executables. System configuration utilities, OS installers, and diagnostic programs are all good candidates to build as EFI executables. For example, "elilo" is a Linux boot loader built as an EFI executable. To me, EFI seems more like MS-DOS than anything else.
EFI has modular drivers, so you can support different boot devices, network stacks, etc., and use them for pre-OS-boot tasks such as installation, configuration, etc.
Since EFI can mount (some) filesystems, and the booted OS can subsequently mount the same filesystem, an EFI partition is a useful place. For example, when you build a new linux kernel, you just copy it into the mounted EFI partition, modify the elilo.conf file (also in this partition), and the next boot will boot from the new file. No more scribbling to boot records.
Why did the polish airline crash?
The captain announced that the passengers could see an interesting landmark on their right.
So, all the poles moved to the right hand half of the plane, and it went unstable.
There once was a fellow named fisk
whose fencing was exceedingly brisk
so fast was his action
the Lorentz contraction
reduced his rapier to a disk.
(I'd attribute it, but I have no idea where it came from).
They fall down badly if you travel a slightly unusual itinerary such as:
For this type of route, with enough patience, you can still do much of your research on Travelocity. But you need to apply trial and error combinations of individual segments, then call the airline to get the REAL price, which is often quite a bit lower, especially in the discontinuous example.
Another reason to actually call the airline rather than book online, is that they occasionally offer you a lower fare that is technically unavalable because the cutoff date has passed. I guess they have some discretionary flexibility. I don't know why they voluntarily do this, but it's happend to me more than once. British Airways is particularly good about this.
Menus and keys/buttons with multiple functions are not very intuitive.
If your feature list is so long that menus and multi-function buttons are unavoidable, try to use them only for the more exotic frills. Dedicate a few buttons to the basic functionality, and perhaps a few to the more basic of the frills. Multiplex the remaining frills onto the remaining buttons. Above all, make sure that the basic stuff remains accessible at all times, and it's operation is not interrupted or modified in any way by the current state of the menuing system.
The best candidates for menus and multifunction buttons, if unavoidable, are things that are typically accessed very seldom or once only -- like setup features.
Divide all the features into two piles: basic functionality, and frills: Basic functionality is the stuff that defines your product. Without this, your product isn't useful. Frills are the other stuff that may be useful, cool, and possibly even set your product apart from the competition, but doesn't define the product.
For example, if you were designing a phone, basic funtionality is dialing numbers to make outgoing calls, and receiving incoming calls. Period. That's it. Frills include everything else: speed dialing, programmable ring tones, redial, phone book, call log, etc.
Now stick to this simple rule: No frill should ever, in any way, make a basic functionality feature any more difficult to use, harder to find, or less intuitive. Never!
For a classic example, consider those Nokia phones that have a single, multifunction button, that serves a SEND, END, MENU, and a zillion other multiplexed functions. You can be on a call, and need to hang up, but because of other unrelated features (e.g. address book access, volume control, etc.), the multi-function button doesn't happen to be behaving as an END button at the time. You've got to look at the screen and back out of menus, until you see END, and then push the button. That's ugly, and it's all because frills were multiplexed onto the same contols as basic functionality, in a way that interfered with the basic functionality.
I suppose a more sophisticated strategy would involve multiple categories of features, ordered from most basic to most frilly. In that case, no feature may ever be allowed to cause any feature in a "more basic" category to be any more difficult, or less intuitive. But with just 2 categories and a strict adherence to this rule, you'll already be ahead of 90% of the gizmos on the market.
Do commercial freight ships even use magnetic compasses any more..
No first-hand knowledge, but I'd be very surprised if they didn't use them.
At least in aviation, the general philosophy is that instruments can get as complex and sophisticated as you like, but the basic "fallback" low-tech instruments must be present to use when all else fails, and they must be routinely checked for functionality even if they are hardly ever used.
For an airplane, that's altitude, airspeed, and magnetic compass. (And others if IFR). I don't know what the list would be for a container ship or supertanker, but I'd bet it includes a low-tech magnetic compass.
I'd worry about permanently magnetizing the hull.
Sure, there won't be enough residual that it sticks to other passing ships, or anything, but what about interference with magnetic compasses.
I had a steel-tube frame airplane, and it got so magnetized from arc welding that the mag compass was totally useless. No amount of swinging could correct the compass deviation. Nor did it help to replace the mag compass with a new one. I ended up degaussing the whole fuselage with a degauss coil designed for TV sets, and never had the problem again.
But I can't see doing that on the scale of a container ship!
Replying to my own post.... I forgot to mention a few things.
Given that a multi/hyper thread CPU is closer in complexity and cost to a single core CPU than a dual core one, it's more meaningful to compare it to a single CPU:
When a "context switch" occurs in a single CPU, the context that has to be saved is quite large: The entire application register space for starters. All of this gets copied to memory (OK, to the cache, and maybe eventually to memory as the new running context crowds it out of the cache.) Context switches between threads are handled by the OS.
When a similar "context switch" occurs between the two threads in a multi-threading CPU, the application registers are already duplicated, so no copy to memory is needed. Less context switch overhead. The OS sees the chip as if it were two CPUs, both making forward progress. The context switching happens at a hardware level, below and invisible to the OS, and on a much finer-grained timeline.
In a hyper-threaded (as opposed to multi-threaded) CPU, there's not even an exact identifyable moment when a context switch occurs. In many clock cycles, both threads REALLY DO make concurrent forward progress.
Eventually a real OS context switch has to occur of course (the CPU probably supports only two threads, but the OS supports more than two). When a real OS context switch does have to happen, i.e. you were running threads A and B, and you now want to run threads C and B, the multithread CPU offers another advantage. During all the context save (thread A) and context load (thread C), good old thread B continues to make useful forward progress during all the time thread A and then thread C are blocked on slow loads and stores. In the absence of multithreading, nobody would be making forward progress.
One final observation. A lot of people seem to be thinking that multi/hyper-thread is somehow an alternative to multiple core, as though the two technologies are mutually exclusive: They are not. We WILL be seeing CPUs in the future that contain multiple cores, each of which is multi-threading. And, of course, we'll be seeing multi-socket systems with several of these chips installed.
Don't think of hyperthreading as an alternative to dual-core or 2-way SMP. It isn't. Think of hyperthreading as a way of squeaking out more usage from the existing execution units in your CPU.
Lets say you have a hypothetical CPU with n execution units. (For simplicity, we won't distinguish between types of execution unit, such as integer, floating point, branch, etc).
You fetch and decode a bunch of instructions, and then issue them n-at-a-time to these execution units, for maximum performance.
But, the instruciton stream has some inherent limitations on which instructions can be issued concurrently, due to dependencies between instructions, instruction type mix mismatching available execution unit type mix, and instructions waiting on loads, etc. Even with control and data speculation, there may be fewer than n instructions READY to issue on the next clock cycle.
So, you have three choices:
1. Just issue the ready instructions, and let the other execution units go to waste.
2. Switch to another thread, maybe it has n instructions READY to run. (This is usually called on-chip multithreading).
3. Issue a mix of READY instructions, some from one thread, and some from another thread, which combined together use all n execution units. Both threads get to make some forward progress, and no execution units are "wasted". (This is usually called on-chip hyperthreading).
So, back to the big picture: Hyperthreading isn't a replacement for a second CPU or core, because it does not provide any more computation resources. It's a way of using the available resources in a CPU more efficiently, so that fewer computation units are likely to go to waste on any given clock cycle.
A dual core chip typically duplicates almost ALL the circuitry on the chip, often even including the caches. Big chips have low yields and cost a lot. Dual core is a way of throwing a lot of money at getting more parallelism. Kind of like having multiple CPUs in separate sockets, but with both advantages and disadvantages coming from the closer coupling. Hyperthreading is a way of throwing far less money at the problem of squeaking out some of the wasted performance in an existing CPU design.
It isn't free, by the way. Hyperthreaded CPUs do have to duplicate some hardware on a per-thread basis. Obviously, thread context registers like program counter and stack pointer have to be duplicated, as do application registers. But they share caches, execution units, decoders, memory management units (mostly), bus interface logic, etc.
Hope this paints a clear picture.
This is certainly the greatest non-DNA information density per square cubit ever reported.
Probably because it's the only information density "per square cubit" ever reported.
Plenty of memories from when I was 3. My parents moved to a new home and neighborhood before I turned 4, so I know these memories predate that. They include walks in the neighborhood, the arrival of the ice-cream truck, some very detailed memories of the architecture of the house, etc.
Perhaps the earliest was waking up in the night, and bugging my parents about "when will it be daytime again?". Their answer, "tomorrow", didn't make sense for a few minutes, but then I understood for the first time the concept of a succession of days alternating with nights, and the words "yesterday", "today" and "tomorrow" stared to gel meaningfully in my vocabluary.
That memory seems much earlier than the others I mentioned, so perhaps it predates 3. Perhaps I was 2, I dunno.
I don't get it.
See the movie "office space".
Nonsense. You can bring a light airplane down on any flat surface that is a couple hundred feet long
Maybe true. That depends a lot on what you fly: I've logged thousands of hours in gliders, and very light singles, and have landed off-airport in farm fields, pastures, etc., many many times, with never a scratch.
On the other hand, I had an engine failure in my Pitts S1-E once. It was in the US northeast, where there are nothing but trees as far as the eye can see. Very luckily, I was close to an airport, and made it onto a runway OK. Had I been a mile further from the airport, I'd probably have taken my chances hitting the silk, rather than risk putting the Pitts into the trees.
As for a "couple hundred feet", forget it: The Pitts is a very light airplane, but it also has a very high stall speed, tiny wheels, poor forward visibility, and a high likelihood of flipping inverted if you land in soft or excessively rough ground. And egress from an inverted Pitts can be problematic.
As for "skimming the top of trees", I've seen that go both ways: The plane typically does NOT end up hanging from the treetops. It but usually either slows, pitches down and hits the underlying ground nose-first, or one wing catches something solid while there is still significant airspeed, and you get a sort of cartwheel effect.
I've only witnessed, first hand, two landings into trees. Both involved servere damage but only minor injuries. But in one case, it came very close to being a trajedy. The plane was slowed by the treetops, pitched down, and hit the underlying swamp nose-first. It ended up with its nose burried so deep in mud that even when the supporting trees were cut down, it remained upright, tail in the air, all by itsself. Had this same accident occurred over harder ground, it would have undoubtedly been fatal.
The day I quit, my employer went ballistic because he found out that I was going to work for a company he perceived as being a competitor. He chewed me out for being "unethical" by taking all my hard-earned knowledge off to a competing company, and threatened to sue me (on unspecified grounds).
Time went by. No lawsuit. Then I got a call from a friend and former co-worker, still working my former boss. He wanted help with a project. I gave him the help he needed, no charge. I didn't do it out of loyalty to my ex-employer, of course, but rather out of personal loyalty to my ex coworker who would have been in a bind otherwise.
My friend told me later that, for months afterwards, my ex-employer went around bragging about his good judgement in choosing to "overlook" my ethical lapse, and not sue. (In reality, I suspect that he didn't choose not to sue, but was told by his lawyers that he didn't have a case.)
Since then, I've had a call at least once a year from the ex-employer, trying to entice me back to the company. Fat chance.
How can an article about frontside bus and memory latency entirely ignore the concept of request pipelining? Huh?
And why all that complex hand-waving about practical upper limits to burst length. He gave all kinds of secondary limiting factors, but missed the obvious one: How about the simple arguement that long bursts are useless unless you have a reasonable expectation that the speculativly fetched portion of the data will be consumed. Moving lots of data fast is only useful if a substantial fraction of it is data that you care about.
(It's the same reason that there's an upper bound on the useful cache line size.)
The strangest one I ever saw was the application written in object-oriented K shell! It was a complex run-script for a Verilog simulation environment. To protect the guilty, I won't identify where I saw it. (NO, I wasn't the guilty party, even though I am the worlds worst programmer!) The person who showed it to me was the current maintainer, who had inherrited it from a former collegue, since departed from the company. He wasn't too thrilled with being responsible for its maintenence, but admitted that it worked "remarkably well". The program has since been retired.
I forget the details, but the basic idea was something like...
Object instances were represented by directories. Methods were represented by shell scripts named for the methods. Derived objects were represented by subdirectories. Overlaid methods would be scripts in the subdirecrory, and inherited methods (from the parent directory) would be used if the script wasn't present. Instance variables were data files in the corresponding object directory. I think class and global variables were stored in environment variables, but I'm a little hazy on that. The whole scheme relied heavily on scripts that walk directory trees, programs that exec each other, inherited environment variables, and scripts inheriting settings from other scripts by sourcing them.
I'm also hazy on how fullly it really implemented the concept of classes independent of class instances (i.e. objects).
As for the big question: Why??? I was never able to find an answer.
Well, blender may be the greatest thing since sliced bread, but blender.org sure have a lame web page!
You shouldn't have to resort to Google to find out what Blender is, or what it does. Nor should you have to dig many levels deep in links to find out.
Where's the "What is blender" link? Or, the "Blender FAQ" link? Or, just the one paragraph description on the top-level home page?
Maybe some day when it's less slashdotted, I'll explore some more.
The first level (L0) is 16k data + 16k instruction.
The second level (L1) is 256k unified.
The third level (L2) is 3MB unified.
At any given time, you have several instruction bundles being fetched from the L0 instruction cache, and several data operands being read or read+invalidated (for writes) from the L0 data cache. These represent simultaneous processing on multiple instructions (due to 'explicit parallelism' in the architecture), and also speculative fetching and execution, even past a control transfer.
If an L0 miss on any of these cycles were to automatically cause a pipeline stall, then I'd agree with your assertion that the first level cache is all-important. But it doesn't work that way! The exact mix of L0 hits & misses only determines which subset of the outstanding instructions make forward progress first -- while waiting for the other L0 miss cycles to complete from L1 or L2.
In fact, what really matters is that a high enough percentage of the outstanding cycles hit L0 to ensure that useful work can continue during the L1 or L2 latency. Beyond that percentage, a higher L0 hit rate is not required!
So, L0 misses aren't such a big deal. Now, L2 misses are a huge deal!
Comparing only first level cache sizes does an injustice to modern CPUs like Itanium 2 that can exploit parallelism and speculative execution.
(By the way, this wasn't a paid advertisement for Itanium 2. It just happens that it's the architecture I'm familiar with.)
"Assuming there are approximately 300 million Americans, with 2/3 having upwards of 2 TV sets, that amounts to close to 500 million or more perfectly functional TVs that will..."
I know it's tangential to your main point, but I can't let those numbers stand. Since the FCC jusrisdiction is the USA, I'll interpret your reference to "Americans" to refer to those in the USA only. As you stated, that's a little under 300 million people total. So far so good.
I'll also assume most TVs are in homes. I think it's fairly safe to ignore other locations as an insignigicant fraction of the total.
So, by your numbers, an average family of five should have eight TV sets(!)
I don't know where you got the 1.75+ per person figure, but it can't be real. 1.75 per *household* MIGHT be true in some circles, but even that I doubt it very much as an average for the US. Even if so, it's meaningless without taking into account the average household size.
With the exception of a few single individuals living alone, I don't remeber ever walking into someone's home, and seen as many as 1.75 TVs per resident.
You don't appear to have actually read my post: Far from advocating 20kHz (as you suggest I was doing), in fact I explicitly said that 20kHz was a bad idea, but for other reasons. My post ONLY concerned the fallacy of assuming that iron cores would be used at 20kHz.
So bear with me, and please give a substantive answer based upon the physics of transformers, not some flip comment about my ignorance -- which I readily admit. I'm not going to go back to school -- I'm closer to retirement age than college age.
I admit that I know nothing about scaling ferrite transformers to large scales. I have designed dozens of switchmode power converters in my career, but only up to about 500W. I've used frequencies from 20kHz to about 500kHz. But, I've never designed a 50/60Hz transformer in my life, so I know only one side of the coin.
In that low power regime, there is no inherent "size limitation" mitigating against 20kHz/ferrite versus 50Hz/iron. On the contrary, both the size and weight (both core and copper), strongly favor the higher frequency solution. Cost typically favors low frequency iron, of course.
So, the "obvious" size limitations to which you refer must be some factor that becomes dominant as sizes are scaled up. I can think of some possible factors, but none that are compelling.
Perhaps you can give a simple explaination of the physics of why large-scale ferrite transformers should are impractical.
But if, instead, you choose to post another disparaging comment about my lack of education, that's OK too. I can take it.
If you increase the frequency by a factor f, you end up increasing hysteresis losses by f as well, and this is a *very* big deal. In short, transformers would be much less efficient.
I can think of plenty of reasons why 20kHz may not be ideal, but transformer efficiency is definitely not one: Transformers would be way more efficient, lighter, and more compact, because they'd no longer require iron cores.
Sure, iron laminate core transformers would suck bug time at 20kHz, but the only reason we now use those monstrosities is because of the choice of such a low AC line frequency, 50~60 Hz. If we used 20kHz, just substitute ferrite cores instead of iron laminate, and you instantly have smaller, lighter, way more efficient transdormers.