Author Topic: Mill CPU Architecture  (Read 19068 times)

0 Members and 1 Guest are viewing this topic.

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #75 on: February 07, 2018, 11:22:50 pm »
I don't remember what exactly made me thing this. I think there are operations that would require massive simultaneous (from a programmer point of view) changes to the belt. IIRC, it was something related to function calls. But I really don't remember, since it is hard to keep vaporware in your head for years.

At least software simulator would be nice. I bet they have this by now.
Alex
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10445
  • Country: gb
    • Having fun doing more, with less
Re: Mill CPU Architecture
« Reply #76 on: February 08, 2018, 12:04:47 am »
They are touting as covering the full range of computing needs from embedded to HPC. 

I'm sure Godard has ruled out embedded as a target market.

Quote
An RTL/FPGA implementation of the smallest design would at least build some faith that it isn't vaporware after nearly 15 years of development. Yes, FIFTEEN YEARS. Wikipedia: It has been under development since about 2003 by Ivan Godard and his startup Mill Computing, Inc.

Given an architecture, it is known how to turn that into hardware - providing there are no idiocies such as the iAPX432. Getting the right architecture where it can be seen that all features are present and they all play nicely together is much harder. The last time I saw that was in Gosling's Java whitepaper, back in '96.

Providing an RTL implementation without a fully thought through architecture would be a classic case of rushing to a premature implementation.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline donotdespisethesnake

  • Frequent Contributor
  • **
  • Posts: 935
  • Country: gb
  • Embedded stuff
Re: Mill CPU Architecture
« Reply #77 on: February 08, 2018, 09:09:59 am »
At 15 years, Mill development has been going longer than Propellor 2, a mere 10 years.

Designs on paper can look neat and beautiful, getting them to work in practice sometimes takes a bit of hacking and ugliness. But "winning ugly" is usually better than nothing.
Bob
"All you said is just a bunch of opinions."
 

Offline jbb

  • Frequent Contributor
  • **
  • Posts: 731
  • Country: nz
Re: Mill CPU Architecture
« Reply #78 on: February 10, 2018, 07:45:39 pm »
In several of the videos they said that the ‘shift register’-ness of the belt was provided by auxiliary logic. The actual large registers (which could get very big with vector ops!) stay put.
I guess there’s a (small!) abstraction unit to turn a belt address into a real source address.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #79 on: February 10, 2018, 07:50:54 pm »
In several of the videos they said that the ‘shift register’-ness of the belt was provided by auxiliary logic. The actual large registers (which could get very big with vector ops!) stay put.
I guess there’s a (small!) abstraction unit to turn a belt address into a real source address.
The problem is that you can't implement belt as a standard RAM. There are a ton of operations that need to read/write multiple values on the belt at the same time. With RAM it will either have to be N-port RAM, which is expensive and slow for large N, or each such operation will require multiple clock cycles, which defeats the whole purpose of the belt.
Alex
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 944
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Mill CPU Architecture
« Reply #80 on: February 11, 2018, 08:02:20 am »
Can't remember in which video, but I think he said it was similar to renaming...

I haven't read thru this yet:
https://millcomputing.com/topic/the-belt/

Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10445
  • Country: gb
    • Having fun doing more, with less
Re: Mill CPU Architecture
« Reply #81 on: February 11, 2018, 08:15:23 am »
In several of the videos they said that the ‘shift register’-ness of the belt was provided by auxiliary logic. The actual large registers (which could get very big with vector ops!) stay put.
I guess there’s a (small!) abstraction unit to turn a belt address into a real source address.
The problem is that you can't implement belt as a standard RAM. There are a ton of operations that need to read/write multiple values on the belt at the same time. With RAM it will either have to be N-port RAM, which is expensive and slow for large N, or each such operation will require multiple clock cycles, which defeats the whole purpose of the belt.

By that argument, you can't implement TLB caches since they can't be implemented as a standard RAM!

IIRC there is little point in making the belt more than 32 steps long, which isn't very much hardware.

Perhaps you could indicate the key belt (not RAM) operations that can't be sensibly implemented in logic gates.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #82 on: February 11, 2018, 08:22:57 am »
By that argument, you can't implement TLB caches since they can't be implemented as a standard RAM!
IIRC there is little point in making the belt more than 32 steps long, which isn't very much hardware.
Well, I don't know how long the belt is going to be in high end models. I believe the lowest length I've seen was 8.

I did not say it is impossible, it obviously is not. It is just a matter of belt length at which it becomes impractical or slower than conventional design.
Alex
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1277
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: Mill CPU Architecture
« Reply #83 on: February 28, 2018, 11:59:09 pm »
They are touting as covering the full range of computing needs from embedded to HPC.  An RTL/FPGA implementation of the smallest design would at least build some faith that it isn't vaporware after nearly 15 years of development. Yes, FIFTEEN YEARS. Wikipedia: It has been under development since about 2003 by Ivan Godard and his startup Mill Computing, Inc.

If Mill Computing can't show a booting CPU after 15 years because it is worried that the "simple" design will be too slow is worrying about the wrong thing.

Yes, it's not encouraging.

Quote
The RISC-V project, where FPGA implementations were available from early on, were very useful for popularizing the architecture, and making it easy for tools to be developed and tested, and enabled the transition to custom silicon much easier.

Yes, it's been handled far better .. it's only 3 1/2 years since they decided to get serious about freezing the spec, making everything open source, and getting a community going. Less than eight years total since the first vague idea of making an internal (university) project.

Quote
To me, it seems to be a vacuum for VC money, and vacuuming up the spare time for "keen but green" engineers trying to make a break for themselves.

I'm not sure about the VCs. As far as I know, everyone working on it is doing so for "sweat equity". Still.

Ivan has offered me to come onboard a couple of times, but I sadly need a salary in order to pay rent and eat.

Still, adventure is a good thing. I've handed in my notice at Samsung R&D and I'm starting at a RISC-V company very soon.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1277
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: Mill CPU Architecture
« Reply #84 on: March 01, 2018, 12:04:59 am »
In several of the videos they said that the ‘shift register’-ness of the belt was provided by auxiliary logic. The actual large registers (which could get very big with vector ops!) stay put.
I guess there’s a (small!) abstraction unit to turn a belt address into a real source address.
The problem is that you can't implement belt as a standard RAM. There are a ton of operations that need to read/write multiple values on the belt at the same time. With RAM it will either have to be N-port RAM, which is expensive and slow for large N, or each such operation will require multiple clock cycles, which defeats the whole purpose of the belt.

The belt isn't RAM, it's registers. There are only 8 or 16 or so belt positions, depending on the model of Mill.

Things that are about to fall off the end of the belt (not really -- it's actually just that the register is going to be reused for a new result) and be lost, but that are actually still needed, are copied to "Scratchpad" by the compiler. That *is* RAM. SRAM I guess.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #85 on: March 01, 2018, 12:10:40 am »
The belt isn't RAM, it's registers. There are only 8 or 16 or so belt positions, depending on the model of Mill.
I got a feeling at 8 or 16 positions applies to low end models and actual models that target performance will have much longer belt. In that respect it is not that different from a typical stack-based machine, and you need quite a bit of stack to do any real calculations. Constantly saving things that are about to fall off is a hassle and time sink.

I'd like to see this simulated on real applications, of course. But I feel like we are not getting that any time soon.
Alex
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1098
  • Country: fi
Re: Mill CPU Architecture
« Reply #86 on: March 01, 2018, 12:33:23 am »
Quote
The RISC-V project, where FPGA implementations were available from early on, were very useful for popularizing the architecture, and making it easy for tools to be developed and tested, and enabled the transition to custom silicon much easier.
Yes, it's been handled far better .. it's only 3 1/2 years since they decided to get serious about freezing the spec, making everything open source, and getting a community going. Less than eight years total since the first vague idea of making an internal (university) project.
To be fair, the RISC-V project is also not trying to do anything new, so it's only to be expected they'll get done quicker.

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 944
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Mill CPU Architecture
« Reply #87 on: March 01, 2018, 07:26:46 am »
It's very hard to have a truly original thought.

Since I posted this, I have been studying the topic a bit here and there - and you see a LOT of resources regurgitating the same architecture over and over again. As soon as you get off the beaten path, information dries up pretty quickly. I have dismissed the RISK-V architecture as more of the same but open-source -which is great- but hardly an inspiration for new ideas. With such a single-sided (minded) stream of information, you can be forgiven for thinking there is no other way of doing this.

I find the Mill architecture very innovative -probably due to my lack of experience and insight. Too bad of all those patents, though  ;D
Anyway, what Ivan presents in his videos DOES make me think about the problem in a different way -I am not claiming to understand ALL of it, but I think I got most of it. I know I do not know enough to make claims that the proposed Mill architecture will have such-and-such a problem with the belt (or any other part). I do not have any clue how one could make such a statement based on the high level (simplified) info that is presented - he starts of every presentation with that disclaimer. Many detailed questions come to my mind while watching these videos that just aren't talked about - many of those questions are probably due to my ignorance and their answer/solution is probably a well-know mechanism or principle in the CPU architecture domain.

The hardest thing I find is trying to guestimate if any idea I have is an improvement or even what would be the pro's and con's of such an deviation from the norm - again probably due to my lack of understanding. I liked how Ivan explained how the compiler is doing more of the work of scheduling instructions and I am developing an TTA idea based on that premise. It's a wonderful journey.
« Last Edit: March 01, 2018, 07:31:29 am by obiwanjacobi »
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #88 on: March 01, 2018, 07:36:36 am »
The reason all modern CPUs looks the same is decades of evolution. We have settled on a way to do things that work, and guaranteed to work from a first try. That's how engineering works.

People have tried many other architectures (VLIW, OISC, pure stack-based machines, register-less machines), and there is plenty of information on all sorts of strange stuff. But it does not get wide adoption as none of them actually bring performance improvement significant enough to justify re-doing all the software work that has been going on for the same decades.

Those strange architectures also often face problems interfacing with existing IP. How hard would it be to attach existing GPU to that CPU? Will it just work, or something about new bus structures will make it impossible/impractical?

There is a lot of stuff to think about, and the actual architecture matters very little on a full system scale.
Alex
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1277
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: Mill CPU Architecture
« Reply #89 on: March 01, 2018, 07:59:16 am »
Quote
The RISC-V project, where FPGA implementations were available from early on, were very useful for popularizing the architecture, and making it easy for tools to be developed and tested, and enabled the transition to custom silicon much easier.
Yes, it's been handled far better .. it's only 3 1/2 years since they decided to get serious about freezing the spec, making everything open source, and getting a community going. Less than eight years total since the first vague idea of making an internal (university) project.
To be fair, the RISC-V project is also not trying to do anything new, so it's only to be expected they'll get done quicker.

Certainly RISC-V is a far less ambitious thing, technically. I wouldn't say *nothing* new though. Each individual thing in it has probably been done before ... and generally long enough ago that patent protection has expired. But the combination of things and attention to detail is really quite nice.

When you compare it to the other clean-sheet design that happened at about the same time -- Aarch64 (which also didn't do anything new) -- the RISC-V guys did I think a much nicer job.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10445
  • Country: gb
    • Having fun doing more, with less
Re: Mill CPU Architecture
« Reply #90 on: March 01, 2018, 08:51:42 am »
The reason all modern CPUs looks the same is decades of evolution. We have settled on a way to do things that work, and guaranteed to work from a first try. That's how engineering works.

Not quite.

Evolution, both biological/engineering, makes local optimisations which are based on the history of environmental/technical conditions. It is effectively a "hill climbing algorithm". That leads to messes like the human eye, which a 10 year old can easily see is ridiculous (especially compared with some of the other eyes that have evolved).

It is frequently the case that adjacent "hills" have higher peaks and, if the chasm can be leaped, there are better rewards (a.k.a. a more optimal solution) to be found. That's well known in problems attacked by "simulated annealing" algorithms, e.g. much CAD software.

That is particularly valid when conditions change. In the engineering sense, Moores law is running headlong into thermodynamics problems. Yes transistors can continue to shrink for a few years, but they are very leaky (= hot) and are becoming small enough that there are fewer electrons in them than desirable.

If we want progress to continue, we have to try radically different solutions. The Mill is leaping a chasm in a particular direction.

Quote
People have tried many other architectures (VLIW, OISC, pure stack-based machines, register-less machines), and there is plenty of information on all sorts of strange stuff. But it does not get wide adoption as none of them actually bring performance improvement significant enough to justify re-doing all the software work that has been going on for the same decades.

Those strange architectures also often face problems interfacing with existing IP. How hard would it be to attach existing GPU to that CPU? Will it just work, or something about new bus structures will make it impossible/impractical?

There is a lot of stuff to think about, and the actual architecture matters very little on a full system scale.

True, with reservations.

The architectures you mention typically were pretty small deltas on previous architectures, attacked a small of proportion of the current challenges, and punted difficult problems into the future (assuming Moores Law would come to the rescue). That has advantages and disadvantages.

The Mill is a more radical departure tackling many of the existing challenges. It is reasonable that it should take longer to investigate and document. They are tackling many of the software issues head on, rather than using more transistors to conceal the problems.

So far I haven't seen a flaw in the Mill's architecture. I believe that it can be made to work, and producing initial hardware will not be a major engineering challenge (unlike making a faster x86!). Time will tell whether it succeeds in crossing the chasm.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #91 on: March 01, 2018, 05:28:30 pm »
Evolution, both biological/engineering, makes local optimizations
I did not say that what we have is absolutely the best. I don't think so. But what we have works fine, and evolution did its thing, just like in most other cases.

Overcoming this in favor of something better is going to be hard or impossible.

If we want progress to continue, we have to try radically different solutions. The Mill is leaping a chasm in a particular direction.
Here is a proposal. Stop worrying about the speed of hardware, and start investing into making software faster. Win10 on Core i5 runs slower that Win95 on the first Pentium.


The Mill is a more radical departure tackling many of the existing challenges.
I don't see it as that of a revolution. Majority of things they have are not new ideas, just ideas adopted to work with their core. And I'm not convinced that there is going to be significant performance improvement.
Alex
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10445
  • Country: gb
    • Having fun doing more, with less
Re: Mill CPU Architecture
« Reply #92 on: March 01, 2018, 06:05:27 pm »
Evolution, both biological/engineering, makes local optimizations
I did not say that what we have is absolutely the best. I don't think so. But what we have works fine, and evolution did its thing, just like in most other cases.

Overcoming this in favor of something better is going to be hard or impossible.

The current path has reached its limit, especially w.r.t. thermodynamics (=> don't bother shrinking transistors) and aggregate i/o bandwidth (=> don't bother increasing core count). Radical changes to both hardware and software are going to be needed to make radical progress.

The Mill is a radical change w.r.t. hardware, and is a neat hardware+software system that notably also works with current programs. Many radical changes don't play well with existing software; often complete rewrites are necessary.

The Mill might achieve an order or magnitude improvement for current codes; that's significant and is known to be problematic using other "traditional" technology.

Quote
If we want progress to continue, we have to try radically different solutions. The Mill is leaping a chasm in a particular direction.
Here is a proposal. Stop worrying about the speed of hardware, and start investing into making software faster. Win10 on Core i5 runs slower that Win95 on the first Pentium.

What makes you think it is possible to make serial codes faster? People have been trying that since the 60s, with limited success. All such attempts have ignored existing codebases, and presumed significant paradigm changes. Amhdal's law is still valid.

There are, of course, "embarassingly parallel" problems; while important, they are a subset of what we need to compute.

Quote
The Mill is a more radical departure tackling many of the existing challenges.
I don't see it as that of a revolution. Majority of things they have are not new ideas, just ideas adopted to work with their core. And I'm not convinced that there is going to be significant performance improvement.

Overall the Mill may or may not succeed, but the reasons you have given aren't sufficient to believe it will fail.

My personal suspicion is that the patent portfolio will be licenced and that it will be incorporated into future systems.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #93 on: March 01, 2018, 06:20:56 pm »
The current path has reached its limit, especially w.r.t. thermodynamics (=> don't bother shrinking transistors) and aggregate i/o bandwidth (=> don't bother increasing core count). Radical changes to both hardware and software are going to be needed to make radical progress.
I don't see this as a huge problem. Even if current hardware is fixed, there is a huge margin for extracting actual performance.

I see it as the same thing that happened to Commodore64. Hardware was fixed a long time ago, but there are still games coming out, and they look gorgeous. Since hardware was fixed, people just chose to study it in great details, and learned how to take advantage of all the features.

Same thing happens with modern gaming consoles. When a new generation of console is introduced, games for previous one look much better in many cases. That is until people figure out how to get the maximum performance from the new hardware.

What makes you think it is possible to make serial codes faster?
The fact that we write in JavaScript and F#.

Overall the Mill may or may not succeed, but the reasons you have given aren't sufficient to believe it will fail.
I don't think it will fail, but rather fizzle out as they fail to secure more money.
Alex
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10445
  • Country: gb
    • Having fun doing more, with less
Re: Mill CPU Architecture
« Reply #94 on: March 01, 2018, 06:41:24 pm »
The current path has reached its limit, especially w.r.t. thermodynamics (=> don't bother shrinking transistors) and aggregate i/o bandwidth (=> don't bother increasing core count). Radical changes to both hardware and software are going to be needed to make radical progress.
I don't see this as a huge problem. Even if current hardware is fixed, there is a huge margin for extracting actual performance.

And there are even huger problems doing that in practice.

Frequently there's so much crap that nobody understands it and nobody dare change it - and that's sometimes true for embedded single-manufacturer products, e..g. HP Printers.

So, that's a nice concept, but unrealistic.

Quote
What makes you think it is possible to make serial codes faster?
The fact that we write in JavaScript and F#.

I completely fail to understand the point you are trying to make.

Quote
Overall the Mill may or may not succeed, but the reasons you have given aren't sufficient to believe it will fail.
I don't think it will fail, but rather fizzle out as they fail to secure more money.

I've no idea what the burn rate and funding is. Avoiding making hardware is a smart decision at this stage, provided you ensure there's nothing preventing it being implemented later.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #95 on: March 01, 2018, 06:43:48 pm »
I completely fail to understand the point you are trying to make.
My point is that there is a lot more actual performance in the hardware we have today, but we fail to take advantage of that performance. Even if current technology just stops developing today, we've got 15-20 years of overall system performance improvement just through software optimizations alone.
Alex
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10445
  • Country: gb
    • Having fun doing more, with less
Re: Mill CPU Architecture
« Reply #96 on: March 01, 2018, 06:50:35 pm »
I completely fail to understand the point you are trying to make.
My point is that there is a lot more actual performance in the hardware we have today, but we fail to take advantage of that performance. Even if current technology just stops developing today, we've got 15-20 years of overall system performance improvement just through software optimizations alone.

Please don't snip important context, in this case your reference to JavaScript and F#, viz:
Quote
What makes you think it is possible to make serial codes faster?
The fact that we write in JavaScript and F#.

Would you like to explain how those languages are relevant, and other languages aren't?
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #97 on: March 01, 2018, 06:55:18 pm »
Would you like to explain how those languages are relevant, and other languages aren't?
Those were just two examples of bloated languages highly abstracted from the hardware. There are plenty of others.

Abstraction is good when you have a lot of different hardware, and you need to support all of that in short time. You sacrifice performance big time doing so.

Once hardware is fixed and no longer a moving target, you have incentive to rewrite some of the code in languages closer to the hardware.

Alex
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10445
  • Country: gb
    • Having fun doing more, with less
Re: Mill CPU Architecture
« Reply #98 on: March 01, 2018, 07:00:12 pm »
Would you like to explain how those languages are relevant, and other languages aren't?
Those were just two examples of bloated languages highly abstracted from the hardware. There are plenty of others.

Abstraction is good when you have a lot of different hardware, and you need to support all of that in short time. You sacrifice performance big time doing so.

Once hardware is fixed and no longer a moving target, you have incentive to rewrite some of the code in languages closer to the hardware.

You have a limited view of the software industry, application domains, and commercial incentives.

Other than that, you do have a point for a small part of the industry.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6107
  • Country: us
    • Personal site
Re: Mill CPU Architecture
« Reply #99 on: March 01, 2018, 07:15:00 pm »
You have a limited view of the software industry, application domains, and commercial incentives.
I don't think so. I'm not saying that using Java today is somehow unjustified or bad. Especially given that it is realistically cheaper to buy a better CPU and additional 8 GB of memory than redesign software to consume less.

All I'm saying is that changing conditions will push businesses to make different decisions. When it is no longer cheaper to add more memory, they will pay for developing better software.

But that's also a problem for Mill. Right now, it is more expensive to adopt Mill, even if it comes out. For now, whatever benefits it will bring, can be overcome by throwing more money at existing hardware.
Alex
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf