Re: [ts-7000] how hard would it be to have mavcrunch support all throughout debian arm, upstream?

["Andrew Gaylard" <>]

On 7/8/06, Dustin Harriman <> wrote:

Hi all,

First of all, please pardon my toolchain ignorance in
advance.

No problem!

I'm wondering how hard it would be to just have
Maverickcrunch support compiled into all debian
packages downloaded from debian mirrors.  In other
words, what would need to be done differently upstream
at Debian?  What are the technical, and social
hurdles?

Presently, the technical hurdles are:
- kernel (done thanks to Lennert, but not widely tested yet)
- glibc (I'm not sure what's required here -- anyone?)
- gcc (done, but also not widely tested)

There's talk of some of the silicon revisions having errors
in the MaverickCrunch part.  If anyone has any more details
on this, I'd be interested.

The social hurdles are: building and testing an entire release
requires long-term dedication.  It's only worth it when there's
a large user-base, and I'm not convinced that the EP93xx CPUs
have it.  Cirrus hasn't tried terribly hard to make MaverickCrunch
popular by providing solving the technical hurdles.

Would debian need to have another arch supported in
addition to arm, called say "arm-mavcrunch"?  Or could
mavrunch support just be compiled into all existing
arm packages, and arm cpus out there who don't support
mavcrunch just not use it and automagically fall back
on floating point emulation?

To get the full speed of MaverickCrunch, everything would
need to be recompiled.  Other approaches such as replacing
NWFPE with Maverick instructions would give some improvement,
but not as much.  And they have their own complexity.

Is it true that the gnu toolchain isn't mature enough
to have Maverickcrunch work, in addition to other
modern features like threads and shared libraries?

I believe it's complete, but "maturity" (in my book) comes
from widespead testing and usage, which hasn't yet
happened.

The reason I ask is that I'm finding some unexpected
major slowness on my ts-7300.  The big example is when
I "apt-get install" software.  Let's say I want to
install icewm and it's suggested packages.  This is
about an 8 MB download, 35 MB once unpacked.  Not
including download time, the installation of those
packages takes over 30 minutes!  Most of the time is
spent by the process "dpkg --unpack (then a list of
all the deb files that have been downloaded)".  This
process pegs the cpu at 100% the whole time.  I
imagine this unpacking is floating-point intensive.
BTW, I don't think the slow disk IO to the SD card is
to blame, as I can get slightly over 1 MB/sec when I
measure throughput with "hdparm -t".

Save me, mavcrunch!  Where are you when I need you!
:)

Sorry to disappoint you, but (de-)compression is done
with integer operations. Your slowness is almost certainly
due to other factors.  Try the same process on a NFS
mount a or USB-connected hard disk.

I'm trying to get an idea of the size of the obstacles
in the way to my ts-7300 behaving like I'd expect a
200 MHz should, wrt to floating point operations.  The
ability to "apt-get install" software from a huge
collection of debian software is basically the main
reason I bought this ts-7300 in the first place.

Sorry, but if you want convience, the price is paid in
speed. If you want speed, you pay the price in convenience,
because you'll have to build your own packages (and
kernel, and toolchain...)


Andrew.

__._,_.___

SPONSORED LINKS

Linux os	Hardware	Arms
Computer internet	Computer security	Computer hardware security

---

YAHOO! GROUPS LINKS

•  Visit your group "ts-7000" on the web.
   
•  To unsubscribe from this group, send an email to:
   =Unsubscribe
   
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---

__,_._,___