Jumpers are not really used a lot these days. They cost extra, and are clumsy to handle (need to open case). You are right it would be really good if there were some precautions taken so no accidental writes happen (for instance need some special command sequence hard to trigger accidentally), but often those eeprom chips just have a simple serial interface, and reading and writing works almost exactly the same. A couple of years ago you could easily overwrite the eeprom of hauppauge tv cards (though there wasn't much information in there, just the exact model IIRC which was needed to set things up fully correct), a bug very similar to this.
Even the core2 doesn't use it. If they threw SMT on core2 it'd be SOLELY for a marketing gimmick and not because it helps.
Not quite true. This is all a question of how expensive the feature is to implement vs. how much performance improvement (which can vary a lot depending on the applications used) you will get. Nehalem (the core2 successor), if you're looking only at the core architecture, is little more than exactly that, a core2 with SMT (of course it has way more differences in the "uncore" area, cache organization, integrated memory controller etc.), and I doubt it's just for marketing purposes... Sure it will not double performance but OTOH it is fairly cheap to implement.
btw I take that back that ffmpeg doesn't support PAFF interlacing - this was implemented sometime last year. Still, I get errors and segfaults with certain streams.
ffpmeg's decoder may be "decent", but compared to CoreAVC it has still a few (depending on the circumstances, very severe) drawbacks:
- it is slower
- it doesn't support multithreading very well, so a slower dual-core cpu might still be not fast enough because it can only load one core fully
- it doesn't support some of the more strange features of h.264, which are often used with HDTV (such as PAFF deinterlacing - print an error and segfault)
So yes, I can definitely see why some people would want to use CoreAVC in MPlayer etc. At least right now, I guess once ffmpeg fixes points 2 and 3 above, few people would probably care that CoreAVC might be better optimized, since ffmpeg would be "good enough" (with better multithreading it should be "fast enough" at least with common dual-core cpus probably).
If you write it like that, not true. Power generally increases linearly with frequency. A cpu running at 4Ghz will use twice as much power as the same cpu running at 2Ghz (actually slightly less than twice since the leakage is the same).
The problem with this is that to achieve twice the frequency (for the same cpu), you likely need to increase the voltage (increasing voltage increases power at a rate of voltage^2), and there is only so much you can increase the voltage... If you'd design the cpu to reach higher frequencies from the ground up, you'd get other problems (need more transistors (more expensive, more power), more deeply pipelined (can lower performance).
(btw the voltage^2 power scaling isn't really true anymore, it's quite nonlinear with those small structures nowadays - in fact there's a exponential term too which will dominate scaling after a certain voltage.)
I'm sorry, but for the applications these laptops are going to be serving, 64GB of internal storage should be plenty.
Agreed. And if not, the HD in the MacBook Air doesn't really make a difference. If you think 64GB is paltry and not enough, 80GB probably won't be enough neither. The use of a traditional harddisk in the Air is purely a cost-cutting measure (and a quite effective one...). (Certainly 1.8 inch harddisks with more capacity (at least 160GB) exist - not sure if they'd fit into the Air, maybe their height is too large.)
(if you don't know, Silverthorne is intel's next-gen low-power chip for ultra-mobile applications)
The article states it goes down to 0.3V at idle - so it doesn't actually _run_ at that voltage (just preserve register contents). Compare this to Silverthorne which has a C6 Deep Power Down State - coincidentally at 0.3V... The article also states that this cpu uses 8-bit sram cells instead of the usual 6-bit sram cells - Silverthorne also uses 8-bit sram cells for its caches.
Granted maybe this design works at even lower voltages than does silverthorne (which seems to have an operating range of 0.7V-1.0V) but if they need 5 years to get it to market it might be too late...
(I've taken the silverthorne info from http://www.heise.de/newsticker/meldung/103038, in german, but it can now or soon likely be found elsewhere)
This looks to me like Windows XP SP2 already reports the installed ram and not the ram it actually uses (like Vista SP1 will do), rather than it using actually all 4GB which seems impossible from a technical perspective based on that description there... Yes the problem would only affect buggy drivers, but MS changed the HAL so these drivers will still run without trouble.
Unfortunately, this doesn't work. Windows XP with SP2 (and I assume Vista 32bit too though I'm not sure) will ignore physical addresses above 4GB even with the PAE switch. It probably would have worked with XP SP1 and earlier, but apparently MS changed this. See http://technet.microsoft.com/en-us/library/bb457155.aspx, section "Driver compatibility" - this is PAE specific not DEP.
I'll quote:
To constrain compatibility issues, Windows XP Service Pack 2 includes hardware abstraction layer (HAL) changes that mimic the 32-bit HAL DMA behavior. The altered HAL grants unlimited map registers when the system is running in PAE mode. In addition, the kernel memory manager ignores any physical address above 4 GB. Any system RAM beyond the 4 GB barrier would be made unaddressable by Windows and be unusable in the system. By limiting the address space to 4 GB, devices with 32-bit DMA bus master capability will not see a transaction with an address above the 4 GB barrier. Because these changes remove the need to double-buffer the transactions, they avoid a class of bugs in some drivers related to proper implementation of double buffering support.
The DRM is not more problematic. This is very much untrue. HD-DVD "only" supports AACS, while blu-ray additionally supports BD+. This runs some code in a virtual machine to ensure the player integrity. Now some discs are supporting this, and apparently older players have a lot of problems with these discs (that is, they don't work at all without a firmware upgrade). And if it works, it seems to cause longer load times and other performance issues. Now, it may be true that this is the fault of the players, but BD+ inherently is another "feature" which at best offers absolutely no benefit to the customer, and at worst causes lots of headaches. Plus, for software players, I really don't want the big media companies to be able to run arbitrary code on my box - I've got no idea what they are allowed to do in that vm, but there's no reason to not fear the worst...
I wonder why they don't just use the +5V standby line from DVI for that? Looks like it's there _exactly_ for that purpose... Granted, this won't work for TVs for instance, and for computer monitors only if it's connected with DVI, but not with VGA (but who cares nowadays?).
The problem isn't just one of overall bandwidth use, but also one of contention. Sure, but that can be dealt with. I'm not exactly sure how current chipsets handle it, but they certainly have some cache for display buffer, together with some logic for prioritization (if the display buffer is full, requests from the display controller to the memory controller have low priority, if it gets more empty priority will increase).
Further, when used for 3D the memory consumption will be greater because not only graphics memory but also texture memory is in system RAM. Yes but as said, that doesn't count as "drags down system performance". It will "only" drag down 3d performance. It will eat some ram, true, but as long as you have "enough" (at least 1GB) that shouldn't really be a problem.
And of course, you don't actually get peak bandwidth across the memory bus. It would be closer to peak (at least for intel cpus) if the frontside bus could actually keep up with the memory bandwidth, as FSB bandwidth is quite a bit lower:-). So you actually do have "free" bandwidth you can use without a penalty in theory...
But anyway, you don't need to trust my theoretical ramblings, the benchmarks speak for themselves. Unfortunately they are hard to find, boards with igps get seldomly reviewed (and even less both with and without using the igp). Here's some quick numbers: http://www.digit-life.com/articles2/mainboard/giga byte-965g-ds3-i965g.htmlNotice the non-3d benchmarks are within one percent if igp is enabled or not - though the resolution isn't stated (I'd guess it was 1600x1200 but I could be wrong...). I never said igps are fast for 3d:-).
In addition, if we could get them without shared memory, the performance would likely improve and it wouldn't drag down system performance. So that would be a great thing.
I don't know how much faster the "same" graphic chip would be if it just would get its own ram, but that igps drag down system performance is basically a myth nowadays. Used to be true when single-channel sdram was best you could get, but it's basically a non-issue with todays dual-channel ddr2 memory systems. (Bandwidth needed for scanout, which is basically what slows things down even if you don't do anything graphics related, hasn't increased that much - a 1920x1200x32 display at 60Hz would need roughly 500MB/s, if you have a chipset which provides 1066MB/s (single-channel 133Mhz sdr sdram) this is a lot but if you have a chipset which provides 12.8GB/s (dual-channel ddr2-800) it's just not that much.)
I really don't see why Microsoft went 32-bit on this version anyway...I'd say over %80 of the potential upgrade platforms and over %95 of all shipping PCs today support x86-64 mode I think this number might be a bit overestimated. There are still lots of notebooks sold with core duo (or pre-merom celeron M), though yes on the desktop you'd have trouble finding a pc without x86-64.
You would be correct, execpt what has been relesed is not the player key. In fact the player (device) key is one of the two that have not been released, the other one being the root key held by AACS LA. The key that has just been released and reusulted in this article is the processing key which can (and probably will) be changed for any disc authored after the previous key bacame known.
You're right, except it wouldn't make sense to change the key before the player used to find it is blacklisted, otherwise it would be very easy to find the new one right again. I'd guess future sw players will be harder to compromise, but it's probably just a matter of time...
Besides, Blu Ray is a better format. 50 GB per disk allows for lower compression ratios and uncompressed multichannel sound. The only advantage HD-DVD has is the "extras" and "interactivity features". I don't know about you, but I don't give a shit about picture-in-picture that they push so heavily. I just want to watch the goddamn movie.
The problem is, that picture-in-picture functionality you don't need, some blu-ray discs include such functionality just as well (apparently some people do like it). So how is it done if the format doesn't have that capability? Well, that's easy, they just store multiple versions of the complete film, one normal version and one which has the picture-in-picture overlay just directly integrated. There goes your higher storage capacity...
Apart from that, both formats offer enough storage for high-def movies. Apparently enough that a couple of blu-ray releases use the good old mpeg-2 codec...
Ok, so I guess K8L is not an "official" codename for Barcelona. It doesn't change the fact that everybody used it for this chip, and with good reason. Call it K10, but it's still an improved K8 (not that this is a bad thing - it is a good design, improve the areas where it is a bit weak, why reinvent the wheel).
* And separating integer and floating-point schedulers also accelerates this thing called virtualization
Separate issue queues are good but does it specifically benefit virtualization? - no.
True. Additionally, the article implies this is something new. All K8 chips (=Opterons, Athlon64) however always had seperate schedulers for float and int instructions (in contrast to the intel core2 chips, so amd is touting that as an advantage - it's more of a design choice than really a simple "better" or "worse" for either solution probably). There is a reason the codename of Barcelona is K8L! As you mentioned, it's certainly not somehow a completely new chip.
I'm pretty sure the 68000 only required a single 5V supply too.
Of course, it's kinda unfair to compare to 8088 to the 68000, a comparison to the 68008 (which is the "cheap" version of the 68000 similar to what the 8088 is to the 8086, only 8-bit bus, and only 20bit address bus instead of 24bit) would be more appropriate. This only required a 48-pin package, still more than the 8088 but quite a bit less than the 64-pin package of the 68000.
Too bad the 68008 only came out 1982, definitely after the IBM PC...
At least in Europe, 23W (120W equivalent) are easily available. You can get 30W, but they are not that common. I think the main issue here is size, those 30W CFLs get quite big (at least the length), even the 23W aren't exactly tiny, which might make them impractical to use or not even fit sometimes. Apparently, you can get 72W CFLs even as specialty items (found here, http://www.megaman.de/megamanenergiesparlampen/roe hrenform/jumbo52w/index.html, actually it's 4x18W), how's that for bright looking bulb... Doesn't really warrant the "C" in CFL though.
As for toxic waste, in Switzerland it's illegal to throw them into the garbabe too, but shops selling CFLs are required to take them back free of charge, irrespective where you bought them or if you buy something. Actually it's not really "free of charge", there is a fee paid if you buy the CFLs (works the same for batteries and most electronic gear).
The PPE has to copy whatever data the SPEs need onto their local memory store, and then move it back when they're done with it.
Not quite. The SPEs can copy the data they need themselves just fine to their local store. (But this doesn't change the fact that you can't just use the SPEs as additional cpus.)
If you're going to mention the really not that significant new SSE4 extension, you'd better mention EMT64 too, which is a much more important extension (definitely in terms of transistor count). And Core 2 Duo not only has internally twice as wide SSE units, it also has one unit more (3 instead of 2, though not every unit can do everything).
The 300D (Rebel) and 10D only had USB 1.1. Though the numbers of the GP don't add up anyway, a 200MB movie would still get downloaded in roughly 6 minutes (assuming roughly 600KB/s effective transfer rate which is reasonable for USB 1.1, unless it's a really really poor implementation), so if it took "HOURS" I suppose there was indeed some trouble with the USB port.
Slashdot Mirror
Jumpers are not really used a lot these days. They cost extra, and are clumsy to handle (need to open case). You are right it would be really good if there were some precautions taken so no accidental writes happen (for instance need some special command sequence hard to trigger accidentally), but often those eeprom chips just have a simple serial interface, and reading and writing works almost exactly the same. A couple of years ago you could easily overwrite the eeprom of hauppauge tv cards (though there wasn't much information in there, just the exact model IIRC which was needed to set things up fully correct), a bug very similar to this.
Even the core2 doesn't use it. If they threw SMT on core2 it'd be SOLELY for a marketing gimmick and not because it helps.
Not quite true. This is all a question of how expensive the feature is to implement vs. how much performance improvement (which can vary a lot depending on the applications used) you will get. Nehalem (the core2 successor), if you're looking only at the core architecture, is little more than exactly that, a core2 with SMT (of course it has way more differences in the "uncore" area, cache organization, integrated memory controller etc.), and I doubt it's just for marketing purposes... Sure it will not double performance but OTOH it is fairly cheap to implement.
btw I take that back that ffmpeg doesn't support PAFF interlacing - this was implemented sometime last year. Still, I get errors and segfaults with certain streams.
ffpmeg's decoder may be "decent", but compared to CoreAVC it has still a few (depending on the circumstances, very severe) drawbacks:
- it is slower
- it doesn't support multithreading very well, so a slower dual-core cpu might still be not fast enough because it can only load one core fully
- it doesn't support some of the more strange features of h.264, which are often used with HDTV (such as PAFF deinterlacing - print an error and segfault)
So yes, I can definitely see why some people would want to use CoreAVC in MPlayer etc. At least right now, I guess once ffmpeg fixes points 2 and 3 above, few people would probably care that CoreAVC might be better optimized, since ffmpeg would be "good enough" (with better multithreading it should be "fast enough" at least with common dual-core cpus probably).
Well, the Xonar D2X should work, whereas the Xonar DX not yet it seems: http://www.alsa-project.org/main/index.php/Matrix:Vendor-Asus Since the hardware is so similar I guess it shouldn't take too long but I don't really know...
If you write it like that, not true. Power generally increases linearly with frequency. A cpu running at 4Ghz will use twice as much power as the same cpu running at 2Ghz (actually slightly less than twice since the leakage is the same).
The problem with this is that to achieve twice the frequency (for the same cpu), you likely need to increase the voltage (increasing voltage increases power at a rate of voltage^2), and there is only so much you can increase the voltage... If you'd design the cpu to reach higher frequencies from the ground up, you'd get other problems (need more transistors (more expensive, more power), more deeply pipelined (can lower performance).
(btw the voltage^2 power scaling isn't really true anymore, it's quite nonlinear with those small structures nowadays - in fact there's a exponential term too which will dominate scaling after a certain voltage.)
(if you don't know, Silverthorne is intel's next-gen low-power chip for ultra-mobile applications)
The article states it goes down to 0.3V at idle - so it doesn't actually _run_ at that voltage (just preserve register contents). Compare this to Silverthorne which has a C6 Deep Power Down State - coincidentally at 0.3V... The article also states that this cpu uses 8-bit sram cells instead of the usual 6-bit sram cells - Silverthorne also uses 8-bit sram cells for its caches.
Granted maybe this design works at even lower voltages than does silverthorne (which seems to have an operating range of 0.7V-1.0V) but if they need 5 years to get it to market it might be too late...
(I've taken the silverthorne info from http://www.heise.de/newsticker/meldung/103038, in german, but it can now or soon likely be found elsewhere)
This looks to me like Windows XP SP2 already reports the installed ram and not the ram it actually uses (like Vista SP1 will do), rather than it using actually all 4GB which seems impossible from a technical perspective based on that description there... Yes the problem would only affect buggy drivers, but MS changed the HAL so these drivers will still run without trouble.
I'll quote:
I wonder why they don't just use the +5V standby line from DVI for that? Looks like it's there _exactly_ for that purpose... Granted, this won't work for TVs for instance, and for computer monitors only if it's connected with DVI, but not with VGA (but who cares nowadays?).
But anyway, you don't need to trust my theoretical ramblings, the benchmarks speak for themselves. Unfortunately they are hard to find, boards with igps get seldomly reviewed (and even less both with and without using the igp). Here's some quick numbers: http://www.digit-life.com/articles2/mainboard/gig
Apart from that, both formats offer enough storage for high-def movies. Apparently enough that a couple of blu-ray releases use the good old mpeg-2 codec...
Ok, so I guess K8L is not an "official" codename for Barcelona. It doesn't change the fact that everybody used it for this chip, and with good reason. Call it K10, but it's still an improved K8 (not that this is a bad thing - it is a good design, improve the areas where it is a bit weak, why reinvent the wheel).
I'm pretty sure the 68000 only required a single 5V supply too.
Of course, it's kinda unfair to compare to 8088 to the 68000, a comparison to the 68008 (which is the "cheap" version of the 68000 similar to what the 8088 is to the 8086, only 8-bit bus, and only 20bit address bus instead of 24bit) would be more appropriate. This only required a 48-pin package, still more than the 8088 but quite a bit less than the 64-pin package of the 68000.
Too bad the 68008 only came out 1982, definitely after the IBM PC...
At least in Europe, 23W (120W equivalent) are easily available. You can get 30W, but they are not that common. I think the main issue here is size, those 30W CFLs get quite big (at least the length), even the 23W aren't exactly tiny, which might make them impractical to use or not even fit sometimes. Apparently, you can get 72W CFLs even as specialty items (found here, http://www.megaman.de/megamanenergiesparlampen/roe hrenform/jumbo52w/index.html, actually it's 4x18W), how's that for bright looking bulb... Doesn't really warrant the "C" in CFL though.
As for toxic waste, in Switzerland it's illegal to throw them into the garbabe too, but shops selling CFLs are required to take them back free of charge, irrespective where you bought them or if you buy something. Actually it's not really "free of charge", there is a fee paid if you buy the CFLs (works the same for batteries and most electronic gear).
(But this doesn't change the fact that you can't just use the SPEs as additional cpus.)
If you're going to mention the really not that significant new SSE4 extension, you'd better mention EMT64 too, which is a much more important extension (definitely in terms of transistor count). And Core 2 Duo not only has internally twice as wide SSE units, it also has one unit more (3 instead of 2, though not every unit can do everything).
The 300D (Rebel) and 10D only had USB 1.1. Though the numbers of the GP don't add up anyway, a 200MB movie would still get downloaded in roughly 6 minutes (assuming roughly 600KB/s effective transfer rate which is reasonable for USB 1.1, unless it's a really really poor implementation), so if it took "HOURS" I suppose there was indeed some trouble with the USB port.