The blurb should still have given Capek his credit.
Well, Capek apparently denied credit for the invention of the word, attributing it to his brother. Where do we stop? I think the first publication that used it in the modern sense is the right point.
The concept behind cyberspace (artificial reality) was first espoused by Plato, before the birth of Christ.
I think you may be slightly misrepresenting the ideas of Plato here, which essentially boiled down to mathematical truths being as real as the world we can see and touch. I don't think he believed in creating a new reality, i.e. an "artificial reality", just that there was another reality than our own and that we could explore it through mathematics.
My 1990 PC (486DX33, 8MB, 200MB drive) was about £2k
That was one hell of a high-end system at the time. I bought my first PC at about the same time, and it was a 286 @12MHz, which set me back £600. 45MB MFM hard drive and EGA graphics that were _ever so slightly_ nonstandard, so that moving the mouse around left incorrect colours every now and then.
It's funny how Slashdotters completely forget what "anti-competitive behavior" means when the perpetrator is not spelled M-I-C-R-O-S-O-F-T.
Can you cite some behaviour of Google that is anticompetitive? I certainly am not aware of any. Sure, their original distribution of copyright content without the rights holder's permission on the basis that an opt out was possible was a little unethical, and their continued trust of publishers who opt in to the program but who often turn out not to hold the relevant rights to do so is somewhat more problematic, but I don't think either of these constitutes anticompetitive behaviour.
So they have the power to grant Google access to orphan books whos publishers and authors haven't explicitly authorized it?
How does that work? 'we can grant google this power even though we don't have it, but we can't grant it to anyone else because we don't have it!'
That argument doesn't appear to make a whole lot of sense to me.
This is a basic consequence of class action law suits. When a class action is certified, the representatives who brought the action are assumed (legally speaking) to speak for all members of the class (in this case everyone who holds copyright or publication rights in a book) with respect to the specific court case, and in settlements relating to that case. It's a legal fiction, but a generally accepted one.
In this case, it means that the Writers Guild represents all appropriate rights holders in negotiations with google. They don't represent those rights holders in any other case, so cannot negotiate similar terms with anybody except google; they could only do so in the event that a court certified that it would be in the interests of the class as a whole for them to do so (as happened in the Google case).
If you don't like it, you need to campaign to your representatives for a change in the law regarding class actions.
1) This refers to legislation that has not yet come into force. No bank account thus far has had its contents seized under this scheme.
2) You fail to mention that the scheme includes a process for those whose money has been taken to claim the money back. All it does it take the money out of the bank: the QUANGO that receives the money then has just as much obligation to return it to you as the bank does.
Honestly, do you really think any distros today will be supported on 15 years?
Oh, I don't know, if you pick up debian unstable it'll become testing in about 3 years, stable about 4 years after that and maybe reach end of life after another 5. That only leaves you 3 years of unsupported status.
Joking aside... Seriously, it be hard to even pick a highlevel programming language and framework that won't be obscure or incompatible in 15 years...
If you'd asked me that question 15 years ago, the answer would have been: C++/MFC, or maybe Visual BASIC. I'd have been right with the former and there's a lot of resources for dealing with the latter.
Can you even be sure that x86 won't be somewhat obscure in 15 years?
Yes. Because even if we all upgrade to something better, there'll be a _lot_ of need to run legacy software. 15 years isn't that long in terms of enterprise computing. There will be a solution to running x86 apps.
The original systems probably cost $5k-$7k 10-15 years back.
Really? I bought a P100 system in 1996 that only set me back about £500 ($900ish at the exchange rates of the day). While it didn't last me 10 years, I used that system as a 24-hour-a-day server well into the 2000s. We tend to misremember when price changes happen. Sure, that kind of price was common in the 80s, but by the 90s they were fairly rare.
Systems to replace these will cost $1-2k and deliver much higher performance.
I really wouldn't recommend spending that much unless you _need_ the higher performance. Cheap components run at low speed (i.e., underclocked CPU and RAM) and redundancy (cheap RAID1 pair of 5400RPM disks) would be the best approach here. Ensure the case has plenty of cooling, and that it doesn't need it. Don't install latest version software as it's more demanding than older versions. Linux and old-style X set up with fvwm and a DOS box sounds like all this guy needs, and such a setup can be run without swap off a ramdisk so the HDD is only used when absolutely necessary. Even on a machine underclocked as low as the motherboard will go this would be a blindingly fast setup.
it's a cinch that in five years the bar will be raised to include real online functionality. Make an appointment, see when your dog is due for shots, see how much Poo-Poo weighed at his last checkup -- sounds nice, right? [...] That means he needs to plan on new software
Speaking as a developer of such software, I'll say he can do it with his current system without upgrading. I'd make a browser-based booking system that works in IE3 and he can access over dialup. He'll have to reserve some slots to web bookings due to the fact that it isn't live-integrated with his existing system, but such systems are workable for most small businesses. Occasional unbooked slots can be useful to catch up with paperwork, and responding to a sudden increase in demand is easy enough as long as he checks the system at least twice a day.
DOS software is pretty aged now. I really shudder to think about it ANOTHER 15 years from now. I don't know where the golden point is in Vet software, but it should be looked at to provide the decision context.
Legacy software isn't an issue until you need it do something it doesn't already do. But at that point, you typically need it to do it yesterday, and migration to a replacement will take months. So, it may be best to start looking for an upgrade now, preferably to something open source and/or custom, so that migration doesn't become a hassle in future (avoid vendor lock-in).
Yes, indeed. Underclocking is your friend: it reduces heat and power consumption, and extends the lifetime of most of the components on the board. Hard disk reliability will be the biggest issue after that, so a RAID1 pair with a spare in a box somewhere so you can just swap it in on demand seems the best choice.
it sounds like this could be awfully expensive in lawyer fees.
I have it on good authority that in copyright cases in the US one can usually claim back your fees from the infringer and/or false accuser of infringement. If the contributor is correct in his assertion that he has copyright and can prove it then it will probably be the stock photo company that pays those fees.
But I'm not talking about two people working on the same area
Well, that's the fundamental disconnect we have here. Yes, if you have separate areas you should assign individual programmers to those until you have them all covered (unless you consider bug-free results more important than speed of development: in safety critical areas I would suggest pairing as a basic safety technique to prevent errors). Then you should probably have teams of two people working independently, again as long as productivity is your main concern. After that, I think as soon as team size goes up to four you're better off with your members pairing rather than working individually.
Am I missing something? Given that most non-trivial companies can parallelise their workload for at least two people, I would expect two independent programmers to be 100% faster than a single programmer.
Most studies have found this not to be true. The extra overhead of communication between the programmers tends to cause an exponential decay in how much additional work is performed by each additional programmer added to the team. Given that most teams are already somewhere approaching the sweet spot on that curve, adding a new programmer doesn't usually result in that programmer achieving more than 50% of what a single programmer achieves. In large teams, it is often found that adding an extra programmer results in no increase in the amount of work performed (see Brooks, The Mythical Man Month). However, adding a new programmer as a pair to an existing programmer doesn't suffer the same problem. The idea enables teams that are twice as large, achieving around 50% more work, before paralysis sets in.
And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.
That's one study. I imagine the one you're talking about is "All I really need to know about pair programming I learned in kindergarten" by Williams and Kessler. This study has been criticised for its focus on performance over and above accuracy. I'd suggest you look at some of the broader studies that have been published since that one, e.g. Williams, L. Kessler, R.R. Cunningham, W. Jeffries, R. "Strenghtening the case for pair programming" (IEEE Software), finding that a 50% speedup over a single programmer, which is in the same order as two programmers working independently, but more importantly a 13-17% reduction in the number of bugs discovered after signoff, whereas you would usually expect an increase with two programmers working independently. Nosek 1998 (also a Communications paper) found a 41% speedup, which is less than you would expect from two programmers individually, but also found a 43% increase in evaluations of code readability and a 33% increase in evaluations of resulting functionality of the software developed.
So, yeah, basically the point is that while two people at separate keyboards may produce a larger volume of code, the code produced during pairing is more likely to solve the problem that it was actually required for, and will be more maintainable afterwards. And we haven't even touched on the fact that pair programming spreads knowledge of the design of the codebase the team is working on, thus helping the team maintain the software at a later date, or that most programmers find they can keep up pairing for longer periods of time than they can code by themselves, or that job satisfaction is generally higher for programmers who pair.
And your description of how you think when you code betrays that you have dismissed this without trying it. You think differently when you're pairing. It's just as effective (if not more so), and the interruption is not a problem.
1. He says that everybody needs to learn communicate. That's trivial.
Trivial or not, there are many so-called "professional" programmers out there who don't seem to understand it. They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone". Well, frankly, you need to be able to communicate those details, so you _should_ be able to talk to somebody about the coding while you're doing it. The focus is on the implementation, not the communication. It should be the other way around.
3. He says that the U.S. economy in the future won't need any people with technical skills, only managers, as technical skills can be outsourced. This is bullshit, as the U.S. is going to experience the hard way in the upcoming years.
Did you read the same article as me? I seriously don't see where it says this. What it says it that lead-from-the-top teams where jobs are parcelled out by an architect with a vision and are implemented by junior programmers will go the way of dinosaurs; it says that everyone is going to need to understand the whole product they're implementing it, the business reason why it's necessary, and to interact with the eventual users of the system to ensure that what they're implementing is the right thing.
This isn't news to some of us, but there are still a lot of people out there who don't seem to understand this.
I wouldn't say agile development as a field is stale; it has been gradually attracting interest over the last 10 years, and is more popular now than ever. Yes, this kind of thinking might help it along. But it doesn't really _need_ that help.
This isn't really x86, in my opinion; it's x86 with a separate set of very obviously graphics-oriented instructions bolted on top. Since getting decent performance will require using the new instructions and a new programming model almost exclusively, what's the point of the x86 bit?
The point is that there's stuff those graphics-oriented instructions are really not very good at, like indirect memory referencing and branching logic, both of which x86 excels at handling. Now, that kind of workload isn't common on GPUs _at the moment_, but both of those are common operations, for example, in ray tracing, so you may see them become more important over the next few years. What Intel are doing here is defining the GPU architecture for the next decade, and it's one that allows more complex algorithms to be implemented than can easily be done using the specialized stream processing systems we have at the moment.
The other point behind the x86 bit is that not only did Intel alrady have core designs that implemented it (Larrabee simply has the new registers & instructions bolted on to an existing low-power Pentium-class core) thus enabling faster time to market than if they'd developed entirely new hardware, they also have a massive amount of software support for the architecture, including one of the best optimizing C++ compilers there is. A new ISA would have required a new compiler, thus further complicating the project. As it is, only extensions to their existing compiler have been necessary.
Seriously, most of the Mesa shader assemblers deal with very limited, simple, straightforward shader ISAs. This is icky. We're gonna need a full-on compiler for this
If you don't need the extra complexity of an x86 core, you can ignore it. Compilers for this system will be just as simple as compilers for current nvidia/ati designs.
If developers are too stupid to code for it, it won't go anywhere. This is sounding a lot like the PS3 architecture in complexity.
There are several problems with PS3 programming that don't apply to Larrabee:
* Non-uniform core architectures. Cell processors have two different instruction architectures depending on which core your code is intended to run on. This causes quite a bit of confusion and makes the tools for development a lot more complex. * Non-uniform memory access. Most cell processor cores have local memory, and global memory accesses must be transferred to/from this local memory via DMA. Larrabee cores have direct access to main memory via a shared L2 cache. * Memory size constrains. Most cell processor cores only have direct access to 256K of memory, so programs running on them have to be very tightly coded and don't have much spare space for scratch usage.
Any application that's reasonably parallelisable is going to be pretty easy to optimize for larrabee. Most graphics algorithms fit into this category.
Articles states that there's hardware support for transcendental functions, but the list of instructions doesn't include any. Anyone know what is/isn't supported in this line?
Wonderful ! Now, instead of having some standard battery sizes (AA, AAA and so on), we are going tu have as many different shapes of batteries as there are products
I have non-standard batteries in my cell phone, my laptop, my electric bike, my portable media player, my bluetooth headset and my digital camera. I have standard size batteries in... err... actually, I can't remember anything I own that uses standard batteries. Oh, the digital scales in my kitchen, which take 2xCR2032s.
Standard sized batteries are already on their way out. Manufacturer-specific rechargeables are the new standards.
Seriously, this is a useless battery. It's based on the Li-FePO4 chemistry, the same as the fast charging one the parent mentions, but it (1) doesn't have the fast charging capability and (2) is only suitable for 100 recharge cycles. Li-FePO4 is a lower power-density variant of lithium ion that is used primarily because it can usually last for about 3000 recharge cycles rather than the 1000 that's typical for traditional lithium ion cells. So the only advantage of this tech: it might be cheap to make. But probably not cheap to market, considering MIT will want quite a bit for the patent licenses.
I doubt we'll ever see these marketed successfully.
Slashdot Mirror
The blurb should still have given Capek his credit.
Well, Capek apparently denied credit for the invention of the word, attributing it to his brother. Where do we stop? I think the first publication that used it in the modern sense is the right point.
The concept behind cyberspace (artificial reality) was first espoused by Plato, before the birth of Christ.
I think you may be slightly misrepresenting the ideas of Plato here, which essentially boiled down to mathematical truths being as real as the world we can see and touch. I don't think he believed in creating a new reality, i.e. an "artificial reality", just that there was another reality than our own and that we could explore it through mathematics.
My 1990 PC (486DX33, 8MB, 200MB drive) was about £2k
That was one hell of a high-end system at the time. I bought my first PC at about the same time, and it was a 286 @12MHz, which set me back £600. 45MB MFM hard drive and EGA graphics that were _ever so slightly_ nonstandard, so that moving the mouse around left incorrect colours every now and then.
It's funny how Slashdotters completely forget what "anti-competitive behavior" means when the perpetrator is not spelled M-I-C-R-O-S-O-F-T.
Can you cite some behaviour of Google that is anticompetitive? I certainly am not aware of any. Sure, their original distribution of copyright content without the rights holder's permission on the basis that an opt out was possible was a little unethical, and their continued trust of publishers who opt in to the program but who often turn out not to hold the relevant rights to do so is somewhat more problematic, but I don't think either of these constitutes anticompetitive behaviour.
So they have the power to grant Google access to orphan books whos publishers and authors haven't explicitly authorized it?
How does that work? 'we can grant google this power even though we don't have it, but we can't grant it to anyone else because we don't have it!'
That argument doesn't appear to make a whole lot of sense to me.
This is a basic consequence of class action law suits. When a class action is certified, the representatives who brought the action are assumed (legally speaking) to speak for all members of the class (in this case everyone who holds copyright or publication rights in a book) with respect to the specific court case, and in settlements relating to that case. It's a legal fiction, but a generally accepted one.
In this case, it means that the Writers Guild represents all appropriate rights holders in negotiations with google. They don't represent those rights holders in any other case, so cannot negotiate similar terms with anybody except google; they could only do so in the event that a court certified that it would be in the interests of the class as a whole for them to do so (as happened in the Google case).
If you don't like it, you need to campaign to your representatives for a change in the law regarding class actions.
1) This refers to legislation that has not yet come into force. No bank account thus far has had its contents seized under this scheme.
2) You fail to mention that the scheme includes a process for those whose money has been taken to claim the money back. All it does it take the money out of the bank: the QUANGO that receives the money then has just as much obligation to return it to you as the bank does.
Honestly, do you really think any distros today will be supported on 15 years?
Oh, I don't know, if you pick up debian unstable it'll become testing in about 3 years, stable about 4 years after that and maybe reach end of life after another 5. That only leaves you 3 years of unsupported status.
Joking aside...
Seriously, it be hard to even pick a highlevel programming language and framework that won't be obscure or incompatible in 15 years...
If you'd asked me that question 15 years ago, the answer would have been: C++/MFC, or maybe Visual BASIC. I'd have been right with the former and there's a lot of resources for dealing with the latter.
Can you even be sure that x86 won't be somewhat obscure in 15 years?
Yes. Because even if we all upgrade to something better, there'll be a _lot_ of need to run legacy software. 15 years isn't that long in terms of enterprise computing. There will be a solution to running x86 apps.
The original systems probably cost $5k-$7k 10-15 years back.
Really? I bought a P100 system in 1996 that only set me back about £500 ($900ish at the exchange rates of the day). While it didn't last me 10 years, I used that system as a 24-hour-a-day server well into the 2000s. We tend to misremember when price changes happen. Sure, that kind of price was common in the 80s, but by the 90s they were fairly rare.
Systems to replace these will cost $1-2k and deliver much higher performance.
I really wouldn't recommend spending that much unless you _need_ the higher performance. Cheap components run at low speed (i.e., underclocked CPU and RAM) and redundancy (cheap RAID1 pair of 5400RPM disks) would be the best approach here. Ensure the case has plenty of cooling, and that it doesn't need it. Don't install latest version software as it's more demanding than older versions. Linux and old-style X set up with fvwm and a DOS box sounds like all this guy needs, and such a setup can be run without swap off a ramdisk so the HDD is only used when absolutely necessary. Even on a machine underclocked as low as the motherboard will go this would be a blindingly fast setup.
it's a cinch that in five years the bar will be raised to include real online functionality. Make an appointment, see when your dog is due for shots, see how much Poo-Poo weighed at his last checkup -- sounds nice, right? [...] That means he needs to plan on new software
Speaking as a developer of such software, I'll say he can do it with his current system without upgrading. I'd make a browser-based booking system that works in IE3 and he can access over dialup. He'll have to reserve some slots to web bookings due to the fact that it isn't live-integrated with his existing system, but such systems are workable for most small businesses. Occasional unbooked slots can be useful to catch up with paperwork, and responding to a sudden increase in demand is easy enough as long as he checks the system at least twice a day.
DOS software is pretty aged now. I really shudder to think about it ANOTHER 15 years from now. I don't know where the golden point is in Vet software, but it should be looked at to provide the decision context.
Legacy software isn't an issue until you need it do something it doesn't already do. But at that point, you typically need it to do it yesterday, and migration to a replacement will take months. So, it may be best to start looking for an upgrade now, preferably to something open source and/or custom, so that migration doesn't become a hassle in future (avoid vendor lock-in).
So a cool motherboard and system is required.
Yes, indeed. Underclocking is your friend: it reduces heat and power consumption, and extends the lifetime of most of the components on the board. Hard disk reliability will be the biggest issue after that, so a RAID1 pair with a spare in a box somewhere so you can just swap it in on demand seems the best choice.
it sounds like this could be awfully expensive in lawyer fees.
I have it on good authority that in copyright cases in the US one can usually claim back your fees from the infringer and/or false accuser of infringement. If the contributor is correct in his assertion that he has copyright and can prove it then it will probably be the stock photo company that pays those fees.
Interesting?! WTF?!?one?!slash
But I'm not talking about two people working on the same area
Well, that's the fundamental disconnect we have here. Yes, if you have separate areas you should assign individual programmers to those until you have them all covered (unless you consider bug-free results more important than speed of development: in safety critical areas I would suggest pairing as a basic safety technique to prevent errors). Then you should probably have teams of two people working independently, again as long as productivity is your main concern. After that, I think as soon as team size goes up to four you're better off with your members pairing rather than working individually.
Am I missing something? Given that most non-trivial companies can parallelise their workload for at least two people, I would expect two independent programmers to be 100% faster than a single programmer.
Most studies have found this not to be true. The extra overhead of communication between the programmers tends to cause an exponential decay in how much additional work is performed by each additional programmer added to the team. Given that most teams are already somewhere approaching the sweet spot on that curve, adding a new programmer doesn't usually result in that programmer achieving more than 50% of what a single programmer achieves. In large teams, it is often found that adding an extra programmer results in no increase in the amount of work performed (see Brooks, The Mythical Man Month). However, adding a new programmer as a pair to an existing programmer doesn't suffer the same problem. The idea enables teams that are twice as large, achieving around 50% more work, before paralysis sets in.
And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.
That's one study. I imagine the one you're talking about is "All I really need to know about pair programming I learned in kindergarten" by Williams and Kessler. This study has been criticised for its focus on performance over and above accuracy. I'd suggest you look at some of the broader studies that have been published since that one, e.g. Williams, L. Kessler, R.R. Cunningham, W. Jeffries, R. "Strenghtening the case for pair programming" (IEEE Software), finding that a 50% speedup over a single programmer, which is in the same order as two programmers working independently, but more importantly a 13-17% reduction in the number of bugs discovered after signoff, whereas you would usually expect an increase with two programmers working independently. Nosek 1998 (also a Communications paper) found a 41% speedup, which is less than you would expect from two programmers individually, but also found a 43% increase in evaluations of code readability and a 33% increase in evaluations of resulting functionality of the software developed.
So, yeah, basically the point is that while two people at separate keyboards may produce a larger volume of code, the code produced during pairing is more likely to solve the problem that it was actually required for, and will be more maintainable afterwards. And we haven't even touched on the fact that pair programming spreads knowledge of the design of the codebase the team is working on, thus helping the team maintain the software at a later date, or that most programmers find they can keep up pairing for longer periods of time than they can code by themselves, or that job satisfaction is generally higher for programmers who pair.
And your description of how you think when you code betrays that you have dismissed this without trying it. You think differently when you're pairing. It's just as effective (if not more so), and the interruption is not a problem.
1. He says that everybody needs to learn communicate. That's trivial.
Trivial or not, there are many so-called "professional" programmers out there who don't seem to understand it. They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone". Well, frankly, you need to be able to communicate those details, so you _should_ be able to talk to somebody about the coding while you're doing it. The focus is on the implementation, not the communication. It should be the other way around.
3. He says that the U.S. economy in the future won't need any people with technical skills, only managers, as technical skills can be outsourced. This is bullshit, as the U.S. is going to experience the hard way in the upcoming years.
Did you read the same article as me? I seriously don't see where it says this. What it says it that lead-from-the-top teams where jobs are parcelled out by an architect with a vision and are implemented by junior programmers will go the way of dinosaurs; it says that everyone is going to need to understand the whole product they're implementing it, the business reason why it's necessary, and to interact with the eventual users of the system to ensure that what they're implementing is the right thing.
This isn't news to some of us, but there are still a lot of people out there who don't seem to understand this.
I wouldn't say agile development as a field is stale; it has been gradually attracting interest over the last 10 years, and is more popular now than ever. Yes, this kind of thinking might help it along. But it doesn't really _need_ that help.
This isn't really x86, in my opinion; it's x86 with a separate set of very obviously graphics-oriented instructions bolted on top. Since getting decent performance will require using the new instructions and a new programming model almost exclusively, what's the point of the x86 bit?
The point is that there's stuff those graphics-oriented instructions are really not very good at, like indirect memory referencing and branching logic, both of which x86 excels at handling. Now, that kind of workload isn't common on GPUs _at the moment_, but both of those are common operations, for example, in ray tracing, so you may see them become more important over the next few years. What Intel are doing here is defining the GPU architecture for the next decade, and it's one that allows more complex algorithms to be implemented than can easily be done using the specialized stream processing systems we have at the moment.
The other point behind the x86 bit is that not only did Intel alrady have core designs that implemented it (Larrabee simply has the new registers & instructions bolted on to an existing low-power Pentium-class core) thus enabling faster time to market than if they'd developed entirely new hardware, they also have a massive amount of software support for the architecture, including one of the best optimizing C++ compilers there is. A new ISA would have required a new compiler, thus further complicating the project. As it is, only extensions to their existing compiler have been necessary.
Seriously, most of the Mesa shader assemblers deal with very limited, simple, straightforward shader ISAs. This is icky. We're gonna need a full-on compiler for this
If you don't need the extra complexity of an x86 core, you can ignore it. Compilers for this system will be just as simple as compilers for current nvidia/ati designs.
Servers are I/O heavy - CPU parallelism is very secondary
I take it you've never tried to run a large-scale J2EE app.
If developers are too stupid to code for it, it won't go anywhere. This is sounding a lot like the PS3 architecture in complexity.
There are several problems with PS3 programming that don't apply to Larrabee:
* Non-uniform core architectures. Cell processors have two different instruction architectures depending on which core your code is intended to run on. This causes quite a bit of confusion and makes the tools for development a lot more complex.
* Non-uniform memory access. Most cell processor cores have local memory, and global memory accesses must be transferred to/from this local memory via DMA. Larrabee cores have direct access to main memory via a shared L2 cache.
* Memory size constrains. Most cell processor cores only have direct access to 256K of memory, so programs running on them have to be very tightly coded and don't have much spare space for scratch usage.
Any application that's reasonably parallelisable is going to be pretty easy to optimize for larrabee. Most graphics algorithms fit into this category.
Articles states that there's hardware support for transcendental functions, but the list of instructions doesn't include any. Anyone know what is/isn't supported in this line?
Wonderful ! Now, instead of having some standard battery sizes (AA, AAA and so on), we are going tu have as many different shapes of batteries as there are products
I have non-standard batteries in my cell phone, my laptop, my electric bike, my portable media player, my bluetooth headset and my digital camera. I have standard size batteries in... err... actually, I can't remember anything I own that uses standard batteries. Oh, the digital scales in my kitchen, which take 2xCR2032s.
Standard sized batteries are already on their way out. Manufacturer-specific rechargeables are the new standards.
Seriously, this is a useless battery. It's based on the Li-FePO4 chemistry, the same as the fast charging one the parent mentions, but it (1) doesn't have the fast charging capability and (2) is only suitable for 100 recharge cycles. Li-FePO4 is a lower power-density variant of lithium ion that is used primarily because it can usually last for about 3000 recharge cycles rather than the 1000 that's typical for traditional lithium ion cells. So the only advantage of this tech: it might be cheap to make. But probably not cheap to market, considering MIT will want quite a bit for the patent licenses.
I doubt we'll ever see these marketed successfully.