1. Scaling != performance. Scaling simply means that if you multiply the hardware by n you should be getting (ideally) close to throughput *n.
2. DB is the bottleneck for most websites. A good connection pooling and caching system are critical. Ahem... last time I checked, Java did considerably better than PHP in terms of both.
3. As PHP was not designed as a multipurpose language, sometimes a PHP-only solution is simply a kludge. PHP's power is in writing webpages quickly, if you want to do, for instance, something more complex like charting in a web page (well, in a.PNG), things can get messy. Yeah, you can do that in C, but what's the point ?
The 2 on-chip cores would still share the L2 and actually have the same memory controller. That would in fact allow them to keep the packaging very similar (most of the external interface - memory and I/O - should be roughly the same)
Furthermore, Hypertransport is *not* simple. As a point-to-point interconnect, maintaining cache coherency is not so easy... But I think they have figured this out already.
While I strongly agree with you that Clearspeed is bullshitware, everything else is simply incorrect.
1. A processor running at 1 GHz while dissipating only 7W of power is a major acomplishment (even if it's the speed equivalent to a Pentium 3 at 700MHz). It's not uncommon for a laptop processor to consume around 45W (i.e. half the total power consumption). 7W simply means that you have twice as much battery time...
2. Sun processors, taken individually, suck big time. Their power come from scalability (putting 32 of them on a single board, for instance).
Furthermore, 15 times the performance should always be taken with a grain of salt. (and you were the one complaining about BSware...). On what benchmarks ? I guess they always use MIPS (which is only meaningful for marketing), and never a real benchmark.
And why exactly are you comparing Sun processors to Transmeta ? They're really meant for different markets... you don't put server procs in a laptop or mobile procs in a server...
Not to mention that Sun starts to smell like a decaying corpse.
Currently, the main computational bottleneck is memory speed & bandwidth. Processors - it's still relatively easy to stay on Moore's curve. But memory speed improves by only a couple of percents per year. Yes, you can throw caches at them (it's not uncommon these days to have 6M or even 8M on a server chip), but those caches are very unlikely to consume 3W...
You can certainly throw a bunch of ALUs on a grid (it's not so difficult) and claim GIPS, GFLOPS or whatever... but you won't get similar speedups on real-life benchmarks, because no program will be able to use them all at the same time (btw, only professional bullshiters - read marketing people - use MIPS/GIPS/GFLOPS these days. The computer architecture has realized for a LOONG time that they're not a good indicator of performance).
As a MDK club member myself, I first applauded the measure to release first to us and then to everybody.
As I'm downloading it right now, I'm wondering however if releasing to everybody through bittorrent wouldn't have been a better choice, as that would imply faster downloads for club members as well...
The biggest problem I see with converting people is the things that used to "just work" and they don't anymore...
The two clearest examples are sound and clipboard. We have alsa, oss, arts, esd as various ways of getting sound... The problem is not choice, but stability and incompatibility. If you use arts, than you can play arts apps, but nothing else...
(it blocks the dev even when no app is running). If you just rely on oss/alsa then all kde apps no longer have sound... Not to mention the serious synchronicity problem that makes the life of game/video player developers a hell.
As far as clipboard is concerned - countless times I got different results by using Ctrl-V and middle button.
Choice is good, but incompatibility is not. The opensource world seems to be entrenched in civil holy wars instead of trying to provide a real alternative (pretty much like the chinese factions in WWII - fighting against each others instead of the real enemy).
To conclude - I agree with you, it's the little things. And it's not a bad thing to copy UI from commercial OSes, as they actually have resources to do usability studies, whereas the OSS world most often doesn't.
My personal conspiracy theory is that there are two companies heavily benefitting from this: Boies' (lawyers always win...) and Microsoft.
After all, where did the funds for this campaign come from ? Microsoft, HP & Sun licensing (Sun is seeing its marketshare destroyed by cheap Linux on Intel, but they're dead anyway)
Microsoft has a lot to gain from SCO spreading FUD for as long as possible. SCO's attempts to slow down the legal process is achieving precisely this. And Microsoft doesn't really care if they win or not - the battle for Server Marketshare is happenning NOW.
Well, when a colleague is talking on the phone, 5 feet away from me, my brain absorbs considerably less radiation than my colleague's brain (it's mostly a matter of solid angle/spherical source). And yes, borrowing works - but so does borrowing cigarettes/alcohol (completely different issue).
I quite agree with everything you said - but you read my message out-of-context. In the parent message it was argued that "radiation is all around us" and you basically can't do anything about it, which, IMNSHO is completely untrue - cellphones are a clear example of that.
As far as rats are concerned, here's a recent source - this is in fact a study of the GSM system.
Regarding the second statement, it was a personal conclusion. There are a couple of cases of mobile phone "abusers" who developed tumors spatially close to the cellphone's antenna. There are studies that show how the blood brain barrier is negatively affected by cellphone-like radiation and some others that show how mininuclei are formed when blood is subjected to the same kind of radiation (mininuclei are thought to be a cause of cancer). Other studies (some of them sponsored by you-know-who) say that statistical data regarding cancer and cellphones is inconclusive and that the risk is clearly small. But cancer is not completely random, some people are more likely to develop it than others (in other words it is an uneven russian roullette).
P.S. I'm clearly not a microbiologist, and there are many things that I'm missing. I just happened to be alarmed by the continuous reports on cellphone unsafety.
The waves being around us is one thing, having a strong microwave source close to your head is completely different.
It is for instance a known fact that the brain absorbes ~60% of a cellphone's emission. That's one of the reasons cellphones have antennae - not for signal quality, but to reduce the absorbtion ratio.
It is also known that the old analog cellphones (brain friers) cause brain damage to rats (fully-repeatable experiments). While experiments with human subject aren't that conclusive, it's quite clear that some people are more likely to develop conditions than others.
Furthermore, an imature body/brain is much more susceptible to develop problems than an adult one.
Symbian is great & all (extremely stable, low footprint, etc.), but in terms of programmability it just sucks badly. Because it's meant to be used on devices with small memories, even doing "simple" operations on strings can be quite a chore. This advantage is crucial for something like a phone, but it's not unusual for a PDA these days to have 64M+ (very limited gains here). Furthermore, the non-standard programming style makes portability a serious issue.
Of course, it would have been nicer if their choice was Linux. OTOH my current Linux PDA (Zaurus) can't really be sync-ed with my Linux Desktop (unless i downgrade my ROM or use OpenZaurus, which is a mess in itself), whereas a WinCE one can...
2. Place lots of R&D on SPARC... it needs to be competitive with POWER... so they need to catch up a bit. It needs to break 1.5-2Ghz (but still be the elegant architecture it is... no corner-cutting)
Even x86 procs are lightyears ahead of SPARC (not to mention the Itanium). SPARCs are good for one thing - scaling - i.e. put 32 of them in a MP system. x86 procs can't really do that yet, but I wouldn't be very surprised if, let's say, an 8xOpteron system beat the shit out of a 32xSPARC machine on an enterprise benchmark.
And btw, for the enterprise segment the frequency of a processor is almost irrelevant - the size of the caches is MUCH more important, as the memory is ~100->400 times slower than the processor. I think that's why the latest Itanium has a whooping 6MB of L3 cache, but doesn't run at the same frequency as the P4.
Maybe because Europeans (and I believe Asians as well) pay a little bit more attention than Americans to true quality and show less "herding" behaviour when doing purchases.
We certainly need a significant improvement in memories as well. Currently an L3 miss costs a P4 Xeon about 400 cycles... As memory speed improves at a much smaller rate than processors (6->20% every 2 years, instead of 100%), what's that penalty going to be ? 1000 cycles ? more ?
Granted, quite a few applications have their working set of about or less than 2MB.... but server apps don't (db, webserver, etc).
DRAM was so far designed for capacity, I believe it's time for a significant change.
The durability constraint of ACID implies that each transaction will be written to hdd when before the commit returns. This is why I don't buy the 3000x faster claim - you can certainly make everything go fast, but you'll still need 1 hdd access per transaction (granted, a db could try to coallesce 2 commits into one write, but that still won't fix much; furthermore, the DBs that I know of simply don't do it).
If they just benchmarked reads... then the results don't tell much.
You're clearly right about instructions requiring operands to be in some registers, etc. The compiler (IIRC) usually keeps EAX through EDX for such computations and register-allocates SI, DI and BP (if available). You clearly have to move stuff back and forth between EAX->EDX and these 3 registers, but a register copy is extremely cheap these days.
It's probably wrong to call them general purpose registers (although that's what Intel does), but the compiler can make use of them for integer operations.
Re:Performance doesn't come directly from 64 bits
on
Is Prescott 64-bit?
·
· Score: 1
The problem is not CISC vs. RISC. You do lose a little bit by having to convert CISC to RISC, but that's manageable. The problem is the number of registers. The compiler can barely allocate 2->3 registers to variables, and consequently has to go to memory many more times than a RISC processor (which usually has 32->128 registers). Accessing registers is much faster than going to memory, even if you hit in the first level cache (and if you don't hit in the caches and have to go all the way to the DRAMs, you'll wait about ~100->400 cycles...)
To be more specific, the compiler has to build traces (or hypertraces) from multiple basic blocks, as the level of paralellism in a basic block is just too small (this is also called "Flynn's bottleneck"). To do this properly you need profiling. JITs and software interpreters can do this on the fly (i.e. you don't need 2-steps compilation), and that's the reason software emulation does better than the hardware one (note: VLIW-scheduling in hardware is possible, but no processor does this AFAIK)
I also agree with you about RSE being a mess - but stackable registers (similar to register windows in Solaris) is a very effective mechanism for reducing memory accesses. It does make out-of-order execution a living hell, but in the end it all comes down to stressing the memory less, as RAM doesn't follow Moore's curve...
Re:Performance doesn't come directly from 64 bits
on
Is Prescott 64-bit?
·
· Score: 2, Informative
Yeah, but support for in the 2 major x86 OSes (Win & Linux) is rather flaky. Furthermore, a "normal" app is still limited to 4G by the OS.
Performance doesn't come directly from 64 bits
on
Is Prescott 64-bit?
·
· Score: 4, Informative
MMX and SSE can already do integer operations on 64 bits... What people don't realize is that the performance improvement comes from a significant change in the instruction set architecture (ISA). While x86 is the most commercially-successful ISA, it is ugly as hell, difficult to compile for and stressing the memory system unnecessarily, as it has very few registers ("difficult to explain and impossible to love" once said an Intel designer).
Itanium is a full fix to the problem. The horrendous x86 ISA is completely replaced by an explicitly-parallel (EPIC) instruction set that has all the nice properties of a RISC machine (easier to compile for, less stress on the memory system as you get 128 registers, easier for the machine to decode the instructions as they're fix format and don't require RISC conversion, etc.). The problems with it are:
1. You need a compiler that "knows" how to bundle instructions effectively (a VLIW-compiler). GCC clearly isn't there yet (it's not uncommon for the intel compiler to beat gcc by 30->50% when running computationally-intensive stuff)
2. Being completely different than x86, it can't be very efficient at emulating x86 programs.
AMD partially fixes the problem by extending the x86 ISA to 64 bits, *and* adding 8 general purpose registers. Because they just extended the ISA, running old code is just as fast. Furthermore, new code can benefit from from the extra 8 registers, and run even faster.
For the short term the Opteron is a pretty impressive chip, but I really don't see how AMD is going to stay on Moore's curve with such a shitty instruction set architecture.
P.S. Clearly 32 bits can only address 4GB of RAM, and for *some* servers more addressing space buys you something. But I'd say they are a very small minority.
Old satellites have a significant processing time as well. Getting from Europe to US through a satellite connection takes about 500->600 ms, where light only accounts for ~200ms of them (satellites are at ~40K Km - 100ms for light). Good ol' traceroute.
Slashdot Mirror
2. DB is the bottleneck for most websites. A good connection pooling and caching system are critical. Ahem ... last time I checked, Java did considerably better than PHP in terms of both.
3. As PHP was not designed as a multipurpose language, sometimes a PHP-only solution is simply a kludge. PHP's power is in writing webpages quickly, if you want to do, for instance, something more complex like charting in a web page (well, in a .PNG), things can get messy. Yeah, you can do that in C, but what's the point ?
Furthermore, Hypertransport is *not* simple. As a point-to-point interconnect, maintaining cache coherency is not so easy ... But I think they have figured this out already.
1. A processor running at 1 GHz while dissipating only 7W of power is a major acomplishment (even if it's the speed equivalent to a Pentium 3 at 700MHz). It's not uncommon for a laptop processor to consume around 45W (i.e. half the total power consumption). 7W simply means that you have twice as much battery time ...
2. Sun processors, taken individually, suck big time. Their power come from scalability (putting 32 of them on a single board, for instance).
Furthermore, 15 times the performance should always be taken with a grain of salt. (and you were the one complaining about BSware ...). On what benchmarks ? I guess they always use MIPS (which is only meaningful for marketing), and never a real benchmark.
And why exactly are you comparing Sun processors to Transmeta ? They're really meant for different markets ... you don't put server procs in a laptop or mobile procs in a server ...
Not to mention that Sun starts to smell like a decaying corpse.
You can certainly throw a bunch of ALUs on a grid (it's not so difficult) and claim GIPS, GFLOPS or whatever ... but you won't get similar speedups on real-life benchmarks, because no program will be able to use them all at the same time (btw, only professional bullshiters - read marketing people - use MIPS/GIPS/GFLOPS these days. The computer architecture has realized for a LOONG time that they're not a good indicator of performance).
As I'm downloading it right now, I'm wondering however if releasing to everybody through bittorrent wouldn't have been a better choice, as that would imply faster downloads for club members as well ...
If linux keeps improving at the same rate, it'll be a viable competitor in the desktop marketplace as well in 2006.
The two clearest examples are sound and clipboard. We have alsa, oss, arts, esd as various ways of getting sound ... The problem is not choice, but stability and incompatibility. If you use arts, than you can play arts apps, but nothing else ...
(it blocks the dev even when no app is running). If you just rely on oss/alsa then all kde apps no longer have sound ... Not to mention the serious synchronicity problem that makes the life of game /video player developers a hell.
As far as clipboard is concerned - countless times I got different results by using Ctrl-V and middle button.
Choice is good, but incompatibility is not. The opensource world seems to be entrenched in civil holy wars instead of trying to provide a real alternative (pretty much like the chinese factions in WWII - fighting against each others instead of the real enemy).
To conclude - I agree with you, it's the little things. And it's not a bad thing to copy UI from commercial OSes, as they actually have resources to do usability studies, whereas the OSS world most often doesn't.
After all, where did the funds for this campaign come from ? Microsoft, HP & Sun licensing (Sun is seeing its marketshare destroyed by cheap Linux on Intel, but they're dead anyway)
Microsoft has a lot to gain from SCO spreading FUD for as long as possible. SCO's attempts to slow down the legal process is achieving precisely this. And Microsoft doesn't really care if they win or not - the battle for Server Marketshare is happenning NOW.
Well, when a colleague is talking on the phone, 5 feet away from me, my brain absorbs considerably less radiation than my colleague's brain (it's mostly a matter of solid angle/spherical source). And yes, borrowing works - but so does borrowing cigarettes/alcohol (completely different issue).
I quite agree with everything you said - but you read my message out-of-context. In the parent message it was argued that "radiation is all around us" and you basically can't do anything about it, which, IMNSHO is completely untrue - cellphones are a clear example of that.
Regarding the second statement, it was a personal conclusion. There are a couple of cases of mobile phone "abusers" who developed tumors spatially close to the cellphone's antenna. There are studies that show how the blood brain barrier is negatively affected by cellphone-like radiation and some others that show how mininuclei are formed when blood is subjected to the same kind of radiation (mininuclei are thought to be a cause of cancer). Other studies (some of them sponsored by you-know-who) say that statistical data regarding cancer and cellphones is inconclusive and that the risk is clearly small. But cancer is not completely random, some people are more likely to develop it than others (in other words it is an uneven russian roullette).
P.S. I'm clearly not a microbiologist, and there are many things that I'm missing. I just happened to be alarmed by the continuous reports on cellphone unsafety.
It is for instance a known fact that the brain absorbes ~60% of a cellphone's emission. That's one of the reasons cellphones have antennae - not for signal quality, but to reduce the absorbtion ratio.
It is also known that the old analog cellphones (brain friers) cause brain damage to rats (fully-repeatable experiments). While experiments with human subject aren't that conclusive, it's quite clear that some people are more likely to develop conditions than others.
Furthermore, an imature body/brain is much more susceptible to develop problems than an adult one.
Conclusion: test, but never with children.
There are some rough edges, but you can get it to work (not true for Zaurus w. new ROM)
Of course, it would have been nicer if their choice was Linux. OTOH my current Linux PDA (Zaurus) can't really be sync-ed with my Linux Desktop (unless i downgrade my ROM or use OpenZaurus, which is a mess in itself), whereas a WinCE one can ...
Even x86 procs are lightyears ahead of SPARC (not to mention the Itanium). SPARCs are good for one thing - scaling - i.e. put 32 of them in a MP system. x86 procs can't really do that yet, but I wouldn't be very surprised if, let's say, an 8xOpteron system beat the shit out of a 32xSPARC machine on an enterprise benchmark.
And btw, for the enterprise segment the frequency of a processor is almost irrelevant - the size of the caches is MUCH more important, as the memory is ~100->400 times slower than the processor. I think that's why the latest Itanium has a whooping 6MB of L3 cache, but doesn't run at the same frequency as the P4.
With the mighty Konqueror you only need a new kio slave :). The others will require a plugin (a very simple one actually)
Maybe because Europeans (and I believe Asians as well) pay a little bit more attention than Americans to true quality and show less "herding" behaviour when doing purchases.
Granted, quite a few applications have their working set of about or less than 2MB .... but server apps don't (db, webserver, etc).
DRAM was so far designed for capacity, I believe it's time for a significant change.
If they just benchmarked reads ... then the results don't tell much.
It's probably wrong to call them general purpose registers (although that's what Intel does), but the compiler can make use of them for integer operations.
The problem is not CISC vs. RISC. You do lose a little bit by having to convert CISC to RISC, but that's manageable. The problem is the number of registers. The compiler can barely allocate 2->3 registers to variables, and consequently has to go to memory many more times than a RISC processor (which usually has 32->128 registers). Accessing registers is much faster than going to memory, even if you hit in the first level cache (and if you don't hit in the caches and have to go all the way to the DRAMs, you'll wait about ~100->400 cycles ...)
I also agree with you about RSE being a mess - but stackable registers (similar to register windows in Solaris) is a very effective mechanism for reducing memory accesses. It does make out-of-order execution a living hell, but in the end it all comes down to stressing the memory less, as RAM doesn't follow Moore's curve ...
Yeah, but support for in the 2 major x86 OSes (Win & Linux) is rather flaky. Furthermore, a "normal" app is still limited to 4G by the OS.
Itanium is a full fix to the problem. The horrendous x86 ISA is completely replaced by an explicitly-parallel (EPIC) instruction set that has all the nice properties of a RISC machine (easier to compile for, less stress on the memory system as you get 128 registers, easier for the machine to decode the instructions as they're fix format and don't require RISC conversion, etc.). The problems with it are:
1. You need a compiler that "knows" how to bundle instructions effectively (a VLIW-compiler). GCC clearly isn't there yet (it's not uncommon for the intel compiler to beat gcc by 30->50% when running computationally-intensive stuff)
2. Being completely different than x86, it can't be very efficient at emulating x86 programs.
AMD partially fixes the problem by extending the x86 ISA to 64 bits, *and* adding 8 general purpose registers. Because they just extended the ISA, running old code is just as fast. Furthermore, new code can benefit from from the extra 8 registers, and run even faster.
For the short term the Opteron is a pretty impressive chip, but I really don't see how AMD is going to stay on Moore's curve with such a shitty instruction set architecture.
P.S. Clearly 32 bits can only address 4GB of RAM, and for *some* servers more addressing space buys you something. But I'd say they are a very small minority.
Old satellites have a significant processing time as well. Getting from Europe to US through a satellite connection takes about 500->600 ms, where light only accounts for ~200ms of them (satellites are at ~40K Km - 100ms for light). Good ol' traceroute.