Actually Fortress has probably more mechanisms to support high-performance, programmer-controllable parallel computation than any other current language. Unfortunately they haven't published any good papers about the details yet, but slides 21 and thereafter of this Guy Steele lecture http://research.sun.com/projects/plrg/GSPx-Lecture 2006public.pdf make it very clear that Fortress does at least the following:
- Provide an abstract definition of data structures. - Define reductions and computations over those data structures in an abstract manner. - Allow specification of concrete mappings to particular processor and network topologies, such that those computations can be efficiently scaled to the local system.
In some ways it reminds me of Google's MapReduce system, but applied at the language level, in a way that allows library authors to create their own data structures and computational mappings in a fully extensible way. Super cool stuff, not only groundbreaking in the computer language world, but also potentially revolutionary in the scientific computing world.
And so what if their interpreter is written in Java? That's like writing off Java because the very first Java engines were bytecode interpreters! You walk before you run, and you interpret before you compile, when building up a new language from absolute scratch.
Also, they put a lot of emphasis on interoperability with Java, so there should be no problem using existing Java codebases to build UIs, etc. for Fortress apps.
Here's the actual summary from the Steele presentation:
- Regions describe machine resources. - Distributions map aggregates onto regions. - Aggregates used as generators drive parallelism. - Algebraic properties drive implementation strategies. - Algebraic properties are described by traits. - Properties are verified by automated unit testing. - Traits allow sharing of code, properties, and test data. - Reducers and generators negotiate through overloaded method dispatch keyed by traits to achieve mix-and-match parallel code selection.
And as far as downtime reduction goes, NRAM would be no good unless the server has time to suspend-to-RAM...
Well, unless the server was written using memory transactions, which are starting to look like a good idea for other reasons also. If you had a transactional layer on top of your NVRAM, then you could structure things to allow crash recovery as well; then you could recover from any crash at any time.
Humans degrade very quickly if not in a 1.0G environment. As far as we know, even if you can get around the bone loss, immune system degradation, and other big troubles with living long-term in microgravity, you will NEVER be able to have viable offspring in a non-1.0G environment.
To my mind this is the real long-term showstopper to human space travel: our biology isn't compatible with living outside a gravity well.
Probably there would have to be large investment in constructing permanently rotating space stations and even planetary installations to simulate gravity, and the issues with keeping a planetary installation permanently rotating are really a big problem.
Seems to me that humans as we know them may be pretty much permanently and severely handicapped in space. And to me, that says that really large-scale human colonization of space is going to have to wait until after really advanced nanotech has reengineered humans to be more survivable in space.
Dude, I'm 34, and I can relate. We are having a hell of a time right now finding young sharp kids who stay on top of the state of the art and who want to write good stuff in the right way. (Are you in the San Francisco area? Want a better job?)
We are using agile (not XP -- lightweight but with hopefully just the right amount of planning) techniques here at work, and we are staying current with technology. Hibernate, Junit, continuous integration, green builds, Checkstyle, story-based planning. But also actual story plan documents, installation documentation, enforced javadoc, careful attention to architectural ratholes (frequent spikes and lots of mentoring of the developers).
You say you don't want to be a team lead, but the God's honest truth is that you do, eventually. People who think about and care about process make the best team leads, because they are the ones who best optimize the whole team's productivity. You can still get a lot of work done if you are the team lead -- the only difference is that you get to set the standards and help everyone else come up to that level, rather than just being a voice in the wilderness. I know, because that's exactly the spot I'm in now -- a team lead who's looked up to, rather than looked down on.
The other thing to be careful of in your frenzy of abstraction is YAGNI. Are you really going to need all this documentation? Who is it for? Be extra careful that your definition of The Right Way isn't just The Most Fun Way For You. Ultimately you are just as accountable for getting the job done as the other grunt coders at your job. The only way your upfront work will pay off is if you can leverage it a few weeks from now to write 10 screens in the time it takes them to write 2, and if you can sustain that productivity increase. If you can't, then is it really worth it? (And your whole create-the-whole-object-structure-with-XML... cool, sure, but do you REALLY need it???)
Don't overwork yourself so much that it magnifies your resentment. And don't lose hope -- yes, there ARE people over 20 who care about good clean code that does the job in the right way! Cheers! Rob
This SciAm article describes three categories of ferromagnetic materials. The first two are ferromagnetic alloys (which are what make up MRAMs and other current ferromagnetic tech), and ferromagnetic semiconductors.
This team has discovered the first room-temperature (or higher) ferromagnetic semiconducting material, hence opening the way for spin switching and computing.
We implemented an interactive drag-and-drop drawing tool using the Adobe SVG plugin. It's frankly amazing to drag things around as though you were in Visio (connection points and all), yet to be doing it just by updating the DOM of the drawing itself. Developing with SVG is incredibly fast.
SVG is enormously more useful than many realize. It's also one of those technologies that's not going away... it'll take a while for everyone to learn just how good it is, but once they do, watch out!
Your paper "Defending against an Internet-Based Attack on the Physical World" describes a number of coutnermeasures, almost all of which are focused on the Internet level of the attack.
Since most of the actual bad consequences of the attack come due to the "mail implosion" at the target address, it seems to me that there are other defensive possibilities based on detecting and averting the mail implosion before it happens.
The only entity in a position to do this is the post office itself. But the post office is already in the business of knowing the destination address of every piece of mail in its system. If the post office were able to mine the addressing data in its system to such an extent as to be able to detect sudden service-threatening implosions targeted at a particular address, the post office itself would be able to flag such mail as "nondeliverable due to system abuse" (perhaps with a notification to the target address that their mail was too voluminous to be delivered).
This would of course require exceptional investment in real-time tracking systems by the post office, although since all that is really required is a count of "number of mailings addressed to target" (and not an actual index of what the mailings themselves *are*), it is possible to avoid the overheads of constructing a full per-package tracking system.
This defense, it seems to me, would be performed by the actual victim of the attack -- the post office itself. Moreover, it is hard to see what countermeasures an attacker could employ to circumvent the post office's own monitoring of its traffic.
(I would imagine similar techniques at the email level are likely already used by ISPs to protect users against email implosion attacks...?)
What would you consider the strengths and weaknesses of this defense?
Thank you for a thought-provoking paper. Sincerely, Rob Jellinghaus rob@helium.com http://www.helium.com
If you'd read the paper (yeah, how often do people do THAT around here?), you'd know that the gun works by ejecting a cloud of superheated, pressurized gas from a storage container at the base of the weapon forwards into a lasing cavity. Every shot involves a high-pressure gas release. It's the internal gas release that causes the recoil.
Actually, the NV30 very likely *can* do raytracing in hardware. I don't know if it can come close to realtime, but here is the paper describing how raytracing can be done on NV30-level programmable graphics hardware.
It's gonna be a fun couple of years coming up here:-)
How quickly we forget. Snow Crash had LOTS of plot elements that were all about millimeter-wave radar. It's how the robo-dog saw the world, for heaven's sake!
"never heard of this before" -- sheesh... kids these days:-)
The post says: "[It is hard] to believe that 500 million billion tonnes of ice sheet has disintegrated in less than a month."
That would be hard to believe, indeed, especially since the actual article at antarctica.ac.uk says: "Hard to believe that 500 billion tonnes of ice sheet has disintegrated in less than a month."
But a factor of a million here, a factor of a million there, who cares, right? This is Slashdot! We don't need no stinkin' proofreading!
Kohan (www.kohan.net, available for Linux!) has supply zones, morale, formations, and quite a few other more-strategic concepts. It's by far my favorite RTS, as it's *not* a clickfest.
Anyone who's interested in this thread should definitely at least try the Kohan demo... it's right up your alley:-)
I hope quite a few people here read Lee Smolin's comment in the feedback to Lanier's article, in which Smolin describes different scales of problem solving (CLASS 1, simple optimization, through CLASS 5, creating entirely new fitness landscapes and simultaneously functioning within them). Lanier's article didn't say much new to me, but Smolin's analysis of what we are up against if we hope to really speed evolution is very persuasive and enlightening.
I think Lanier's whole discussion of subjective experience is a red herring. Personally, I do think I have subjective experience, but I don't see why a computer -- or some other evolved-partly-by-us creation -- couldn't also have subjective experience. Arguing the point seems to be a fundamental distraction from the deeper issue: what kind of impact ever-evolving technology will have on human society, and whether we will (eventually) create beings comparable or superior to ourselves.
I tend to agree with Lanier that one of the worst risks we face is increasing social inequity. Think about some of the nightmare totalistic scenarios -- that we will create a race of super-beings that will look down on us and use us as fodder. Now, put on a very cynical hat, and think about the world we live in now, where the "first world" consumes most resources; where the richest 1% of the population has over 30% of the wealth; where entire social classes are disenfranchised and economically shut out. Seems to me we already live in the technological dystopia people like Joy and Lanier are afraid of! (I think Lanier acknowledges this, on some level.)
I am still an associate of the Foresight Institute, because it is a good resource for tracking developments in advanced technology. But I haven't been to one of their functions in some time, largely because the prevailing meme pool there doesn't contain enough skepticism for my taste. (Cryonics in particular seems to me to be substituting overwhelming technological optimism for a real confrontation with issues of life and death.)
Putting the optimist hat on, I would hope that newer, smaller, greener technology will eventually reduce humanity's ecological impact on the planet, and that as we do start to evolve creations (creatures) that have greater independence and autonomy, that it helps us widen the "circle of empathy" Lanier mentions. You could take an almost Buddhistic view -- that compassion is the essence of the universe -- and realize that it's our moral responsibility, as creative and intelligent beings, to evolve creatures that are themselves compassionate. Whether we can do this when we are so often lacking in compassion ourselves is another question... in fact (finishing off by wearing the theist hat), that may be the question that God created us to answer.
You are dead wrong about the pros and cons of a built-in hard disk. Having an external hard disk means that developers lose one of the biggest benefits of a console: knowing exactly what hardware all their customers have. If the hard disk is an add-on, then most people won't have it, and you can't build your game on the assumption that it's there. Presto, it might as well not exist at all.
There is plenty of console precedent for failed add-ons... Microsoft is very smart to avoid making the same mistake.
I'm surprised no one in this thread has mentioned Raimi's film A Simple Plan yet... definitely one of the most gripping, tragic, and powerful movies I've seen in the last few years. If you haven't seen it, see it. It's like Fargo except much bleaker. I think Raimi could do a creditable job directing just about anything, and I'd love to see him helming a Spidey flick!
No, I'm sorry, they are making a new CPU. You're completely missing the point of the patent.
Current CPUs do all the instruction decomposing into primitive operations, rescheduling, and speculative execution in hardware for every instruction that goes through the execution pipes. The whole point of this patent is that that's all wasted, redundant, excess work. You can save lots and lots of transistors, and gain lots and lots of speed, by simply not doing any of that work more than once. That's what their software/hardware combo lets them do.
It would be pointless to run it on any current chips, since all current chips are literally hardwired to do all the extra work that they're figuring out how to avoid.
OK, screwed up my last comment a bit... but everyone in this thread seems to have missed the clear mention of price and performance!
As a comparison, one embodiment of the present invention designed to run all available X86 applications is implemented by a morph host including approximately one-quarter of the number of gates of the Pentium Pro microprocessor yet runs X86 applications substantially faster than does the Pentium Pro microprocessor or any other known microprocessor capable of processing these applications.
Imagine that... they really could be talking about a huge price/performance leap. I would be worried if I were Intel or AMD... or Motorola... or IBM... or anyone making chips with lots of on-die instruction wrangling logic.
As a comparison, one embodiment of the present invention designed to run all available X86 applications is implemented by a morph host including approximately one-quarter of the number of gates of the Pentium Pro microprocessor yet runs X86 applications substantially faster than does the Pentium Pro microprocessor or any other known microprocessor capable of processing these applications.
Jeez, that seems pretty impressive, if true. Imagine an Athlon-equivalent ("faster than any other known microprocessor") for one-quarter the price....
Yeah, but Moller isn't working with NASA. That alone gives this guy more credibility than Moller, to my mind. Moller's stuff is way more ambitious, but that's an engineering negative in my book--I would bet a simpler personal air buggy will start working long before a more complex one. I think this guy beats Moller cold.
Um, I think the analogy's pretty straightforward: at the nanoscale, we are just inventing the wheel. Unfortunately it is only the alpha version of the wheel and it doesn't spin properly yet. Still a few bugs in the system.
Some other nanoscale folks are working on gears, rods, bearings, etc.
Once we get the wheel worked out, then we can start on the problems of mass production... since right now we're still piecing these parts together one by one.
Difference engine? At least three technology generations away. Colossus? Four. C64? Five. P3? Six. Of course, a nanoscale difference engine is probably about as fast as an IC-scale P3, and a nanoscale P3 probably uses quantum electronics and is *way* faster than an IC-scale P3.
Now, how long is a "technology generation"? Aye, there's the rub:-) Given what I've seen over the last decade, I would estimate about five years....
HotSpot hasn't *really* arrived--there's no code!
on
HotSpot arrives
·
· Score: 1
(Note: Sun will be offering developers server-side binaries for free download from this website later this week. Check back here for download information.)
In other words, the code's not done yet! I actually do believe it probably will be done Real (Real, Real) Soon Now, but still, it's humorous:-)
...for the last six months of my current project: ~16.3K lines of Java. That's on a contract job, involving a lot of requirements thrashing (ergo, a fair amount of code thrown away). But the thing's about to go to code freeze, with adequate quality (i.e. no showstoppers and good usability).
So I guess I'm running about double the productivity of the average worldwide programmer. Only problem is, if I worked over my code I could probably get rid of a few hundred lines here and there, making it cleaner & more stable in the process... would that make me negatively productive?!?! yeah right....
Yale lets you code in Scheme in freshman CS class. Great fun too! Learning about infinite streams after only two months of undergrad CS was a definite mind-opener. aahhh, the memories. It was also fun being among the few in the class who could debug the code:-)
I agree totally. I've been using Kinesis keyboards since 1995, when I had some moderate tendinitis. A better chair with back support and good posture, a keyboard tray to put the keyboard in my lap instead of way out in front of me, a bunch of books under my monitor so it rose up to eye level, and a Kinesis keyboard collectively saved my wrists and arms from chronic pain.
I can actually type faster with the Kinesis now than I could with other keyboards, since the Kinesis has its keys arranged in vertical rows, unlike almost all other keyboards (including the crappy Microsoft Natural) which have the keys in staggered rows; staggered rows force your fingers to seek horizontally and vertically to hit upper/lower row keys, whereas on the Kinesis my fingers just have to move vertically. Much easier on the hands, and quicker to type. And it even works well for FPS games--the left hand keyboard well is very nicely contoured for speedy keypresses, and having all those keys under the thumb is also mighty fast!
www.kinesis-ergo.com -- check it out. I've turned on about six or seven coworkers to the joys of Kinesis since I got my first one, and I want this company to stay in business (not that I think they're doing badly) for my entire career:-)
Slashdot Mirror
Actually Fortress has probably more mechanisms to support high-performance, programmer-controllable parallel computation than any other current language. Unfortunately they haven't published any good papers about the details yet, but slides 21 and thereafter of this Guy Steele lecture http://research.sun.com/projects/plrg/GSPx-Lecture 2006public.pdf make it very clear that Fortress does at least the following:
- Provide an abstract definition of data structures.
- Define reductions and computations over those data structures in an abstract manner.
- Allow specification of concrete mappings to particular processor and network topologies, such that those computations can be efficiently scaled to the local system.
In some ways it reminds me of Google's MapReduce system, but applied at the language level, in a way that allows library authors to create their own data structures and computational mappings in a fully extensible way. Super cool stuff, not only groundbreaking in the computer language world, but also potentially revolutionary in the scientific computing world.
And so what if their interpreter is written in Java? That's like writing off Java because the very first Java engines were bytecode interpreters! You walk before you run, and you interpret before you compile, when building up a new language from absolute scratch.
Also, they put a lot of emphasis on interoperability with Java, so there should be no problem using existing Java codebases to build UIs, etc. for Fortress apps.
Here's the actual summary from the Steele presentation:
- Regions describe machine resources.
- Distributions map aggregates onto regions.
- Aggregates used as generators drive parallelism.
- Algebraic properties drive implementation strategies.
- Algebraic properties are described by traits.
- Properties are verified by automated unit testing.
- Traits allow sharing of code, properties, and test data.
- Reducers and generators negotiate through overloaded method dispatch keyed by traits to achieve mix-and-match parallel code selection.
Well, unless the server was written using memory transactions, which are starting to look like a good idea for other reasons also. If you had a transactional layer on top of your NVRAM, then you could structure things to allow crash recovery as well; then you could recover from any crash at any time.
Humans degrade very quickly if not in a 1.0G environment. As far as we know, even if you can get around the bone loss, immune system degradation, and other big troubles with living long-term in microgravity, you will NEVER be able to have viable offspring in a non-1.0G environment.
To my mind this is the real long-term showstopper to human space travel: our biology isn't compatible with living outside a gravity well.
Probably there would have to be large investment in constructing permanently rotating space stations and even planetary installations to simulate gravity, and the issues with keeping a planetary installation permanently rotating are really a big problem.
Seems to me that humans as we know them may be pretty much permanently and severely handicapped in space. And to me, that says that really large-scale human colonization of space is going to have to wait until after really advanced nanotech has reengineered humans to be more survivable in space.
Dude, I'm 34, and I can relate. We are having a hell of a time right now finding young sharp kids who stay on top of the state of the art and who want to write good stuff in the right way. (Are you in the San Francisco area? Want a better job?)
We are using agile (not XP -- lightweight but with hopefully just the right amount of planning) techniques here at work, and we are staying current with technology. Hibernate, Junit, continuous integration, green builds, Checkstyle, story-based planning. But also actual story plan documents, installation documentation, enforced javadoc, careful attention to architectural ratholes (frequent spikes and lots of mentoring of the developers).
You say you don't want to be a team lead, but the God's honest truth is that you do, eventually. People who think about and care about process make the best team leads, because they are the ones who best optimize the whole team's productivity. You can still get a lot of work done if you are the team lead -- the only difference is that you get to set the standards and help everyone else come up to that level, rather than just being a voice in the wilderness. I know, because that's exactly the spot I'm in now -- a team lead who's looked up to, rather than looked down on.
The other thing to be careful of in your frenzy of abstraction is YAGNI. Are you really going to need all this documentation? Who is it for? Be extra careful that your definition of The Right Way isn't just The Most Fun Way For You. Ultimately you are just as accountable for getting the job done as the other grunt coders at your job. The only way your upfront work will pay off is if you can leverage it a few weeks from now to write 10 screens in the time it takes them to write 2, and if you can sustain that productivity increase. If you can't, then is it really worth it? (And your whole create-the-whole-object-structure-with-XML... cool, sure, but do you REALLY need it???)
Don't overwork yourself so much that it magnifies your resentment. And don't lose hope -- yes, there ARE people over 20 who care about good clean code that does the job in the right way!
Cheers!
Rob
This SciAm article describes three categories of ferromagnetic materials. The first two are ferromagnetic alloys (which are what make up MRAMs and other current ferromagnetic tech), and ferromagnetic semiconductors. This team has discovered the first room-temperature (or higher) ferromagnetic semiconducting material, hence opening the way for spin switching and computing.
We implemented an interactive drag-and-drop drawing tool using the Adobe SVG plugin. It's frankly amazing to drag things around as though you were in Visio (connection points and all), yet to be doing it just by updating the DOM of the drawing itself. Developing with SVG is incredibly fast.
SVG is enormously more useful than many realize. It's also one of those technologies that's not going away... it'll take a while for everyone to learn just how good it is, but once they do, watch out!
Cheers!
[An open letter to the paper authors:]
m
Your paper "Defending against an Internet-Based Attack on the Physical World" describes a number of coutnermeasures, almost all of which are focused on the Internet level of the attack.
Since most of the actual bad consequences of the attack come due to the "mail implosion" at the target address, it seems to me that there are other defensive possibilities based on detecting and averting the mail implosion before it happens.
The only entity in a position to do this is the post office itself. But the post office is already in the business of knowing the destination address of every piece of mail in its system. If the post office were able to mine the addressing data in its system to such an extent as to be able to detect sudden service-threatening implosions targeted at a particular address, the post office itself would be able to flag such mail as "nondeliverable due to system abuse" (perhaps with a notification to the target address that their mail was too voluminous to be delivered).
This would of course require exceptional investment in real-time tracking systems by the post office, although since all that is really required is a count of "number of mailings addressed to target" (and not an actual index of what the mailings themselves *are*), it is possible to avoid the overheads of constructing a full per-package tracking system.
This defense, it seems to me, would be performed by the actual victim of the attack -- the post office itself. Moreover, it is hard to see what countermeasures an attacker could employ to circumvent the post office's own monitoring of its traffic.
(I would imagine similar techniques at the email level are likely already used by ISPs to protect users against email implosion attacks...?)
What would you consider the strengths and weaknesses of this defense?
Thank you for a thought-provoking paper.
Sincerely,
Rob Jellinghaus
rob@helium.com
http://www.helium.co
If you'd read the paper (yeah, how often do people do THAT around here?), you'd know that the gun works by ejecting a cloud of superheated, pressurized gas from a storage container at the base of the weapon forwards into a lasing cavity. Every shot involves a high-pressure gas release. It's the internal gas release that causes the recoil.
Cheers!
Rob
It's gonna be a fun couple of years coming up here :-)
Cheers!
Rob
How quickly we forget. Snow Crash had LOTS of plot elements that were all about millimeter-wave radar. It's how the robo-dog saw the world, for heaven's sake!
:-)
"never heard of this before" -- sheesh... kids these days
That would be hard to believe, indeed, especially since the actual article at antarctica.ac.uk says: "Hard to believe that 500 billion tonnes of ice sheet has disintegrated in less than a month."
But a factor of a million here, a factor of a million there, who cares, right? This is Slashdot! We don't need no stinkin' proofreading!
Kohan (www.kohan.net, available for Linux!) has supply zones, morale, formations, and quite a few other more-strategic concepts. It's by far my favorite RTS, as it's *not* a clickfest.
:-)
Anyone who's interested in this thread should definitely at least try the Kohan demo... it's right up your alley
Cheers!
Rob
"New version of EDLIN"???
EDLIN is perfect!
NO MORE NEW VERSIONS, EVER AGAIN!!!!!
Sincerely,
Hackers for Software Finality
I think Lanier's whole discussion of subjective experience is a red herring. Personally, I do think I have subjective experience, but I don't see why a computer -- or some other evolved-partly-by-us creation -- couldn't also have subjective experience. Arguing the point seems to be a fundamental distraction from the deeper issue: what kind of impact ever-evolving technology will have on human society, and whether we will (eventually) create beings comparable or superior to ourselves.
I tend to agree with Lanier that one of the worst risks we face is increasing social inequity. Think about some of the nightmare totalistic scenarios -- that we will create a race of super-beings that will look down on us and use us as fodder. Now, put on a very cynical hat, and think about the world we live in now, where the "first world" consumes most resources; where the richest 1% of the population has over 30% of the wealth; where entire social classes are disenfranchised and economically shut out. Seems to me we already live in the technological dystopia people like Joy and Lanier are afraid of! (I think Lanier acknowledges this, on some level.)
I am still an associate of the Foresight Institute, because it is a good resource for tracking developments in advanced technology. But I haven't been to one of their functions in some time, largely because the prevailing meme pool there doesn't contain enough skepticism for my taste. (Cryonics in particular seems to me to be substituting overwhelming technological optimism for a real confrontation with issues of life and death.)
Putting the optimist hat on, I would hope that newer, smaller, greener technology will eventually reduce humanity's ecological impact on the planet, and that as we do start to evolve creations (creatures) that have greater independence and autonomy, that it helps us widen the "circle of empathy" Lanier mentions. You could take an almost Buddhistic view -- that compassion is the essence of the universe -- and realize that it's our moral responsibility, as creative and intelligent beings, to evolve creatures that are themselves compassionate. Whether we can do this when we are so often lacking in compassion ourselves is another question... in fact (finishing off by wearing the theist hat), that may be the question that God created us to answer.
There is plenty of console precedent for failed add-ons... Microsoft is very smart to avoid making the same mistake.
I'm surprised no one in this thread has mentioned Raimi's film A Simple Plan yet... definitely one of the most gripping, tragic, and powerful movies I've seen in the last few years. If you haven't seen it, see it. It's like Fargo except much bleaker. I think Raimi could do a creditable job directing just about anything, and I'd love to see him helming a Spidey flick!
Current CPUs do all the instruction decomposing into primitive operations, rescheduling, and speculative execution in hardware for every instruction that goes through the execution pipes. The whole point of this patent is that that's all wasted, redundant, excess work. You can save lots and lots of transistors, and gain lots and lots of speed, by simply not doing any of that work more than once. That's what their software/hardware combo lets them do.
It would be pointless to run it on any current chips, since all current chips are literally hardwired to do all the extra work that they're figuring out how to avoid.
As a comparison, one embodiment of the present invention designed to run all available X86 applications is implemented by a morph host including approximately one-quarter of the number of gates of the Pentium Pro microprocessor yet runs X86 applications substantially faster than does the Pentium Pro microprocessor or any other known microprocessor capable of processing these applications.
Imagine that... they really could be talking about a huge price/performance leap. I would be worried if I were Intel or AMD... or Motorola... or IBM... or anyone making chips with lots of on-die instruction wrangling logic.
As a comparison, one embodiment of the present invention designed to run all available X86 applications is implemented by a morph host including approximately one-quarter of the number of gates of the Pentium Pro microprocessor yet runs X86 applications substantially faster than does the Pentium Pro microprocessor or any other known microprocessor capable of processing these applications.
Jeez, that seems pretty impressive, if true. Imagine an Athlon-equivalent ("faster than any other known microprocessor") for one-quarter the price....
Or not... what do I know?
Some other nanoscale folks are working on gears, rods, bearings, etc.
Once we get the wheel worked out, then we can start on the problems of mass production... since right now we're still piecing these parts together one by one.
Difference engine? At least three technology generations away. Colossus? Four. C64? Five. P3? Six. Of course, a nanoscale difference engine is probably about as fast as an IC-scale P3, and a nanoscale P3 probably uses quantum electronics and is *way* faster than an IC-scale P3.
Now, how long is a "technology generation"? Aye, there's the rub :-) Given what I've seen over the last decade, I would estimate about five years....
In other words, the code's not done yet! I actually do believe it probably will be done Real (Real, Real) Soon Now, but still, it's humorous
...for the last six months of my current project: ~16.3K lines of Java. That's on a contract job, involving a lot of requirements thrashing (ergo, a fair amount of code thrown away). But the thing's about to go to code freeze, with adequate quality (i.e. no showstoppers and good usability).
So I guess I'm running about double the productivity of the average worldwide programmer. Only problem is, if I worked over my code I could probably get rid of a few hundred lines here and there, making it cleaner & more stable in the process... would that make me negatively productive?!?! yeah right....
Yale lets you code in Scheme in freshman CS class. Great fun too! Learning about infinite streams after only two months of undergrad CS was a definite mind-opener. aahhh, the memories. It was also fun being among the few in the class who could debug the code :-)
Abelson & Sussman rock hard.
I agree totally. I've been using Kinesis keyboards since 1995, when I had some moderate tendinitis. A better chair with back support and good posture, a keyboard tray to put the keyboard in my lap instead of way out in front of me, a bunch of books under my monitor so it rose up to eye level, and a Kinesis keyboard collectively saved my wrists and arms from chronic pain.
:-)
I can actually type faster with the Kinesis now than I could with other keyboards, since the Kinesis has its keys arranged in vertical rows, unlike almost all other keyboards (including the crappy Microsoft Natural) which have the keys in staggered rows; staggered rows force your fingers to seek horizontally and vertically to hit upper/lower row keys, whereas on the Kinesis my fingers just have to move vertically. Much easier on the hands, and quicker to type. And it even works well for FPS games--the left hand keyboard well is very nicely contoured for speedy keypresses, and having all those keys under the thumb is also mighty fast!
www.kinesis-ergo.com -- check it out. I've turned on about six or seven coworkers to the joys of Kinesis since I got my first one, and I want this company to stay in business (not that I think they're doing badly) for my entire career