Re: End of optimization...

Hi,


mayan@sandbridgetech.com writes:
>Walter Banks wrote:
>> Embedded microprocessors with limited resources and unusual
>> architectures are just the kind of target that compilers should be
>> used for.
>
>I'm not completely certain that I agree. One question is - why develop a
>peculiar architecture in the first place? Why not, for instance, use an
>200MHz PPC/ARM/etc. for everything (or even a 2GHz x86)?


At high volume: cost. For mobile devices: power.


>The reason boil down to:
>- cost: the microprocessors are too expensive; an alternate processor
>better tailored to the problem domain will be cheaper.


Interestingly, this is not always the case. If you also factor in the
development costs, it might actually be _cheaper_ to use a
widely-supported commodity processor rather than some niche device
which has less support from, say, RTOS vendors, debug tool vendors, IP
vendors, etc.


>- power: the microprocessors burn too much power; an alternate processor
>better tailored to the problem domain will use less power


Again, not always. A fast processor can be put to sleep once it has
finished its computation, and only woken up when it is needed. True,
by cutting out the unnecessary parts you can reduce power consumption,
and then you pretty much end up with your customized processor.


>- performance: the microprocessors just can't keep up with the workload;
>an alternate processor with specialized units is a better choice.


Good point, but then you lose out on support from compilers,
debuggers, etc.


>But why stop there? Why develop a fully-programmable solution? If
>you're going to spin a chip, why not just build an ASIC perfectly
>tailored to the problem?


One word: risk. As feature size decreases, the cost of a mask for an
ASIC increases. Rough estimate is around $1 million for a 0.18um mask
set, and if there is a bug in the design you will spend the same
amount for the next version of the mask.


Once you factor that figure into the equation then lowering the design
risk becomes a major factor in the economics of whether a product is
feasible or not. E.g. if you plan on making 1 million devices, and
your profit margin is 50c, then one extra mask because of a bug in
your custom processor means your product is dead. Or you manage the
higher risk with more testing time, but again that eats into your
profits.


>This ASIC may have a limited (or even a large) amount of
>programmability. But, if it was developed for one or two applications,
>then providing a compiler for it is overkill - the effort is better
>spent just hand-coding the chip.


But surely better to use a widely-supported ASIC core processor, like
an ARM or MIPS, and add the extra hardware to support your specific
application, like a bluetooth module or broadband modem. In which
case there is a very compelling need for a _good_ optimizing compiler,
which becomes viable to develop as there will be many designs using a
common core.


>Note also that, in this scenario, a large number of the inner-loops will
>have been optimized away, as well - they will be implemented in special
>hardware blocks, linked together in specific ways.


Which raises the interesting problem of design partitioning, which is another
complex issue.


>Compilers only make sense for platforms - i.e. for some kind of
>generally programmable hardware for which a moderate number of
>applications will be developed.


And also for IP cores, like the aforementioned ARM and MIPS.


>Optimizing compilers only make sense for "consumer" platforms - i.e.
>for platforms for which a large number of applications will be
>developed.


No---they are also _very_ much in demand for large-volume ASIC
products. Consider code size: the code has to go somewhere, and in so
doing uses up silicon area. For the large volumes where ASICs are
economically viable, every mm^2 of chip space becomes _very_
expensive, so we can see a direct correlation between code size and
chip cost.


The other angle is code speed, which has an impact on power
consumption (as does code size, but admittedly to a lesser extent).
If the code can complete its computation sooner, then the processor
can be put back into low power mode, thus reducing the power
consumption.


>While your point about embedded devices being a good target for
>compilers is well taken, I think economics is going to limit the number
>of platforms, and therefore compilers, to a few areas.
>- routers
>- video
>- wireless
>- (possibly) audio


Don't forget:
- mobile phones, PDAs
- wireless modules (bluetooth, WiFi)
- white goods (microwaves, washing machines, fridges)
- brown goods (TVs, VCRs, DVD players, set-top boxes)
- industrial and domestic sensors
- automotive (there are about 100 processors in modern high-end cars these days)


An interesting case are bluetooth modules---typically have an ARM core
running the bluetooth stack, with _everything_ on one chip (RF,
baseband, DSP, digital, FLASH, processor, interfaces, power
management) with current prices around the $4 mark, and looking at
heading towards the $3 mark in the next 18 months or so. The stack
software is just too big to hand-write in assembler, and yet code
quality _IS_ important to both keep the cost of the chip down (size)
and to minimize the power consumption (speed).


>In the embedded arena, areas where compilers MAY still play a part fall
>more in the area of hardware EDA tools: behavioral synthesis either to
>FPGAs or silicon, hardware/software co-development, etc.


Hmmm.... throwing silicon at the problem only makes the problem
bigger, it does not make it easier. And hardware EDA tools are far
from ideal, although slowly getting better.


When you step back and consider the entire design process and its,
sometimes bizarre, economics then many arguments change. Even more so
if your future employment prospects depend on the successful outcome
of a project.


Cheers,
Neil


--
Neil Johnson ::::::::::::::::: University of Cambridge
PhD Research Student Computer Laboratory
http://www.cl.cam.ac.uk/~nej22 http://www.cl.cam.ac.uk

Return to the comp.compilers page.
Search the comp.compilers archives again.