cpu usage way too high (?)

[Nils Faerber]

thomasg schrieb:
> On Sun, Feb 1, 2009 at 7:00 PM, Daniel Spies <daniel.spies at fuceekay.com> wrote:
>> thomasg <thomas at gstaedtner.net> wrote on Sunday 01 February 2009:
>>> On Sun, Feb 1, 2009 at 4:16 PM, Nils Faerber
>>> <nils.faerber at kernelconcepts.de> wrote:
>>>> Daniel Spies schrieb:
>>>>> Hello,
>>>> Hi!
>>>>> I must admit that I am not that deep into hardware. I hope someone could
>>>>> explain me why things are like this. For example if I do "apt-get
>>>>> update" I have 100% cpu usage until it's done. Upgrade does the same.
>>>>>
>>>>> Recently I tried to play a .ogg file for the first time (also .mp3) and
>>>>> am really confused about the cpu usage again. I tried to play it in vlc,
>>>>> but this doesn't work at all. Playing in alsaplayer is nearly
>>>>> impossible, the song laggs like hell. Only in mplayer (console version)
>>>>> I can listen to the song. But if I do anything else, like moving a
>>>>> window or opending any application, writing in xterm make the sound stop
>>>>> or lag. I can see the cpu usage is at 100% all the time...
>>>>>
>>>>> So what my problem is: I used my old 433Mhz (33Mhz more than FR) Celeron
>>>>> with 128MiB (same as FR) of RAM listening to music, playing games,
>>>>> downloading and much more all at the same time and didn't have such
>>>>> lags. So what makes the Freerunner this unresponsive and slow when doing
>>>>> easy tasks?
>>>>>
>>>>> Thank you for enlightening me. :)
>>>>>
>>>>> BTW: I'm using Debian with lxde from the install.sh, but with ext3 and a
>>>>> 1GB (*g*) swap partition on a 8GB (Class6) SD Card (and Qi).
>>>> Ah, Debian, that may explain it.
>>>> With standard Debian players you will not have much fun I assume - same
>>>> is probably true for MP3 BTW. What you need is a player that does not
>>>> use floating point - this kills performance. What is good on an x86 CPU
>>>> with explicit FPU inside the CPU is a nightmare on CPUs without FPU like
>>>> the S3C (ARM). Floating point is only supported by emulation and this is
>>>> slow.
>>>> For this reason there are fixed point optimized versions of most codecs
>>>> around, like madplay for MP3 and Tremor for Ogg.
>>>> So look for a Tremor plugin/player in Debian or compile one yourself and
>>>> CPU usage should go down to something like 30-50%.
>>> That's also the reason why your celeron performs much better.
>>> The Celeron has an FPU, so can do floating point arithmetic in
>>> hardware, while the Freerunner's CPU has to emulate this in software.
>>> Also you can't really compare CPUs by MHz over different
>>> architectures, the CPUs are just not comparable.
>>>
>>> However, you can't expect any magic, a arm9 without FPU is just plain
>>> slow, nothing to do about it.
>>> Also there are far more limitations not ony by the CPU, also by the
>>> FR's hardware design. Especially I/O is terribly bad, so you can't
>>> compare the harddrive in your Celeron machine (which probably does
>>> 20-40 MB/s) with the SD card in the FR (1-4 MB/s).
>> Okay, that explains the bad audio playback. I will give Madplay and Tremor a
>> try. But if CPUs without FPU are that slow, why should one use them? Is this
>> reducing power consumption in some way? Or are ARM CPUs simply smaller? Or
>> what is the benefit of ARM over x86 CPUs with explicit FPU inside? From what I
>> could read from the net, there are ARM CPUs with FPU inside available, so why
>> not taking these?
>>
>> I don't use that Celeron machine any more, it's like 10 years ago, but the
>> hardware specs were (except the architecture) nearly the same. That's why I
>> compared them...
>>
>> I didn't think about the hard disk issue, as 1-4MB/s still seems fast enough
>> for mp3/ogg playback. So I think this  only affecting while facing heavy disk
>> I/O...
>>
>> Thanks for your quick replies! :)
> 
> There is no reason to use an CPU without FPU. It's just an very old
> CPU where in arm-world FPUs were optional and not wide-spread.
> FPU-less CPUs perform worst for all kind of multimedia-stuff because
> this is usually very floating point driven.

I am sorry but I cannot let this stand.
There are reasons for not using CPUs with FPU and it is not because ARM
CPUs are old (or the Ssamsung flavour of ARM used in the GTA02 would be).
If you look at the chip layout of a modern x86 CPU (regardless of brand
and actual type) you will easily find several areas that look similar.
The largest today is the on-die CPU cache - ever growing because in
comparison to the CPU cycles the RAM bus is becoming more and more the
performance bottleneck. The next bigger parts one can see are the fixed
point CPU and ALU along with a larger chunk for the MMU and finally a
quite big part, this is the FPU. And here comes the reason for getting
rid of the FPU: It eats too many transistor gates! Transistor gates mean
chip size and mean power consumption. An FPU can be emulated in software
but parts like cache and MMU can not. So in order to reduce power
consumption the FPU gets stripped first. As easy as that.

And this has nothing to do with ARM - other embedded CPUs follow the
same trick in order to reduce the number of gates, look at MIPS, Hitachi
SH, embedded PowerPC, AVR32, etc.

Multimedia stuff can usually be optimzed for fixed point, like it was
done for OGG with Tremor, MP3 with Madplay, etc. But this kind of
software is based on a long series of mathematical calculations, lot of
them involving frequency spectrum anylisis like FFT. This can easier be
developed using floating point. But once you know how your code shall
look like you can, in most cases, get rid of floating point again. But
this is extra work and many developers omit that.
So there is no intrinsic problem with multimedia that forced it to be
floating point heavy - it is rather the "laziness" of the developers.

> GTA03 will have a much more recent CPU with an integrated VFP (=arm
> FPU), this will most likely multiply the performance for that kind of
> apps.

ARM is a clever company. If you are a chip manufacturer you can get a
customized individual CPU design from ARM, this is their business model,
they sell building blocks and the integration. You can have almost
everything you like, like MMU, DSP, a large variety of interfaces, and
yes, if you have the chipspace and power to feed it, even an FPU.

> ARM CPUs are much smaller, because most x86 CPUs are extremely
> complex, and the main reason to use them is, that all available x86
> CPUs use way to much energy to be used in any kind of handheld device.
> But do not forget, that we talk about a very very old ARM CPU in case
> of GTA02, modern ARM processors are much more powerful. The basic

The S3C2442B is not exactly "really old" - but this depends on the point
of view I guess.

> architecture of GTA02s CPU is almost as old as your celeron (the
> actual implementation is of course not that old, but in ARM land it
> takes more time from the design to an actual product, also  the
> lifecycle is usually much longer).

This is not exactly true. It may look like this from a PC user's point
of view because you are used to this confusing GHz ralley going on
between Intel and AMD. But the GHz do not tell you anything about the
real technology underneath - or why do you think Atom CPUs systems still
need a fan? There is ancient cruft in those x86 thingies.
The embedded CPUs just cause less PR. And they consume way less energy -
a modern smartphone can run for weeks! How long does your average laptop
last? Comparisons are difficult in this area but neither are those
embedded designs old nor are their lifecycles longer. Look at the Intel
PXA CPUs e.g. - they got replaced almost as fast as new Intel x86 CPUs
were introduced. For the largest part of this market the average user
simply does not get to know what happens - and most don't even care
since in most cases you do not have a choice, either you buy that phone
with this CPU or you don't but you cannot get the same one with a
different CPU.

Cheers
  nils faerber

-- 
kernel concepts GbR      Tel: +49-271-771091-12
Sieghuetter Hauptweg 48  Fax: +49-271-771091-19
D-57072 Siegen           Mob: +49-176-21024535
http://www.kernelconcepts.de