Wrong. Parse the grammar the way Intel does it not only makes sense but is very meaningful. What you're lacking are some font and other cues about what things are compound word nouns as well as some knowledge about what are legitimate threading concepts.
"The Intel Threading Tools automatically finds correctness and performance issues" (The tools finds?) Try italizing the product name: The Intel Threading Tools(product name) automatically finds correctness and performance issues and it looks much better gramatically once you realize the product name is singular, not plural (despite the last word ending in s)
"Along with sufficient task scheduler and generic parallel patterns" (Who has insufficient task scheduler?) Look at it as as function: sufficient( task scheduler and generic parallel patterns ). It gives you sufficient patterns for both of these. The blurb is, of course, aimed at someone who understands why threading tools need to have this kind of patterns.
"automatic debugger of threaded programs which detects many of thread-correctness issues such as data-races, dead-locks, threads stalls" (Sarcasm fails me...) Perhaps sarcasm fails you because it isn't helping you? Thread-correctness, data-races, dead-locks, and thread stalls are all common terms used in describing threading issues. Just because they sound funny to you doesn't mean they are not meaningful to people this product is aimed at. If you understand what they are this sentence makes perfect sense.
Please mod the writer down. All he/she is informing us of is his/her ignorance. There's nothing wrong with being unaware of threading concepts, but please don't suggest there's something wrong with things you just don't understand.
...or should Microsoft stick to its knitting while applications take advantage of (possibly) more resources?" Microsoft wishes to inform the writer that there are NO applications of any importance that are NOT from Microsoft. Anything worth wearing is already knitted by MSFT or will be in the future when they decide you are ready for it.
Yes, everyone has known about this for a long time - IF you could make a electronically controlled valve, the possibilies of dynamic 'virtual' camshaft are immense. I'm surprised they only project 20% efficiency gains. Should be much more than that. If they really have a practical variable valve....
That is not necessarily a bad thing. Making money will get companies to write more software for Linux, which is a good thing because it will speed Linux adoption. I would tend to agree, except I fear as that soon as the distro gets a financial stake in this, the urge to inhibit excellent free alternatives will be under pressure. It doesn't seem likely, but it's not impossible to imagine that someday a click-and-run MSFT Office vendor winds up pressuring Ubuntu to delisting Abiword and OpenOffice...
But with Dell making (reportedly) dozens of dollars per unit with licence fees from 'craplet' ISVs installed on Windows PCs, will it recover the difference with the net cost of Ubuntu (we assume Dell has a per-unit-based support contract with Canonical for these) over the OEM price for Windows. This may be closer to being even than you would think. (BTW, MSFT could solve the craplets issue on Vista easily - just compensate each OEM the dollar equivilient of their lost craplet revenue and I'm sure they would all jump at the chance. But would MSFT sell Vista to OEMs for possibly as under 10 bucks...?:-) ) No doubt MSFT would much prefer to make craplets impossible to install on Vista) So the question is, can ISVs start creating annoying Linux trialware that Synaptic Package Manager cannot exorcise and will be very hard to root out so Dell can start getting this cash flow again? Remember, that since almost all small useful utilities anyone would want are already easily available for free for right off the Add/Remove programs menu, these craplets must remain true to the tradition of trialware and be especially useless, annoying or (if they do do anything useful) timeout so soon they're infuriating. Any takers?
Except the shared bus the Xeons sit on is a seriously limiting factor, no-one in HPC is using Xeons because of it. Thats funny, because according to the current Nov 2006 Top 500 Supercomputer list, there are about 220 Xeon systems (EM64T and IA32) on it. I guess nobody told all those HPC professionals that nobody is using Xeons...
Why is it that manufacturing technology is not a engineering advantage in the same way as logic design? AMD is a year behind Intel on process technology (just mainstreaming 65nm now, not doing 45nm until later '08 at which point Intel will have been shipping 45nm for about a year). This isn't some kind of magic, unfair advantage that the semiconductor fairy bestowed on Intel and not AMD. It's a result of prudent choices about where to spend you development budgets and Intel has always cared more about keeping Moore's Law alive than anybody else, and generally it's been to Intel's benefit. So, to seriously suggest that we can't compare 45nm Intel product to 65nm AMD product - OR that we can only compare equivalent clocks. How about we only compare like memory architectures. Oh, no, embedded memory controllers are an advantage for AMD that Intel does'nt have! You see how ridiculous this gets...
AMD always has that card to play, simply but upgrading their fabs the same design that competes with Intel while using an inferior fab process will suddenly blow Intel away. That's silly. You're implying that for some reason AMD is choosing not use the best process technology it can right now? I think if AMD were in possession of that card, they would have played it. A recurring theme I see among AMD advocates is this persistent assumption that AMD's process gap is somehow momentary, and will soon be erased with AMD having the same process as Intel in the same time frame. This has almost never been true and I think you could successfully argue that the gap is WIDENING to more than a year. With Intel's new tick-tock model, you get 45nm in '07, 35nm in '09 and so forth - I haven't seen any rational observer suggest that AMD could even keep up to that with a 1-year gap, let alone catch up. The more likely outcome is that AMD keeps falling further behind on process.
AMD probably makes more per chip while selling at a lower price. Well you're first point is absolutely false. Check out the last earnings report, AMD's margins ARE much lower than Intel's - but you are probably right about AMD haveing a lower ASP (average selling price). Which is a huge problem for AMD, not to their credit. AMD would dearly love to raise prices and get their margins back into shape.
The 3.0GHz Clovertown quad core is already available, BTW. What AMD really needs to do to catch up is not raise the clock speed 200MHz to match Intel, it's to get their quad core (and beyond) chips out the door. HyperTransport should theoretically allow their chips to scale better than Netburst. Clovertowns are core architecture, not NetBurst. No one cares how HT helps AMD scale against NetBurst, the issue is how does HT scale against Core 2 and the coming 45nm products. Benchmarks have shown FSB is not necessarily bad.
Since AMD keeps pushing the ship date of Barcelona out (now Q3) and Intel keeps pulling ship date of Penryn-gen quads (Harpertown) in (now Q4, maybe Q3?) the relivant comparison is not going to be between Barcelona and Clovertown, but Barcelona and Harpertown. I suppose since, AMD only wants to compare same-clock chips (probably because they won't get higher clock Bars for a while) they may start argueing that we should only be allowed to compare Intel's old 65nm products (not the 45nm) to 65nm Barcelona, too. And Intel will ship Penryn processors IN VOLUME, so they'll be something you can buy, not just read about on test reviews designed to give the rest of AMDs product line a halo effect from one excellent part.
... So what's new about this? The older Intel NetBurst processors (which were not as efficent per clock, of course) actually hit 3.7GHz with the 'Dempsey' cpu. The real story about the clock being turned back on is Intel's 45nm Penryn derived products due in Q4, which have very low current leakage due to high K dialectic metal design. EARLY SAMPLES of these have been shown running at 3.2GHz, so it's anybody's guess how high Intel will be able to push that architecture. (Interestingly, despite being due in late Q2, the AMD Barcelonas have rarely been shown, and even when they are, I understand at only at low clock frequencies (less than 2.5GHz)). Rumour has it Intel will be releasing the Clovertown quad cores, now at 2.66GHz at 3.0GHz soon too...
is the comment The real question is, we suppose, how well will AMD's Barcelona perform in comparison. We now know Penryn's potential, but AMD keeps us guessing. Despite the fact that Barcelona is supposed to be shipping at the end of Q2 and Penryn is not due until Q4, Intel seems to be showing stable, polished systems running their 45nm product whereas AMD seems to be holding back early Barcelona silicon. WHY IS THIS?
Flash memory used for disk caching will greatly extend battery life, as disk accesses that are cache hits will not require a powered down drive to spin up which uses much more power than many, many flash memory reads (not to mention is much, much slower than getting it from cache). So the answer is yes, they improve battery life. How much? How disk intensive is your app?
This doesn't just affect frame pirates...
on
AMD's New DRM
·
· Score: 1
Many medical and other specialized applications render images onto the dedicated graphics memory then grab the framebuffer contents back for other processing. I assume this will break those apps unless they get some kind of special exemption access - which would probably be crackable if you allowed it at all. Hardware vendors have to fully think through the implications of what they do to enforce DRM.
... you take it out in US dollars and enjoy it in the real world. Hmmmm. So, if I travel to Country X and earn the equivlent of $3,000US in local currency - BUT spend it at a resort in in Country X, the IRS doesn't care? I think they do, so Second Life and the other alt realities are getting unique treatment, since it does appear that if you leave what happens in SL there and don't bring it home, the IRS doesn't care. Now, Leandra Lederman at the TaxProf blog seems to take a more strict interpretation - if you spend money on things in SL that are not 'game' things (not 'fun' I guess, although many would find making money a 'fun' or 'game' thing) that those would be taxable. I don't doubt that corporations that have done press conferences and product launches in SL have already real-world expensed these (not the Linden dollars, but the media consulting companies fees - which would have rolled in any US$ costs for buying Linden dollars to rent space, etc).
BTW, I gave a lecture on SL recently (uncompensated, you tax spooks!) in which the most interesting question was about whether people could use SL to launder money. My first reaction was that from the criminal's point of view, SL being a cashless society (all SL transactions are theoretically loggable and therefore external authorities could presumably subpoena the logs from Linen Labs) however, if they chose some classic real world money laundering techniques (buy or invest in a business, take the money out in proceeds and maybe even launder it again) it might make it hard enough to follow that SL might be viable for this. It's certainly a good way to get money moved internationally - except that it comes out in US$.
... to succeed: For the same reason there is are NO standards for external power bricks for laptops/printers/scanners/hubs etc. Because there is a high margin add-on market from manufacturers to replace proprietary power devices (when lost) with expensive branded units which are probably about 5x to 10x the cost of what generic units would if there was a some common defined types (V/ma/connector-types) which would be universal. A move to efficent USB power would undercut this business in the same way, so the only standard that will be agreed upon will be an unworkable one. Firewire never replaced USB because it had licence encumberences (cost more to use), alas.
The famous Steve Gibson, author of Spinrite, writes all his software (Windows mostly) in pure ASM and the speed and efficiency of his apps speak for themselves.
There are still many important changes that, popping up at the last minute, could seriously enrage an IT department, but I doubt it's as severe a problem as with Windows. Not that anyone would ever convince a rather conservative IT department of that... That's a very user-desktop-centric point of view and your concession that conservative IT would still want this is not only correct, but they're right and you're not. All the big corporate accts I work with insist on roadmap transpearancy from ALL vendors inlcuding big RISC/UNIX and mainframe system vendors (which have no Windows tie in) - in fact this becomes MORE important when the systems become more mission critical and complex. Apple makes great theatre with Jobs yearly MacWorld announcements, but this is so far from the detailed, non-disclosure timelines and product direction information that corporates require that, long after Apple had ditched the secrecy for business, competing vendors will be making jokes about Apple having just moved from being a "consumer toy company". ( And I think Apple could have a very compelling end-to-end technology story for corporates)
Slashdot Mirror
(end-of-msg)
..."Steve says 'It seems like a good idea' "
Wrong. Parse the grammar the way Intel does it not only makes sense but is very meaningful. What you're lacking are some font and other cues about what things are compound word nouns as well as some knowledge about what are legitimate threading concepts.
"The Intel Threading Tools automatically finds correctness and performance issues" (The tools finds?)
Try italizing the product name: The Intel Threading Tools(product name) automatically finds correctness and performance issues
and it looks much better gramatically once you realize the product name is singular, not plural (despite the last word ending in s)
"Along with sufficient task scheduler and generic parallel patterns" (Who has insufficient task scheduler?)
Look at it as as function: sufficient( task scheduler and generic parallel patterns ).
It gives you sufficient patterns for both of these. The blurb is, of course, aimed at someone who understands why threading tools need to have this kind of patterns.
"automatic debugger of threaded programs which detects many of thread-correctness issues such as data-races, dead-locks, threads stalls" (Sarcasm fails me...)
Perhaps sarcasm fails you because it isn't helping you? Thread-correctness, data-races, dead-locks, and thread stalls are all common terms used in describing threading issues. Just because they sound funny to you doesn't mean they are not meaningful to people this product is aimed at. If you understand what they are this sentence makes perfect sense.
Please mod the writer down. All he/she is informing us of is his/her ignorance. There's nothing wrong with being unaware of threading concepts, but please don't suggest there's something wrong with things you just don't understand.
...or should Microsoft stick to its knitting while applications take advantage of (possibly) more resources?"
Microsoft wishes to inform the writer that there are NO applications of any importance that are NOT from Microsoft. Anything worth wearing is already knitted by MSFT or will be in the future when they decide you are ready for it.
...check out these tools
....that FOSS software generates. I think a court should decide that's a fair compensation.
Yes, everyone has known about this for a long time - IF you could make a electronically controlled valve, the possibilies of dynamic 'virtual' camshaft are immense. I'm surprised they only project 20% efficiency gains. Should be much more than that.
If they really have a practical variable valve....
That is not necessarily a bad thing. Making money will get companies to write more software for Linux, which is a good thing because it will speed Linux adoption.
I would tend to agree, except I fear as that soon as the distro gets a financial stake in this, the urge to inhibit excellent free alternatives will be under pressure. It doesn't seem likely, but it's not impossible to imagine that someday a click-and-run MSFT Office vendor winds up pressuring Ubuntu to delisting Abiword and OpenOffice...
But with Dell making (reportedly) dozens of dollars per unit with licence fees from 'craplet' ISVs installed on Windows PCs, will it recover the difference with the net cost of Ubuntu (we assume Dell has a per-unit-based support contract with Canonical for these) over the OEM price for Windows. This may be closer to being even than you would think. :-) ) No doubt MSFT would much prefer to make craplets impossible to install on Vista)
(BTW, MSFT could solve the craplets issue on Vista easily - just compensate each OEM the dollar equivilient of their lost craplet revenue and I'm sure they would all jump at the chance. But would MSFT sell Vista to OEMs for possibly as under 10 bucks...?
So the question is, can ISVs start creating annoying Linux trialware that Synaptic Package Manager cannot exorcise and will be very hard to root out so Dell can start getting this cash flow again? Remember, that since almost all small useful utilities anyone would want are already easily available for free for right off the Add/Remove programs menu, these craplets must remain true to the tradition of trialware and be especially useless, annoying or (if they do do anything useful) timeout so soon they're infuriating.
Any takers?
(See Subject)
Except the shared bus the Xeons sit on is a seriously limiting factor, no-one in HPC is using Xeons because of it.
Thats funny, because according to the current Nov 2006 Top 500 Supercomputer list, there are about 220 Xeon systems (EM64T and IA32) on it.
I guess nobody told all those HPC professionals that nobody is using Xeons...
Why is it that manufacturing technology is not a engineering advantage in the same way as logic design? AMD is a year behind Intel on process technology (just mainstreaming 65nm now, not doing 45nm until later '08 at which point Intel will have been shipping 45nm for about a year). This isn't some kind of magic, unfair advantage that the semiconductor fairy bestowed on Intel and not AMD. It's a result of prudent choices about where to spend you development budgets and Intel has always cared more about keeping Moore's Law alive than anybody else, and generally it's been to Intel's benefit. So, to seriously suggest that we can't compare 45nm Intel product to 65nm AMD product - OR that we can only compare equivalent clocks. How about we only compare like memory architectures. Oh, no, embedded memory controllers are an advantage for AMD that Intel does'nt have! You see how ridiculous this gets...
AMD always has that card to play, simply but upgrading their fabs the same design that competes with Intel while using an inferior fab process will suddenly blow Intel away.
That's silly. You're implying that for some reason AMD is choosing not use the best process technology it can right now? I think if AMD were in possession of that card, they would have played it. A recurring theme I see among AMD advocates is this persistent assumption that AMD's process gap is somehow momentary, and will soon be erased with AMD having the same process as Intel in the same time frame. This has almost never been true and I think you could successfully argue that the gap is WIDENING to more than a year. With Intel's new tick-tock model, you get 45nm in '07, 35nm in '09 and so forth - I haven't seen any rational observer suggest that AMD could even keep up to that with a 1-year gap, let alone catch up. The more likely outcome is that AMD keeps falling further behind on process.
AMD probably makes more per chip while selling at a lower price.
Well you're first point is absolutely false. Check out the last earnings report, AMD's margins ARE much lower than Intel's - but you are probably right about AMD haveing a lower ASP (average selling price). Which is a huge problem for AMD, not to their credit. AMD would dearly love to raise prices and get their margins back into shape.
The 3.0GHz Clovertown quad core is already available, BTW. What AMD really needs to do to catch up is not raise the clock speed 200MHz to match Intel, it's to get their quad core (and beyond) chips out the door. HyperTransport should theoretically allow their chips to scale better than Netburst.
Clovertowns are core architecture, not NetBurst. No one cares how HT helps AMD scale against NetBurst, the issue is how does HT scale against Core 2 and the coming 45nm products. Benchmarks have shown FSB is not necessarily bad.
Since AMD keeps pushing the ship date of Barcelona out (now Q3) and Intel keeps pulling ship date of Penryn-gen quads (Harpertown) in (now Q4, maybe Q3?) the relivant comparison is not going to be between Barcelona and Clovertown, but Barcelona and Harpertown.
I suppose since, AMD only wants to compare same-clock chips (probably because they won't get higher clock Bars for a while) they may start argueing that we should only be allowed to compare Intel's old 65nm products (not the 45nm) to 65nm Barcelona, too.
And Intel will ship Penryn processors IN VOLUME, so they'll be something you can buy, not just read about on test reviews designed to give the rest of AMDs product line a halo effect from one excellent part.
There's a clause in their agreement with Redmond to support the party line on this, isn't there? :-)
... So what's new about this? The older Intel NetBurst processors (which were not as efficent per clock, of course) actually hit 3.7GHz with the 'Dempsey' cpu.
The real story about the clock being turned back on is Intel's 45nm Penryn derived products due in Q4, which have very low current leakage due to high K dialectic metal design. EARLY SAMPLES of these have been shown running at 3.2GHz, so it's anybody's guess how high Intel will be able to push that architecture. (Interestingly, despite being due in late Q2, the AMD Barcelonas have rarely been shown, and even when they are, I understand at only at low clock frequencies (less than 2.5GHz)).
Rumour has it Intel will be releasing the Clovertown quad cores, now at 2.66GHz at 3.0GHz soon too...
is the comment
The real question is, we suppose, how well will AMD's Barcelona perform in comparison. We now know Penryn's potential, but AMD keeps us guessing.
Despite the fact that Barcelona is supposed to be shipping at the end of Q2 and Penryn is not due until Q4, Intel seems to be showing stable, polished systems running their 45nm product whereas AMD seems to be holding back early Barcelona silicon.
WHY IS THIS?
Flash memory used for disk caching will greatly extend battery life, as disk accesses that are cache hits will not require a powered down drive to spin up which uses much more power than many, many flash memory reads (not to mention is much, much slower than getting it from cache).
So the answer is yes, they improve battery life. How much? How disk intensive is your app?
Many medical and other specialized applications render images onto the dedicated graphics memory then grab the framebuffer contents back for other processing. I assume this will break those apps unless they get some kind of special exemption access - which would probably be crackable if you allowed it at all.
Hardware vendors have to fully think through the implications of what they do to enforce DRM.
... doesn't matter if the routers are milspec or not. Speed of light is speed of light.
... you take it out in US dollars and enjoy it in the real world. Hmmmm. So, if I travel to Country X and earn the equivlent of $3,000US in local currency - BUT spend it at a resort in in Country X, the IRS doesn't care? I think they do, so Second Life and the other alt realities are getting unique treatment, since it does appear that if you leave what happens in SL there and don't bring it home, the IRS doesn't care.
Now, Leandra Lederman at the TaxProf blog seems to take a more strict interpretation - if you spend money on things in SL that are not 'game' things (not 'fun' I guess, although many would find making money a 'fun' or 'game' thing) that those would be taxable. I don't doubt that corporations that have done press conferences and product launches in SL have already real-world expensed these (not the Linden dollars, but the media consulting companies fees - which would have rolled in any US$ costs for buying Linden dollars to rent space, etc).
BTW, I gave a lecture on SL recently (uncompensated, you tax spooks!) in which the most interesting question was about whether people could use SL to launder money. My first reaction was that from the criminal's point of view, SL being a cashless society (all SL transactions are theoretically loggable and therefore external authorities could presumably subpoena the logs from Linen Labs) however, if they chose some classic real world money laundering techniques (buy or invest in a business, take the money out in proceeds and maybe even launder it again) it might make it hard enough to follow that SL might be viable for this. It's certainly a good way to get money moved internationally - except that it comes out in US$.
Not likely. Vast majority of these will probably be deployed with the Linux stack.
... to succeed: For the same reason there is are NO standards for external power bricks for laptops/printers/scanners/hubs etc. Because there is a high margin add-on market from manufacturers to replace proprietary power devices (when lost) with expensive branded units which are probably about 5x to 10x the cost of what generic units would if there was a some common defined types (V/ma/connector-types) which would be universal. A move to efficent USB power would undercut this business in the same way, so the only standard that will be agreed upon will be an unworkable one. Firewire never replaced USB because it had licence encumberences (cost more to use), alas.
The famous Steve Gibson, author of Spinrite, writes all his software (Windows mostly) in pure ASM and the speed and efficiency of his apps speak for themselves.
There are still many important changes that, popping up at the last minute, could seriously enrage an IT department, but I doubt it's as severe a problem as with Windows. Not that anyone would ever convince a rather conservative IT department of that...
That's a very user-desktop-centric point of view and your concession that conservative IT would still want this is not only correct, but they're right and you're not. All the big corporate accts I work with insist on roadmap transpearancy from ALL vendors inlcuding big RISC/UNIX and mainframe system vendors (which have no Windows tie in) - in fact this becomes MORE important when the systems become more mission critical and complex.
Apple makes great theatre with Jobs yearly MacWorld announcements, but this is so far from the detailed, non-disclosure timelines and product direction information that corporates require that, long after Apple had ditched the secrecy for business, competing vendors will be making jokes about Apple having just moved from being a "consumer toy company". ( And I think Apple could have a very compelling end-to-end technology story for corporates)