'whatshisface' would be David Patterson, who together with David Ditzel authored the 'The Case for Reduced Instruction Set Computing' article which started the whole RISC thingie.
Would the translation for each instruction be cached, or is the sequence cached? The article implies that the sequence is cached since the CodeMorph software can optimize the speed on subsequent passes. However, this seems to limit the benefit gained from caching to relatively tight loops or common sequences of code depending on the cache size.
I suspect that the translation units are based on so called 'basic blocks' which can most easily be described as anything in between a target label and a branch (i.e. entry and exit points in your code). This would allow optimisation of loop bodies.
This can be extended by going to 'super blocks' (multiple basic blocks) allowing sofisticated things like loop unrolling, software pipelining etc.
What I'm actually interested in is how the translation cache is being accessed. In a later post somebody states that the translation cache is maintained in main memory (therefore benefitting from the regular data cache). I'm not sure I understand how it is possible to do efficient cache lookups in this way. I assume they use hashing methods to map x86 memory pages to 'translation cache lines', but this has a much higher overhead then hardware based cache lookups.
I am also been a bit suprised by people being worried about loosing the cached translations when powering of a system. People, we're talking here about loops that are being executed 100s if not 1000s of times. Having to do the translation again for the first few iterations is not going to be the big performance loss they seem to think it is!
The other great thing about open source is how much you can strip it down... PicoBSD is a good example. Why fork out $800 bucks for a router or firewall 'black box', when with a little flash RAM and a 486 lying around you can achieve the same thing - IF you're willing to get your hands dirty?
Because time is money. Getting your hands dirty takes time, which in the end might well cost more than that $800 you tried saving.
Builds strong internal and external relationships in order to effectively deliver Apple's message to Linux developers and champion their needs and issues within Apple. Works to help Linux developers get seeded with new Apple hardware to guarantee support for our new CPUs.
to effectively deliver Apple's message to Linux developers? And what could that message be? 'forget linux, it has no future, use OS X'? And since when does Apple make their own CPU's? I seem to recall that the CPU's were never the big problem in porting to Apples hardware! Maarten
Already legendary Linux performance is significantly enhanced. High end SMP support scales well, supporting up to 64-bit processor systems.
What has SMP-scalability to do with 64-bit processors?
and:
Projects such as GNOME (GNU Network Orientated Model Environment), KDE (K Desktop Environment), and Enlightenment all take advantage of the Linux kernel, and allow users to completely customize their Graphical User Interface (GUI). This makes for quick and easy interaction with hardware and software through desktop icons, menus, and keyboard shortcuts.
These have nothing to do with the Linux kernel. In fact, both GNOME and KDE run on a myriad of platforms.
About publishing stuff like this on/., see it as a wider proofreading audience. As long as people give sensible comments on it (and I don't mean stuff like 'this doesn't belong here', 'this should not have come out yet'), it can only help on improving the press release.
Slashdot Mirror
'whatshisface' would be David Patterson, who together with David Ditzel authored the 'The Case for Reduced Instruction Set Computing' article which started the whole RISC thingie.
I suspect that the translation units are based on so called 'basic blocks' which can most easily be described as anything in between a target label and a branch (i.e. entry and exit points in your code). This would allow optimisation of loop bodies.
This can be extended by going to 'super blocks' (multiple basic blocks) allowing sofisticated things like loop unrolling, software pipelining etc.
What I'm actually interested in is how the translation cache is being accessed. In a later post somebody states that the translation cache is maintained in main memory (therefore benefitting from the regular data cache). I'm not sure I understand how it is possible to do efficient cache lookups in this way. I assume they use hashing methods to map x86 memory pages to 'translation cache lines', but this has a much higher overhead then hardware based cache lookups.
I am also been a bit suprised by people being worried about loosing the cached translations when powering of a system. People, we're talking here about loops that are being executed 100s if not 1000s of times. Having to do the translation again for the first few iterations is not going to be the big performance loss they seem to think it is!
Is this the Matt Dillon that wrote the DICE C compiler on the Amiga ages ago? (DICE - Dillons Integrated C Environment?)
Maarten
Because time is money. Getting your hands dirty takes time, which in the end might well cost more than that $800 you tried saving.
Hi,
/., see it as a wider proofreading audience. As long as people give sensible comments on it (and I don't mean stuff like 'this doesn't belong here', 'this should not have come out yet'), it can only help on improving the press release.
read the following:
Already legendary Linux performance is significantly enhanced. High end SMP
support scales well, supporting up to 64-bit processor systems.
What has SMP-scalability to do with 64-bit processors?
and:
Projects such as GNOME (GNU Network Orientated Model Environment), KDE (K
Desktop Environment), and Enlightenment all take advantage of the Linux
kernel, and allow users to completely customize their Graphical User Interface
(GUI). This makes for quick and easy interaction with hardware and software
through desktop icons, menus, and keyboard shortcuts.
These have nothing to do with the Linux kernel. In fact, both GNOME and KDE run on a myriad of platforms.
About publishing stuff like this on
Maarten