slacer
Posts: 32
Joined: Mon Dec 26, 2011 9:13 am

Re: Design choices behind the RPi

Tue Jan 31, 2012 10:58 pm

Do you remember to install Linux on a 486 PC with 4 MB RAM or better 8 MB RAM to run X11 on a system with 30 MB  harddrive?

I had to download every single disk image (1.4 MB) A1, A2, A3... and to decide if I want to download the fonts to use with LaTeX for my printer or to download them ready compiled. A common benchmark was how long it takes to compile the linux kernel

You could do a lot with such a system and it was great to learn how to use linux and to write small command line programs in several languages (c, c++, fortran,...)

Starting with a limited system and to see how everything gets bigger, faster from one cpu generation to the next is what you expect. Bigger systems allow you to think about solving problems which where unreachable with those limited systems some years before.

Now you don't want to switch back from your beloved IDE to a pure vi-editor, you don't want to go back to X11... because you know how it feels if everything is running on a big powerful engine with quad core, hyper threading, several GB of RAM and SSD.

I learned how to write assembler for 8051 microcontroller and how to move a robot arm with it. This (8051) is a very limited system but it was used to teach us and it worked.

The Raspberry Pi is a limited system but it is very different from those old 486 DX system from 199x. It is more powerfull and I can't wait to try/port some OpenGL programs on my RPi. The limitations are a fact and you have to tell the students to live with this restriction, but you don't need to expect this is the only computer the students will have access to. They know there are faster systems and they might have a smartphone wich has a better performance than the RPi, but this doesn't matter.

Teach them how to work in an environment with limited resources and give your students good reasons/background stories/ideas about why it is good to know how to work with limited RAM/Diskspace/Batterylife...

This is a really big step into Green IT - think different?

Teach different!

Baconator
Posts: 7
Joined: Fri Jan 27, 2012 4:25 pm

Re: Design choices behind the RPi

Tue Jan 31, 2012 11:29 pm

error404 said:


Or in context more useful, http://code.google.com/p/distcc/


Stop tempting me from cludging together a compiling farm (once everyone interested has acquired at-least one R-Pi)

User avatar
mkopack
Posts: 242
Joined: Mon Nov 07, 2011 8:46 pm

Re: Design choices behind the RPi

Tue Jan 31, 2012 11:58 pm

Also, did you set up the VM image as an ARM computer, or as an X86 hardware? If it was x86, then, yeah, I can see 256MB being pretty limiting, unless you start dropping down to things like a simpler Window manager, pulling out unneeded stuff, etc.

But ARM code usually compiles to a LOT smaller memory footprint than x86. So I'm sure that between using and ARM environment, and going with lower memory footprint WM, and applications, you should be able to have a very capable system.

You just gotta learn how to effectively make use of what you have and not let it be bloated with a bunch of stuff you don't need. You strip out flashy backgrounds, animated window effects, having a ton of apps open at the same time, huge scrollback buffers, etc.

Heck, I've gotten Linux running on an old HP iPaq (not iPAD!) that had a whopping 32 (64? it's been like 8 years so forgive me) MB of RAM, and ran a pretty intensive Java SWING application on it!

I'd suggest grabbing one of the VM's that somebody here has put together for RPi dev and see if that works any better for you.

User avatar
ArborealSeer
Posts: 300
Joined: Tue Jan 24, 2012 9:48 am
Location: South West, UK

Re: Design choices behind the RPi

Wed Feb 01, 2012 9:56 am

slacer said:


Do you remember to install Linux on a 486 PC with 4 MB RAM or better 8 MB RAM to run X11 on a system with 30 MB  harddrive?


My first PC was a 486 DX-33   Before that I was using an Amiga with AMOS and the Dice C compiler.

No access to linux back then. For college we used DOS and Programmers Workbench (the DOS based forerunner of Visual Studio). Who remembers that?

Had a million options in the autoexec.bat for different memory configs to run games or do other things.

Cirrus logic gfx card with 512kb of memory, I think the machine itself only had 16 or 32 meg of memory, and I was the envy of friends for a while with a 512 meg HDD.. How on earth would I ever fill that up!? All a year or two before WIndows 95 came out in my case!

*wipes misty eyes*
Pi Status > Farnell, Arrived 24/5- RS, Arrived 1/6

hyena
Posts: 44
Joined: Mon Nov 14, 2011 7:55 pm

Re: Design choices behind the RPi

Wed Feb 01, 2012 11:33 am

it's useful to look at the plug computer scene .. many people (me included) bought the dockstars, pogoplugs,iconnects (same cpu grunt as pi, no gpu, no fpu, 128mb/256mb ram, ethernet) cheap and hacked them to do useful things 24/7 .. so the pi is fine for real world apps

.. so im my case the plug is running debian cli & dlna server, squeezebox server, openvpn server 24/7

the big issue is memory constraints -  256mb even using debian cli just isnt enough to avoid frequently using the swap file which on usb/sd is S-L-O-W  ... the cpu also lacks grunt and something like squeezebox server (sql/perl) which is periodically cpu intensive swamps the cpu ...

its much better to setup a virtual machine (debian please cross compiling environment so you can run it on a windows pc using the free and excellent virtualbox .... like was done on the plug scene some kind person could setup the pi cross compiling environment as a virtual box disk and post the disk online  .. easy then for people to compile.  the same kind person could also setup a compiling setup on sd and just post the image online (ive posted on this forum the excellent free sd/usb stick image backup/restore tool ppl on the plug scene use) .. bear in mind though crosscompiling on a decent pc will be way way faster

in addition the ease of interfacing will open up no doubt a discount beagle boarders scene with lots of cheap kits available .. this isnt available with hacked devices

so all in all IMHO it should be really great for learning and interfacing   ... in the real world though the lack of ram will be the biggest limitation to running real world apps well, followed by the lack of cpu grunt.

for me i'll buy one to play with but its no faster/no more mem than my hacked plug so until i can get a hacked allwinner a10 android box (or a pi2 with more mem/cpu grunt) the old plug will carry on 24/7

HeadCase
Posts: 51
Joined: Sat Sep 03, 2011 8:11 am

Re: Design choices behind the RPi

Wed Feb 01, 2012 12:57 pm

As far as I can see the RPi is an excellent design. 256M is a very generous slab of RAM, the ARM core is great and it has a very powerful GPU bolted on to take care of the hardware intensive graphics. All that on a CC size board with full connectivity and it only uses 3 or 4 watts. Its a really elegant design. I am having trouble thinking of things this little computer can't do!

Having said that, I think we have to recognize that even linux has become hugely bloated and that regardless of how much RAM you provide, under the current mindset it will just get gobbled up for little or no appreciable gain.  Perhaps if we have a situation where compilers and editors won't run on a computer with a quarter of a Gb of RAM, we might just have a software-bloat crisis, rather than the RPi being a disappointing design.  Maybe the Rpi is more desperately required for re-educating existing programmers rather than encouraging school kids?

I know that some people will see this view as backward, luddite even. RAM is cheap - why not just put more of it on. The point is that the relentless progress in computer technology has been a mixed blessing. You can have a supercomputer on your desk for a few hundred dollars - that's amazing. On the other hand you can install Windows 7 or Ubuntu Unity or (shudder) MS Office on it and you wish you had your PC from 10 years ago - not so amazing.

The bottom line is that the improvement in hardware is mind-boggling - Chips are better, faster and cheaper. In the software department many of those advances just get swallowed for little real improvement.  The idea that you fix software bloat by throwing more RAM and Mips at it is maybe like trying to cure an alcoholic by buying him more scotch.

User avatar
ArborealSeer
Posts: 300
Joined: Tue Jan 24, 2012 9:48 am
Location: South West, UK

Re: Design choices behind the RPi

Wed Feb 01, 2012 1:03 pm

hyena said:


its much better to setup a virtual machine (debian please cross compiling environment so you can run it on a windows pc using the free and excellent virtualbox



May well lean towards that route. Ideally any code would be stored off the Pi's card and outside the VM anyways. (a samba share on a NAS box or something)

VM on desktop machine - compile + remote debug to the pi

Pi – just running the code..

I won't be the first to try so hopefully the community will come up with some nice solutions.

Downside.. likely the machine hosting the VM won't be fanless like the pi.

As an aside,  only problem i've got is.. my second monitor is VGA only, and the one that'd be best for writing code on is the HDMI one.. darn! Unless a cheap HDMI->VGA turns up. Maybe I'll have to steal my g/f's TV thats in a spare room for the Pi or upgrade the one in the lounge
Pi Status > Farnell, Arrived 24/5- RS, Arrived 1/6

Narishma
Posts: 151
Joined: Wed Nov 23, 2011 1:29 pm

Re: Design choices behind the RPi

Thu Feb 02, 2012 12:08 pm

mkopack said:


[...]

But ARM code usually compiles to a LOT smaller memory footprint than x86.

[...]


I think you got that backwards. x86 code should be denser than the equivalent ARM code.

Prometheus
Posts: 308
Joined: Tue Dec 13, 2011 11:09 pm

Re: Design choices behind the RPi

Thu Feb 02, 2012 6:38 pm

^ No, I'm pretty sure mkopack's got it right. Someone posted a size comparison between some stuff, too (some standard libraries, I think it was). The ARM versions were a lot smaller.

User avatar
jojopi
Posts: 3152
Joined: Tue Oct 11, 2011 8:38 pm

Re: Design choices behind the RPi

Fri Feb 03, 2012 9:10 am

mkopack said:

But ARM code usually compiles to a LOT smaller memory footprint than x86.
http://www.csl.cornell.edu/~vi.....ensity.pdf

x86 always beats pure ARM.  That is exactly what you would expect from comparing a variable-length ISA dating back to when memory was really scarce with a fixed-length RISC architecture designed for simple hardware decoding.

This why ARM have had to go through two different thumb encodings to stay competitive.

I would not expect any difference between x86 and Thumb-2 to be very significant for real workloads.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Design choices behind the RPi

Fri Feb 03, 2012 11:47 am

jojopi said:


I would not expect any difference between x86 and Thumb-2 to be very significant for real workloads.


For sure. I've been working with ARM for years and it's certainly not as compact as people would believe versus x86. Sure Thumb-2 is a good deal more compact than the 32-bit ARM encoding, but that's not what the comparison is against.

Also don't forget that this is just the code size - a program's working set (ie the actual data) is going to be basically the same size regardless of the platform, and it normally dwarfs the code size. Packing/pointer sizes won't make a big difference.

I can see the OP's point though, and just saying "well it was fine back in the day with 1kb - get used to it" isn't too helpful. Software memory use has increased in line with what's available!

(my build machine at work can easily blow through 12 GB of RAM with 16 GCC's running -O3)

Return to “General discussion”