MDW is f'd up, full stop. I fly out of Love Field and Hobby Airport quite regularly and have never felt they were unreasonable. The few times I've flown out of MDW (granted, near holidays), they just seemed anal and psycho. My wife and I got held up 10 minutes because the genius x-ray operator thought the clip on my wife's cell phone holster looked like a cigarette lighter, and so they had to rerun and then manually search her bag.
I personally read/. at +1, and have moderation totals hidden. I also have deselected "Willing to moderate" etc. in my profile. OTOH, I have excellent karma and see no reason to piss it away. If I feel my point deserves a bit of boost, I'll post at +2. The only way I know that my posts get modded up or down is by looking at my user information screen.
The way it works is if you have sufficient karma, your posts start out automagically at +2. When you post, there are checkboxes below the post for "No Karma Bonus" and "Post Anonymously." If you checkmark "No Karma Bonus," the post goes out at +1, otherwise it goes out at +2. If you click "Post Anonymously," it goes out as an AC post (which, IIRC, start at 0).
There's something to that. I think many mods read at 2 and up. I find that if any of my posts start at 2, they're much likely to go up. If I post w/out karma bonus, they're likely to languish at 1. Sure, I post some rather disposable comments at 1, but not all of them are as such. The difference in mod performance is much greater than the spread in post quality, IMHO. I'm sure being an AC, and thus starting at 0, is a double whammy, esp. since many people filter out ACs entirely.
More importantly, the effective resistance seen by the capacitor will change with time if you go through a careful enough regulator circuit. The load itself will draw so many amps at a fixed voltage. If you had a 100% perfect DC-DC convert (which doesn't exist, but bear with me), then the actual current draw from the capacitor will start off small, and only increase as the voltage of the capacitor approaches the voltage of the load. With a perfect DC-DC converter, Watts into the load == Watts out of the capacitor. That means V_load * I_load = V_cap * I_cap. Since the capacitor is at a much higher voltage, the current will be very small.
The effective resistance seen by the capacitor is given by V_cap / I_cap. (Remember Ohm's Law? V = IR. Solve for R to get the equation for effective resistance.) So, when the capacitor is very full, we don't draw much charge off it at all, theoretically. The load's resistance looks larger than it really is by a factor of (V_cap / V_load) squared. The effective resistance will look large to the capacitor for quite awhile, leading to a long time constant, until eventually the whole shebang falls off a cliff. (Actually, that's pretty reminscent of how batteries behave, too.)
Unfortunately, there are no perfect DC-DC converters. (The above analysis works fine if you're doing AC and using a transformer to convert voltages.) Switching power supplies, though, can gain most of this efficiency.
I can't imagine them trying to mesh two plates of carbon fiber carpet together like velcro, although that'd gain the maximum benefit if you could insulate the two from each other. I also can't imagine placing one plate over the other as useful, because you'll just get capacitance from charges stored at one tip vs. the other. I imagine instead they will instead cut the carbon fiber "carpet" into strips and line them up in the same "interlocking finger" pattern you see, for instance, under the pads of buttons on a remote control or keyboard. That way, you get your capacitance side-wall to side-wall. This image shows the configuration I'm speaking of. Imagine vertical columns of nanotubes growing out of the page along the black lines, with dielectric in the white areas. (Granted, I expect the density of these 'fingers' to be much greater in a realistic capacitor.)
I wonder, though, because like-repels-like (as someone else pointed out), how do you engage all the nanotubes, and not just the ones near the edges? The electric fields of all the electrons would tend to push them to the sidewall nanotubes, leaving no charge in the inner nanotubes. You'd have to make very tall, thin columns for this to work.
I've read through man pages that go on and on for 20 screens and never once explicitly state what the syntax is for declaring command line options [...]
I call shenanigans. The command line syntax is usually given in the first 10-15 lines of the man page. Besides, with 99.44% of UNIX commands, the syntax is generally "command [OPTIONS] [FILES]". Learn it once and you've learned it for most of UNIX.
And when you do go that route, might I suggest "pinfo"?
Actually, I kinda like both. I like 'man' pages because often time I have no idea what section will answer a particular question I have. Since a man page is flat, I can just grep through it looking for phrases I think relate to the issue. With Info pages, everything's all subdivided and categorized, so if I miscategorize my question, I'm going to be there awhile.
That said, Info files tend to be more complete than their man-page counterparts.
Errr, no, it was not a "new idea at Intel." It was an idea that had been festering at HP for awhile under the moniker PA-WW, and had acquired a thoroughly pervasive case of Kitchen Sink Syndrome. It ended up at Intel through a combination of factors, probably not the least of which was Intel's growing realization that x86 was getting hard to scale. (Intel may have been emboldened by the Mac 68K to PPC switch as well, given that had happened just before Intel joined forces w/ HP.) Thing is, when they took on EPIC in the early-to-mid 90s, I don't think they realized just how tall the ivory tower they were acquiring actually was.
Man, I'd love to see some insane hacker implement the full 5-chip iAPX 432 chipset in VHDL or Verilog and load it up onto a FPGA, with minor tweaks. For instance, ditch the practically-Huffman-coded opcodes. Much nicer schemes are available today. Oh, and fix address reach. 16-bit segments on a 32-bit CPU? Get real. Of course, such a project should only be undertaken for sheer hack value.
It'd be interested to see how a good, modern compiler might make use of such a beast. Then again, it may just be the second coming of the LISP machine.:-)
(Being only 30 myself, I can't say to have participated first-hand in that era. I was busy getting brain-damaged by BASIC and learning cursive. But, I now work at TI, and you'd be surprised how many of my wonderful coworkers had a hand in the TI Explorer. I try to be an astute student of computer architecture. TI Explorer was another machine that tried to close the "semantic gap" by providing very, very high level "machine code." See how many of those are around?)
This is why I mentioned the "session cache" idea. Once the server farm knows a session is active, any transactions that come in that modify the state the session might be interested in can go to a separate "things that happened since you last asked" database. That database can be really small, and discarded when convenient. The cost of discarding it is that you need to do a full query on the main database.
With this sort of approach, you can stick to a client-pull model, which as I understand it remains at the heart of AJAX. The server isn't notifying the client of changes, but rather the client connects periodically and asks "What's new?"
Am I wrong in thinking that's the model? (I'm truly curious, not as a web developer, but rather as a memory system architect. Similar problems come up in both spaces, though your latencies are measured in seconds and milliseconds, whereas ours are measured in microseconds and nanoseconds.)
Thank you. At the same time, background refreshes when the user isn't paying attention, such as GMail or the Yahoo Beta do, could generate many queries that the user will never notice but the DB has to endure. There needs to be a way to prioritize background activity over direct UI interactions, and/or optimize the server for these background refreshes. Random idea: You could have the server generate a parallel disposable mini-database of "things that have changed since the currently active sessions last refreshed." If a session ever appears bogus or lasts "too long," you can nuke its rows in this cache DB and do the full query in the main DB.
Ahh, so this is the rate at which the Cell can read RSX's local memory? That I'll believe. And I will equally agree "BFD!" The Cell does its work and dumps everything to main memory or the RSX's memory. RSX does its work and if it needs to communicate anything major back to the Cell, it does so through main memory. Makes perfect sense then.
I thought something seemed awful fishy. I thought the slide was summarizing performance of the Cell SPE and RSX, not the Cell's and RSX's ability to communicate with the RSX's local memory. If your statement's true, then this paragraph in TFA is full of it: (Emphasis mine.)
If you can write at 250x the read speed, it makes Cell local memory just about useless. That means you do all your work out of main memory, and the whole point of local is, well, pointless. This can lead to contention issues for the main memory bus, and all sorts of nightmarish to debug performance problems. Basically, if this Sony presentation to PS3 devs shown to us is correct, it looks like PS3 will be hobbled in a serious way.
It all begins to make a lot more sense, though, if this is about accesses from Cell or RSX to memory local to RSX. I admit ignorance on the RSX's architecture. I just know in my bones that those numbers aren't for a Cell SPE talking to its local memory.
It doesn't matter how the Cell processor is hooked up. The performance of the SPE's local memory is determined solely by the clock rate of the CPU. There's no way that main memory (which should be off chip, and thus subject to how Cell is integrated into the box) is 1000 times faster than local memory (connected directly to each SPE and dependent only on the CPU clock rate).
Either that, or a broken benchmark. Each Cell processor (Synergistic Processing Element -- SPE) shares its instruction fetch port with its data memory port. The SPE can buffer up 80 instructions at a time (2.5 fetch words), plus an additional 32 from a branch target. Fetch will stall if the memory system gets saturated with loads and stores. Properly written memory-intensive code includes explicit fetches to keep these buffers full. Incorrectly written code will cause problems. Still, that doesn't explain a 3 orders of magnitude drop.
If you look at the slides on the page I linked to above, you'll see the SPEs are not connected into the global address space. They connect to a private single ported memory, and to each other through two unidirectional rings. (The ring structure is not apparent from that diagram, but trust me, it's there.) These rings then connect to a DMA engine.
If you wade through this paper, you'll see that the Cell compiler implements a software cache. (The same paper also explains the instruction fetch mechanism mentioned above, BTW.) That is, it emulates a cache in software, using the DMA to actually move memory around. Depending on the nature of the benchmark and how it was written, it could be that the read benchmark spends all its time allocating stuff into this cache and waiting for it to arrive. Writes would be faster because the cache can "write behind" without having to wait for the allocation to happen, if the compiler is smart enough to know that the previous data will be entirely overwritten. So, if the benchmark goofed, then the results are meaningless.
Fact of the matter is that the SPEs are capable of reading 128 bits a cycle each (128 bytes / cycle across the 8 SPEs). Other benchmarks, such as the article recently posted to Slashdot about using Cell for scientific computation confirm that this thing hauls--and these are bandwidth-intensive tasks. The quoted paper did run some numbers on real silicon and showed numbers similar to their simulation results.
With all this in mind, I find it hard to believe that Cell is broken.
With even halfway decent antialiasing, serif fonts are perfectly readable even on my 100DPI monitor. Personally, I just don't like Arial. Gives me too many flashbacks to IE.
I think he meant it took a long time to install all the drivers because he installed them each one at a time, rebooting after each. Question is... did he download them first, or do a download-install-reboot cycle for each one?
Slashdot Mirror
Hooking a 5v fan to 12v and using it to cool the user instead of the computer qualifies as front page material? Wow. Slow news day already?
MDW is f'd up, full stop. I fly out of Love Field and Hobby Airport quite regularly and have never felt they were unreasonable. The few times I've flown out of MDW (granted, near holidays), they just seemed anal and psycho. My wife and I got held up 10 minutes because the genius x-ray operator thought the clip on my wife's cell phone holster looked like a cigarette lighter, and so they had to rerun and then manually search her bag.
--JoeI personally read /. at +1, and have moderation totals hidden. I also have deselected "Willing to moderate" etc. in my profile. OTOH, I have excellent karma and see no reason to piss it away. If I feel my point deserves a bit of boost, I'll post at +2. The only way I know that my posts get modded up or down is by looking at my user information screen.
The way it works is if you have sufficient karma, your posts start out automagically at +2. When you post, there are checkboxes below the post for "No Karma Bonus" and "Post Anonymously." If you checkmark "No Karma Bonus," the post goes out at +1, otherwise it goes out at +2. If you click "Post Anonymously," it goes out as an AC post (which, IIRC, start at 0).
--JoeBecause they're really living up to the "Coward" in "Anonymous Coward," perhaps?
There's something to that. I think many mods read at 2 and up. I find that if any of my posts start at 2, they're much likely to go up. If I post w/out karma bonus, they're likely to languish at 1. Sure, I post some rather disposable comments at 1, but not all of them are as such. The difference in mod performance is much greater than the spread in post quality, IMHO. I'm sure being an AC, and thus starting at 0, is a double whammy, esp. since many people filter out ACs entirely.
--JoeMore importantly, the effective resistance seen by the capacitor will change with time if you go through a careful enough regulator circuit. The load itself will draw so many amps at a fixed voltage. If you had a 100% perfect DC-DC convert (which doesn't exist, but bear with me), then the actual current draw from the capacitor will start off small, and only increase as the voltage of the capacitor approaches the voltage of the load. With a perfect DC-DC converter, Watts into the load == Watts out of the capacitor. That means V_load * I_load = V_cap * I_cap. Since the capacitor is at a much higher voltage, the current will be very small.
The effective resistance seen by the capacitor is given by V_cap / I_cap. (Remember Ohm's Law? V = IR. Solve for R to get the equation for effective resistance.) So, when the capacitor is very full, we don't draw much charge off it at all, theoretically. The load's resistance looks larger than it really is by a factor of (V_cap / V_load) squared. The effective resistance will look large to the capacitor for quite awhile, leading to a long time constant, until eventually the whole shebang falls off a cliff. (Actually, that's pretty reminscent of how batteries behave, too.)
Unfortunately, there are no perfect DC-DC converters. (The above analysis works fine if you're doing AC and using a transformer to convert voltages.) Switching power supplies, though, can gain most of this efficiency.
--JoeI can't imagine them trying to mesh two plates of carbon fiber carpet together like velcro, although that'd gain the maximum benefit if you could insulate the two from each other. I also can't imagine placing one plate over the other as useful, because you'll just get capacitance from charges stored at one tip vs. the other. I imagine instead they will instead cut the carbon fiber "carpet" into strips and line them up in the same "interlocking finger" pattern you see, for instance, under the pads of buttons on a remote control or keyboard. That way, you get your capacitance side-wall to side-wall. This image shows the configuration I'm speaking of. Imagine vertical columns of nanotubes growing out of the page along the black lines, with dielectric in the white areas. (Granted, I expect the density of these 'fingers' to be much greater in a realistic capacitor.)
I wonder, though, because like-repels-like (as someone else pointed out), how do you engage all the nanotubes, and not just the ones near the edges? The electric fields of all the electrons would tend to push them to the sidewall nanotubes, leaving no charge in the inner nanotubes. You'd have to make very tall, thin columns for this to work.
--JoeI call shenanigans. The command line syntax is usually given in the first 10-15 lines of the man page. Besides, with 99.44% of UNIX commands, the syntax is generally "command [OPTIONS] [FILES]". Learn it once and you've learned it for most of UNIX.
And when you do go that route, might I suggest "pinfo"?
Actually, I kinda like both. I like 'man' pages because often time I have no idea what section will answer a particular question I have. Since a man page is flat, I can just grep through it looking for phrases I think relate to the issue. With Info pages, everything's all subdivided and categorized, so if I miscategorize my question, I'm going to be there awhile.
That said, Info files tend to be more complete than their man-page counterparts.
--JoeErrr, no, it was not a "new idea at Intel." It was an idea that had been festering at HP for awhile under the moniker PA-WW, and had acquired a thoroughly pervasive case of Kitchen Sink Syndrome. It ended up at Intel through a combination of factors, probably not the least of which was Intel's growing realization that x86 was getting hard to scale. (Intel may have been emboldened by the Mac 68K to PPC switch as well, given that had happened just before Intel joined forces w/ HP.) Thing is, when they took on EPIC in the early-to-mid 90s, I don't think they realized just how tall the ivory tower they were acquiring actually was.
--JoeMan, I'd love to see some insane hacker implement the full 5-chip iAPX 432 chipset in VHDL or Verilog and load it up onto a FPGA, with minor tweaks. For instance, ditch the practically-Huffman-coded opcodes. Much nicer schemes are available today. Oh, and fix address reach. 16-bit segments on a 32-bit CPU? Get real. Of course, such a project should only be undertaken for sheer hack value.
It'd be interested to see how a good, modern compiler might make use of such a beast. Then again, it may just be the second coming of the LISP machine. :-)
(Being only 30 myself, I can't say to have participated first-hand in that era. I was busy getting brain-damaged by BASIC and learning cursive. But, I now work at TI, and you'd be surprised how many of my wonderful coworkers had a hand in the TI Explorer. I try to be an astute student of computer architecture. TI Explorer was another machine that tried to close the "semantic gap" by providing very, very high level "machine code." See how many of those are around?)
--JoeOh, you know, the usual. Lots of hard drives, the occasional swapping, penetration testing, and lots of streaming from a big fat pipe.
Of course, with their new naming scheme, they could just call it "Hard Core Solo Extreme" and it'd actually even be a more appropriate name!
Disclaimer: I am not a database expert. :-)
This is why I mentioned the "session cache" idea. Once the server farm knows a session is active, any transactions that come in that modify the state the session might be interested in can go to a separate "things that happened since you last asked" database. That database can be really small, and discarded when convenient. The cost of discarding it is that you need to do a full query on the main database.
With this sort of approach, you can stick to a client-pull model, which as I understand it remains at the heart of AJAX. The server isn't notifying the client of changes, but rather the client connects periodically and asks "What's new?"
Am I wrong in thinking that's the model? (I'm truly curious, not as a web developer, but rather as a memory system architect. Similar problems come up in both spaces, though your latencies are measured in seconds and milliseconds, whereas ours are measured in microseconds and nanoseconds.)
--JoeThank you. At the same time, background refreshes when the user isn't paying attention, such as GMail or the Yahoo Beta do, could generate many queries that the user will never notice but the DB has to endure. There needs to be a way to prioritize background activity over direct UI interactions, and/or optimize the server for these background refreshes. Random idea: You could have the server generate a parallel disposable mini-database of "things that have changed since the currently active sessions last refreshed." If a session ever appears bogus or lasts "too long," you can nuke its rows in this cache DB and do the full query in the main DB.
--JoeAhh, so this is the rate at which the Cell can read RSX's local memory? That I'll believe. And I will equally agree "BFD!" The Cell does its work and dumps everything to main memory or the RSX's memory. RSX does its work and if it needs to communicate anything major back to the Cell, it does so through main memory. Makes perfect sense then.
I thought something seemed awful fishy. I thought the slide was summarizing performance of the Cell SPE and RSX, not the Cell's and RSX's ability to communicate with the RSX's local memory. If your statement's true, then this paragraph in TFA is full of it: (Emphasis mine.)
It all begins to make a lot more sense, though, if this is about accesses from Cell or RSX to memory local to RSX. I admit ignorance on the RSX's architecture. I just know in my bones that those numbers aren't for a Cell SPE talking to its local memory.
--JoeIt doesn't matter how the Cell processor is hooked up. The performance of the SPE's local memory is determined solely by the clock rate of the CPU. There's no way that main memory (which should be off chip, and thus subject to how Cell is integrated into the box) is 1000 times faster than local memory (connected directly to each SPE and dependent only on the CPU clock rate).
Either that, or a broken benchmark. Each Cell processor (Synergistic Processing Element -- SPE) shares its instruction fetch port with its data memory port. The SPE can buffer up 80 instructions at a time (2.5 fetch words), plus an additional 32 from a branch target. Fetch will stall if the memory system gets saturated with loads and stores. Properly written memory-intensive code includes explicit fetches to keep these buffers full. Incorrectly written code will cause problems. Still, that doesn't explain a 3 orders of magnitude drop.
If you look at the slides on the page I linked to above, you'll see the SPEs are not connected into the global address space. They connect to a private single ported memory, and to each other through two unidirectional rings. (The ring structure is not apparent from that diagram, but trust me, it's there.) These rings then connect to a DMA engine.
If you wade through this paper, you'll see that the Cell compiler implements a software cache. (The same paper also explains the instruction fetch mechanism mentioned above, BTW.) That is, it emulates a cache in software, using the DMA to actually move memory around. Depending on the nature of the benchmark and how it was written, it could be that the read benchmark spends all its time allocating stuff into this cache and waiting for it to arrive. Writes would be faster because the cache can "write behind" without having to wait for the allocation to happen, if the compiler is smart enough to know that the previous data will be entirely overwritten. So, if the benchmark goofed, then the results are meaningless.
Fact of the matter is that the SPEs are capable of reading 128 bits a cycle each (128 bytes / cycle across the 8 SPEs). Other benchmarks, such as the article recently posted to Slashdot about using Cell for scientific computation confirm that this thing hauls--and these are bandwidth-intensive tasks. The quoted paper did run some numbers on real silicon and showed numbers similar to their simulation results.
With all this in mind, I find it hard to believe that Cell is broken.
--JoeDunno. I'm upgrading via Synaptic, and it's pulling down at about the max my DSL can handle.
"Maintenance headache."
With even halfway decent antialiasing, serif fonts are perfectly readable even on my 100DPI monitor. Personally, I just don't like Arial. Gives me too many flashbacks to IE.
Did He create egg noodles?
*chuckle*
Thanks... I needed that.
I think he meant it took a long time to install all the drivers because he installed them each one at a time, rebooting after each. Question is... did he download them first, or do a download-install-reboot cycle for each one?
But it looks like General Failure attended to the other two laptops mentioned in the article.
I read it as "I couldn't verify that this is typical behavior on other laptops, because the two I had were dead for these other reasons."