Totally agree. I think a major forward step will be when we can get manufacturing facilities in orbit -- one of the major problems we have at the moment is that it requires 'quite a lot of energy' to move a spacecraft from the ground to orbit. It's actually (relatively) cheap to move a probe once it is outside the worst of earth's gravity.
The problem with this is that somehow we need to get raw materials to the manufacturing plants, and we need to get them from space, since launching them from earth is just as expensive as launching the probes themselves.
I suspect this will start happening as nanotechnology and flexible fabrication techniques like the polymer depositing tables we're starting to see. Some forms of materials could be gathered from asteroids and other floating objects, I guess. Anyone know what the raw materials of plastics are? (sorry, not a chemist!)
Yep, that would work. You'd probably need it per
thread rather than process; what you're trying to
cache is the working set of the execution thread (i.e. the portions of RAM that the thread is executing most often).
The problem with this would be expense (as you mentioned), and also that *current* processors are only faintly aware of the process and thread switching of the operating system. This would the processor to be aware of the concept of threads at a very low level indeed.
One problem that I suspect this particular technology will suffer from is that modern preemptive multitasking operating systems in combination with object orientated code (which suffers from poor locality, unfortunately) mean that any microcode designed to detect low levels of cache usage etc isn't going to have enough time to respond before either the OS does a context switch, or the working set of the executing task shifts.
Having said that, I firmly believe that both this technology and Transmeta's 'codemorphing' ideas will become the norm within the next few years. Now, if only they could JIT Java bytecode in microcode...
> my sites all have whole articles, pictures, etc... into a MySQL database.
(Warning: DBA in a previous life - expect pain;)
I really wouldn't suggest placing text articles, images or other large objects into a database tuple. Modern databases (including PostgreSQL; not sure about MySQL) have support for 'BLOBs' (Binary Large Objects), which allow you to associate very large files and objects with a particular tuple.
The BLOBs are stored as part of the database, but not within the relation itself. This works a *lot* faster than putting the images or text inline with the tuple, and is I suspect partly why the folks at PostgreSQL haven't yet fixed the 8kb limit.
Slashdot Mirror
Totally agree. I think a major forward step will be when we can get manufacturing facilities in orbit -- one of the major problems we have at the moment is that it requires 'quite a lot of energy' to move a spacecraft from the ground to orbit. It's actually (relatively) cheap to move a probe once it is outside the worst of earth's gravity.
The problem with this is that somehow we need to get raw materials to the manufacturing plants, and we need to get them from space, since launching them from earth is just as expensive as launching the probes themselves.
I suspect this will start happening as nanotechnology and flexible fabrication techniques like the polymer depositing tables we're starting to see. Some forms of materials could be gathered from asteroids and other floating objects, I guess. Anyone know what the raw materials of plastics are? (sorry, not a chemist!)
Just a thought.
Paul
Yep, that would work. You'd probably need it per
:)
thread rather than process; what you're trying to
cache is the working set of the execution thread (i.e. the portions of RAM that the thread is executing most often).
The problem with this would be expense (as you mentioned), and also that *current* processors are only faintly aware of the process and thread switching of the operating system. This would the processor to be aware of the concept of threads at a very low level indeed.
Very funky idea though
One problem that I suspect this particular technology will suffer from is that modern preemptive multitasking operating systems in combination with object orientated code (which suffers from poor locality, unfortunately) mean that any microcode designed to detect low levels of cache usage etc isn't going to have enough time to respond before either the OS does a context switch, or the working set of the executing task shifts.
Having said that, I firmly believe that both this technology and Transmeta's 'codemorphing' ideas will become the norm within the next few years. Now, if only they could JIT Java bytecode in microcode...
> my sites all have whole articles, pictures, etc... into a MySQL database.
(Warning: DBA in a previous life - expect pain ;)
I really wouldn't suggest placing text articles, images or other large objects into a database tuple. Modern databases (including PostgreSQL; not sure about MySQL) have support for 'BLOBs' (Binary Large Objects), which allow you to associate very large files and objects with a particular tuple.
The BLOBs are stored as part of the database, but not within the relation itself. This works a *lot* faster than putting the images or text inline with the tuple, and is I suspect partly why the folks at PostgreSQL haven't yet fixed the 8kb limit.