Besides, just clocking the processor that high still leaves the problem of fetching data fast enough - a problem already existing today, and the reason why the x86 have such huge caches. Memory bandwidth cannot cope with the operating speeds of the core by simple physical constraints. The connection from the core to the memory is basically nothing but an antenna for the high-frequency signals.

Besides, just to mention another limitation: With a clock speed of 3Ghz already getting a signal from one end of the dice to another end of the dice takes more than one clock cycle. Which was the reason for the unfortune "netburst" architecture.

I don't think that netburst had anything to do with the problem of clock distribution. Besides, even though today's x86 dice are usually greater than 1 cm (~wavelength of a 3GHz clock signal), each core only covers a minor part of the die.

Just for clarity: this is the so-called Von Neumann bottleneck and is something all high-performance processors have to compensate with large amounts of multi level cache memory. Just look at the IBM Power series.

Besides, just to mention another limitation: With a clock speed of 3Ghz already getting a signal from one end of the dice to another end of the dice takes more than one clock cycle. Which was the reason for the unfortune "netburst" architecture.

And that's what some call the real Von Neumann bottleneck. Can't outrun the speed of light. :)
While Netburst was clearly designed for high clock rates with dedicated drive stages in the pipeline (just for allowing signals to propagate) the real problems with it had nothing to do with speed of light. The instruction scheduling was speculative (which isn't a big problem in itself) which was combined with a very inefficient mechanism to retry failed speculations.

In most server workload x86 CPUs usually have IPC of 0.2-0.3, instead of four they are in theory capable.

memory latency doesn't count for most of this slowdown (large L2 cache are quite effective), but branch misprediction.

As i already explained long time ago no branch prediction can properly predict outcomes that depends from input data, which is common case

example C program

char *instr,t1;

while(t1=*(instr++))
  switch(t1) {
  case 'a':
    do_something....;
    break;
  case 'b':
    do_something_else...;
    break;
  default:
    do_default_action...;
  }

unless string have all 'a', 'b' or none 'a' or 'b' character this will execute slow.

In every other case it will execute FAR SLOWER on 2GHz x86 CPU than on simple 200MHz MIPS RISC, the latter having 1/100 of transistor complexity and use milliwatts of power.

This is because of enormously long pipelines and huge branch misprediction penalty. as much as 20 cycle stalls are produced.

recently i tried to understand why FreeBSD system call takes like 3000 cycles even if it is reading 1 byte from file, and even if done in a loop so it is fully cached.

Actually there are below 500 opcodes executed.

Pentium IV is great for MP3 or video encoding, and nothing else.

as you mentioned cores doesn't take whole die, while you exaggerated.

x86 cores are huge and take considerable space.

long wires make capacity problem, when you go over some minimal size (like 1mm on modern ICs) wire resistance+capacitance becomes a problem, and time needed to fully charge/discharge wire grows as length^2

When long connections are needed, they put repeaters every few mm, and - in case of huge buses, increases power.

on modern ICs there are often 1-2 CPU cycles dedicated just for flight time between core and L2 cache.

Porting modern crap like openoffice is just bad idea.

CPU speed is really second issue.

Let's compute a little bit. Speed of light in the vacuum: 3*10^8 m/s, clock cycle: 3*10^9 Hz, duration of one clock 1/3*10^-9. Length an electric signal in vacuum travels during that period: 3*10^8 * 1/3 * 10^-9 m = 10 cm.

Now, speed of light in silicon is only 60% of that in vacuum, plus you need a bit more precision than just a single cycle to synchronize, plus paths of the lines on the chip are not exactly straight: Basically, we *are* at the edge of the physical possibilities.

IOW, yes, I believe this is indeed a problem. On today's processors, you are already off by approximately one clock to half a clock if the signal has to travel from one end to the other.

not that i am aware of each has it's flaws.

Personally I'm interested in microkernels and SASOS. But then you have issues like the OS being a complete ecosystem and not missing any parts, or how you construct your screendrawing (networkable or not).
I consider something like datatypes part of the OS, but for linux there is a wast divide between the kernel, libraries, and the visual system. There is no-one to enforce any standard. Apple dictates their entire ecosystem, but I don't know if any other unix or X11 based system could repeat that.

Some (eg DragonFly with inter-process communication via message passing as in the kernel of the Amiga) try other approaches.

Another problem is the startup delay. According to a discussion topic, the OS libs could be one source of inspiration.

About the OS of Apple, even if it is repainting every year, this is a child of UNIX.

Well, the 20 cycle stalls in the 2 GHz CPU are equivalent to only 2 cycles in the 200 MHz CPU...

Oh, yes, of course. I did microchip design at clock rates quite a bit above 3 GHz where wavelengths were in the cm range so I somehow mixed the numbers.

That's why the cores are usually divided into several local clock domains and clock is distributed along with data flow which cancels out most of the latency. Also, they put dozens of PLLs and DLLs in different parts of the chips to cancel out clock skew and to regenerate the clock signal.

Current processors can execute 5+ instructions per clock. More if converted to RISCy terms.

memory latency doesn't count for most of this slowdown (large L2 cache are quite effective), but branch misprediction.     As i already explained long time ago no branch prediction can properly predict outcomes that depends from input data, which is common case

Then you are provable, absolutely, completely wrong. The majority of input data are predictable to a very high degree. What do you think branch prediction are used for if it wasn't?

<removed example>   unless string have all 'a', 'b' or none 'a' or 'b' character this will execute slow.     In every other case it will execute FAR SLOWER on 2GHz x86 CPU than on simple 200MHz MIPS RISC, the latter having 1/100 of transistor complexity and use milliwatts of power.

Yeah right. Even with fully random input data the branch prediction would be ~50% correct. Branch misprediction penalty for Intel Sandy Bridge is ~15 clocks when fetching from the µop cache. Work it out.

This is because of enormously long pipelines and huge branch misprediction penalty. as much as 20 cycle stalls are produced.     recently i tried to understand why FreeBSD system call takes like 3000 cycles even if it is reading 1 byte from file, and even if done in a loop so it is fully cached.     Actually there are below 500 opcodes executed.

The common case isn't reading 1 byte so a smart coder would optimize for larger reads. I guess you wouldn't?