Let's see: the Java VM is stack-based, the TAOS VM is register-based, the DIA VM (the heart of the Inferno system) is memory-memory-based (I don't remember which memory model is used by the C# VM).
It looks a little bit like the division between the RISC/CISC/stack based CPUs..
In the CPU ISA war, I would say that the RISC has "won" because if you want to create a new CPU you would choose a RISC ISA.
Commercially the 80x86 has won, but this is more due to its huge software codebase than to its architecture.
I'm not considering VLIW because I don't know of any VM which could be said having a VLIW-like design!
A comparison of all these different VM would be very interesting? Which design increase code density, is easier for getting better performances?
I'm sorry: I didn't knew this, thanks for your reply: I was quite surprised to see a poll on only the downside of the P4.
I also checked some of the discussion refered on the side of this page: woaw! they are quite high-level (betwee guys who apparently know what they're talking about!)
So I have totally reversed my mind about this website, bookmarked.
I agree that the DDR Athlon system looks like a killer but I'm not sure that we can trust this report:
at the right of the frontpage, there is a poll which asks "what is the most negative downside of the P4?".
Urg! The P4 is not even released so how can you benchmark your application on the P4 and see where is the bottleneck!!
And now just looking at the spec of a processor is NOT ENOUGH to say: this is the bottleneck/downside...
So me,I will take this website with a "grain of salt"...
There is a fundamental difference between the HP's dynamo and a "normal" emulator: it emulates the SAME processor as the initial target.
I think that it is a *BIG* difference which may help a lot in this case!
Transmeta's CPU was conceived to emulate first a 80x86 CPU, this can avoid some ISA "mismatch" where every gain which occurs thanks to dynamic optimisation is lost by the necessary translation from one ISA to another..
Java was also lacking in the printing capabilities for a looonnnggg time!
The JDK1.2.0 was very "funny" in this respect:
- it had the JDK1.1x printing API which was deprecated which means that in theory you could still use it, in reality it wasn't working anymore.
- it had the brand new Java2 printing API which was barely working: it used gobs of memory, was really slow, you had to do weird things such disable the double buffering, etc..
The Java language is not bad, but the set of libraries need some bug fixing!
Maybe opensourcing it will help, there are bugs in the BugParade for which more than 100 people asked to be corrected, the bug report was opened 2 years ago and it is still there!!!
To be fair the JDK1.3 fixed a lot of bug, so it is getting better, it is just taking a lot of time..
*Sight*, let's not be religious here!
on
X On OSX Now Free
·
· Score: 1
A CPU alone won't do you any good, usually mainboards for any other general purpose CPU than a x86 are usually much more expensive!
Why? Simply because of the huge number of PC and the economy of scale..
PPC DO NOT offer better performance/price!
Check the SpecInt/SpecFP benchmarks, they are the most reliable tests, do not blindly beleive Intel or Apple...
Better perfomance/power consumed, yes but it is not really an interesting benchmark for desktop computer, for laptop on the other hand it is much more interesting.
Consoles are very very different from general purpose computers so you cannot use Nintendo as an example.
Apple won't use 80x86 CPU but it is much more a problem of hardware control and a problem of software control than only a performance problem..
Very much depends on the software of course
on
X On OSX Now Free
·
· Score: 1
Yes, maybe it was the software: if the software isn't using multiple process, you won't see any improvement going from one to two CPU.
SMP is nice but you really have to know what you're doing!
I'm a huge fan of NEdit, to summarize my POV: it's my favourite editor.
It has only one downside: you have to keep you NumLock off to use the shortcuts (a "feature" caused by Motif..).
This means that I have to remap the NumPad on each computer I use!
This is not a big problem but it is annoying, and NEdit is the only app which is still using Motif on my PC (I don't use Netscape at home).
I have considered doing the port of NEdit to Gtk+, but as I don't know Motif, it would be quite difficult..
- For example, think about a newbie, he wants to use a new editor, he asks in a forum "which editor should I use?".
He will receive MANY answers: joe,vi,pico,emacs,nedit, etc,etc...
The number of answer will confuse him, and will create some troubles, he will ask emacs-related question in a group of users which only use vi for example, well you get the idea.
So having such a big diversity is a "bad" things for a newbie, it confuses him..
- Another example: At one time, I wanted to do some code review of a console in order a) to learn how a console works b) improve the code of the console if possible.
Which console? Well frankly I don't care, the only thing I wanted is to find a well-written console which would be used for a long time..
But the problem is that there is a big number of console (kconsole,xterm,kvt, etc..), and frankly I don't want to spend years looking at all the sources in order to see which has the "best" sources before helping the "best" to become even better..
So, unable to choose, I gave up..
The first and most significant problem (which isn't related to the Web):
the content is much, much more difficult to produce!
There is no 3D photo (well, there is but they are quite rare).
The second problem is that it takes much more bandwith to download 3D than 2D..
As high-bandwith access (xDSL or cable modem) seems to take forever to become affordable (30$ a month for example), this won't change in the near future.
The third problem is the standardization of data, it IS important but even if it can be solved, I suspect that download speed and content production are going to hold back 3D on the Web for a loonng time!
I remember that for the Inferno platform, the Limbo language was interpreted by the Dis VM.
The DIS VM has a CISC like design (memory-memory operations)
See http://www.vitanuova.com/inferno/papers/dis.html
I'm wondering: has anyone compared the benefit of stack-based VM vs CISC-like VM vs other possible design.
It would be interesting to study the size of the generated code, the ease of applying performances optimisations,etc.
If another company had done it, which hardware would they have used?
The 80x86 family of course because of the better performance / price ratio.
No, I'm NOT talking about meaningless MHz race (the PhotoShop benchmark from Apple is not much better, so a filter carrefully hand-optimised in assembly language beats a less optimised one for another computer, duh!) but about the SpecInt/SpecFP which are still benchmarks (thus not perfect).
So the CPU is lacking, the videocard is usually much worse than its equivalent in the PC world and you pay more! The OS may be nice but No thanks!
The system makers are unhappy? Bah!
on
Pentium 4 Delayed
·
· Score: 1
Frankly, I doubt very much that system makers are THAT unhappy about the P4 release and Christmas.
Considers this:
the P4 is going to cost MUCHO DINERO when it will be released, so who will buy this at the beginning?
Answer: mostly companies which needs CPU power (CAD,etc).
And you know what?
Companies don't buy PC for Christmas!
I think that it is more a case of journalistic exageration than a real problem..
you're saying that ATI can't write good drivers and you're giving a link to a review which doesn't tell about any problem with Radeon's driver.
(except the poor 16 bit performances, which maybe due to the driver or not).
And you are a bit biased: sure 4ns DDR SDRAM supply will improve, but it won't become cheap fast..
The 2.4 will include some code to make the kernel more "responsive", but I suspect that this will be true only for "soft-real-time" processes (audio application).
I'm wondering if the desktop responviness will be better under 2.4..
May be, you could try using XFree86 4.x if you have a supported card, I suspect that it would help more than a new kernel release..
Slashdot Mirror
I suppose that you're joking but for your information here ISA means Instruction Set Architecture and has nothing to do with the ISA bus.
Let's see: the Java VM is stack-based, the TAOS VM is register-based, the DIA VM (the heart of the Inferno system) is memory-memory-based (I don't remember which memory model is used by the C# VM).
It looks a little bit like the division between the RISC/CISC/stack based CPUs..
In the CPU ISA war, I would say that the RISC has "won" because if you want to create a new CPU you would choose a RISC ISA.
Commercially the 80x86 has won, but this is more due to its huge software codebase than to its architecture.
I'm not considering VLIW because I don't know of any VM which could be said having a VLIW-like design!
A comparison of all these different VM would be very interesting? Which design increase code density, is easier for getting better performances?
Good luck Cheryl!
PS: I've made my 1000 jump this year and I would die for doing such a looonnngg jump!
The sight must be incredible!
I have done my 1000th jumps this year, and I do agree with you: the length of the jump and the sight would be incredible.
The heavy suit would be less fun though!
Patrick de Gayardon made many many things, but he didn't do this type of high-ballon jumps.
I'm sorry: I didn't knew this, thanks for your reply: I was quite surprised to see a poll on only the downside of the P4.
I also checked some of the discussion refered on the side of this page: woaw! they are quite high-level (betwee guys who apparently know what they're talking about!)
So I have totally reversed my mind about this website, bookmarked.
And thanks again for correcting me.
I agree that the DDR Athlon system looks like a killer but I'm not sure that we can trust this report:
at the right of the frontpage, there is a poll which asks "what is the most negative downside of the P4?".
Urg! The P4 is not even released so how can you benchmark your application on the P4 and see where is the bottleneck!!
And now just looking at the spec of a processor is NOT ENOUGH to say: this is the bottleneck/downside...
So me,I will take this website with a "grain of salt"...
There is a fundamental difference between the HP's dynamo and a "normal" emulator: it emulates the SAME processor as the initial target.
I think that it is a *BIG* difference which may help a lot in this case!
Transmeta's CPU was conceived to emulate first a 80x86 CPU, this can avoid some ISA "mismatch" where every gain which occurs thanks to dynamic optimisation is lost by the necessary translation from one ISA to another..
Do not forget that chips contains bugs and sometimes, you can fix "timing" bugs by using "slow" operation in the microcode.
So squeeze performances out of the microcode? Well, thank you but NO!
OTOH maybe there is a way to add new instructions which could trigger errors only if you effectively use those new instructions...
Java was also lacking in the printing capabilities for a looonnnggg time!
The JDK1.2.0 was very "funny" in this respect:
- it had the JDK1.1x printing API which was deprecated which means that in theory you could still use it, in reality it wasn't working anymore.
- it had the brand new Java2 printing API which was barely working: it used gobs of memory, was really slow, you had to do weird things such disable the double buffering, etc..
The Java language is not bad, but the set of libraries need some bug fixing!
Maybe opensourcing it will help, there are bugs in the BugParade for which more than 100 people asked to be corrected, the bug report was opened 2 years ago and it is still there!!!
To be fair the JDK1.3 fixed a lot of bug, so it is getting better, it is just taking a lot of time..
A CPU alone won't do you any good, usually mainboards for any other general purpose CPU than a x86 are usually much more expensive!
Why? Simply because of the huge number of PC and the economy of scale..
PPC DO NOT offer better performance/price!
Check the SpecInt/SpecFP benchmarks, they are the most reliable tests, do not blindly beleive Intel or Apple...
Better perfomance/power consumed, yes but it is not really an interesting benchmark for desktop computer, for laptop on the other hand it is much more interesting.
Consoles are very very different from general purpose computers so you cannot use Nintendo as an example.
Apple won't use 80x86 CPU but it is much more a problem of hardware control and a problem of software control than only a performance problem..
Yes, maybe it was the software: if the software isn't using multiple process, you won't see any improvement going from one to two CPU.
SMP is nice but you really have to know what you're doing!
I'm a huge fan of NEdit, to summarize my POV: it's my favourite editor.
It has only one downside: you have to keep you NumLock off to use the shortcuts (a "feature" caused by Motif..).
This means that I have to remap the NumPad on each computer I use!
This is not a big problem but it is annoying, and NEdit is the only app which is still using Motif on my PC (I don't use Netscape at home).
I have considered doing the port of NEdit to Gtk+, but as I don't know Motif, it would be quite difficult..
- For example, think about a newbie, he wants to use a new editor, he asks in a forum "which editor should I use?".
He will receive MANY answers: joe,vi,pico,emacs,nedit, etc,etc...
The number of answer will confuse him, and will create some troubles, he will ask emacs-related question in a group of users which only use vi for example, well you get the idea.
So having such a big diversity is a "bad" things for a newbie, it confuses him..
- Another example: At one time, I wanted to do some code review of a console in order a) to learn how a console works b) improve the code of the console if possible.
Which console? Well frankly I don't care, the only thing I wanted is to find a well-written console which would be used for a long time..
But the problem is that there is a big number of console (kconsole,xterm,kvt, etc..), and frankly I don't want to spend years looking at all the sources in order to see which has the "best" sources before helping the "best" to become even better..
So, unable to choose, I gave up..
Not within a year: within 6 months.
The first and most significant problem (which isn't related to the Web):
:-)
the content is much, much more difficult to produce!
There is no 3D photo (well, there is but they are quite rare).
The second problem is that it takes much more bandwith to download 3D than 2D..
As high-bandwith access (xDSL or cable modem) seems to take forever to become affordable (30$ a month for example), this won't change in the near future.
The third problem is the standardization of data, it IS important but even if it can be solved, I suspect that download speed and content production are going to hold back 3D on the Web for a loonng time!
IMHO everything of course
ReiserFS is much more "advanced" in .. its readiness to be included in Linux (some people already use ReiserFS on Linux).
Still, the latest news I heard is that it won't be included in the 2.4.0 but sometimes later in a 2.4.x .
Given Linus latest mail "I will consider only bugfix patches", it seems quite likely.
IBM or SGI JFS may have more advanced capabilities (higher limits etc) but I think that they won't be ready to go into the kernel before 2.5.x..
I remember that for the Inferno platform, the Limbo language was interpreted by the Dis VM.
The DIS VM has a CISC like design (memory-memory operations)
See http://www.vitanuova.com/inferno/papers/dis.html
I'm wondering: has anyone compared the benefit of stack-based VM vs CISC-like VM vs other possible design.
It would be interesting to study the size of the generated code, the ease of applying performances optimisations,etc.
Does anyone has some URL?
If another company had done it, which hardware would they have used?
The 80x86 family of course because of the better performance / price ratio.
No, I'm NOT talking about meaningless MHz race (the PhotoShop benchmark from Apple is not much better, so a filter carrefully hand-optimised in assembly language beats a less optimised one for another computer, duh!) but about the SpecInt/SpecFP which are still benchmarks (thus not perfect).
So the CPU is lacking, the videocard is usually much worse than its equivalent in the PC world and you pay more! The OS may be nice but No thanks!
Frankly, I doubt very much that system makers are THAT unhappy about the P4 release and Christmas.
Considers this:
the P4 is going to cost MUCHO DINERO when it will be released, so who will buy this at the beginning?
Answer: mostly companies which needs CPU power (CAD,etc).
And you know what?
Companies don't buy PC for Christmas!
I think that it is more a case of journalistic exageration than a real problem..
The third (and last) part of the interview is present on the site now, go here.
you're saying that ATI can't write good drivers and you're giving a link to a review which doesn't tell about any problem with Radeon's driver.
(except the poor 16 bit performances, which maybe due to the driver or not).
And you are a bit biased: sure 4ns DDR SDRAM supply will improve, but it won't become cheap fast..
Well, let's wait before saying that Rambus is "winning" in the courtroom, the article was showing that those who are suing Rambus have a valid point.
Then again, justice decision are quite unpredictable..
Fitting Linux+X in 16 MB (8MB flash + 8 MB DRAM) is not very impressive I think.
I'm quite sure that commercial RT OS plus their GUI can be much lighter than this, so...
Is-it 2.2 or 2.4 ?
The 2.4 will include some code to make the kernel more "responsive", but I suspect that this will be true only for "soft-real-time" processes (audio application).
I'm wondering if the desktop responviness will be better under 2.4..
May be, you could try using XFree86 4.x if you have a supported card, I suspect that it would help more than a new kernel release..
Are you using KDE, if yes KDE 2.0 should help..