is a beagle device comparable to the rasp pi at a similar price point possible?
I really think the raspberry pi is crossing an important price boundary as it is now in the range of
ordinary microcontroller dev boards and is a direct competition to all those AVR and PIC based
boards. And this may imho really make the difference.
Any plans to be as competitive with a TI based unit? There's imho a huge market for "Linux based
microcontroller replacements" where the key factors are price and power consumption as these
are usually the main reasons to not choose a linux board. Additionally Linux adds the
wlan/ethernet/ip connectivity all current µC based boards lack. This is really is something many
people are waiting for (yes, i know uIP and LwIP, but these are pretty limited).
Regards,
Till
> --
> To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com
> Frequently asked questions: http://beagleboard.org/faq
Hi,is a beagle device comparable to the rasp pi at a similar price point possible?
I really think the raspberry pi is crossing an important price boundary as it is now in the range of
ordinary microcontroller dev boards and is a direct competition to all those AVR and PIC based
boards. And this may imho really make the difference.
Any plans to be as competitive with a TI based unit?
There's imho a huge market for "Linux based
microcontroller replacements" where the key factors are price and power consumption as these
are usually the main reasons to not choose a linux board. Additionally Linux adds the
wlan/ethernet/ip connectivity all current µC based boards lack. This is really is something many
people are waiting for (yes, i know uIP and LwIP, but these are pretty limited).
Regards,
Till
> ARM11 is not compatible with float operations. So here BB beats it.
That is not true. Most ARM11 implementations have a VFP floating point
unit.
--
Måns Rullgård
ma...@mansr.com
>> On Feb 25, 6:12 pm, Måns Rullgård <m...@mansr.com> wrote:
>>> Anton Komarov <akoma...@nvisiongroup.ru> writes:
>>> > ARM11 is not compatible with float operations. So here BB beats it.
>>>
>>> That is not true. Most ARM11 implementations have a VFP floating point
>>> unit.
>
> Not sure it rather could process mp3 encoding with even 8000 Hz. On
> BBxM it takes 5 percent of CPU on 800 MHz.
> If we would talk about 44100 Hz encoding it will eat 40% CPU on
> 1000MHz. What will happen with Rasp in that case? I am pretty sure you
> can guess.
Does that encoder use floating-point (LAME does)? If so, the 700MHz
ARM11 will probably be _faster_ than the Cortex-A8 due to the crippled
scalar FPU in the A8. An encoder using NEON on the A8 would of course
be faster still.
--
Måns Rullgård
ma...@mansr.com
Not sure it rather could process mp3 encoding with even 8000 Hz. On
BBxM it takes 5 percent of CPU on 800 MHz.
If we would talk about 44100 Hz encoding it will eat 40% CPU on
1000MHz. What will happen with Rasp in that case? I am pretty sure you
can guess. Rasp could be effectively used in non-multimedia tasks as
BBxM could be effectivly used in both cases. I wonder when TI will
make audio encoding with DSP?
>
>
> On 27 February 2012 10:14, Anton Komarov <anton....@gmail.com> wrote:
> Not sure it rather could process mp3 encoding with even 8000 Hz. On
> BBxM it takes 5 percent of CPU on 800 MHz.
> If we would talk about 44100 Hz encoding it will eat 40% CPU on
> 1000MHz. What will happen with Rasp in that case? I am pretty sure you
> can guess. Rasp could be effectively used in non-multimedia tasks as
> BBxM could be effectivly used in both cases. I wonder when TI will
> make audio encoding with DSP?
>
> The R.Pi GPU is capable of 24 GFLOPS of general-purpose compute, but for licensing reasons only h.264 and MPEG4 (plus some license-free) codecs will be exposed at launch time as I understand it. It will be interesting to see if and how Broadcom exposes more of that general-purpose GPU grunt in the coming months and years.
>
> Either way, with 1080p30 h.264, Open GL ES 2.0, Open VG, EGL and OpenMAX support from launch, it should offer some very impressive bang for buck in a number of (arguably somewhat specific or focussed) media use cases.
What I fear will happen is people wanting to run a 'desktop' on that 1080p screen. The original beagleboard (720MHz cortex A8) needed a lot of tweaking for that to become "usable" and people were disappointed with that. On the Pi you'll have to explain that decoding 1080p h264 works fine, but minesweeper is glacially slow...
But yeah, XBMC will do nicely on the Pi.
regards,
Koen
[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/Cegdejjh.html
Frans
PS: I hope the Pi is a little bit less picky wrt SDHC than the BB
> 2012/2/25 Måns Rullgård <ma...@mansr.com>:
>> Anton Komarov <akom...@nvisiongroup.ru> writes:
>>
>>> ARM11 is not compatible with float operations. So here BB beats it.
>>
>> That is not true. Most ARM11 implementations have a VFP floating point
>> unit.
>>
> The Pi has a Broadcom BCM2835 Soc containing a 700 MHz ARM11 ARM1176JZF-S core.
> According to the tech manual [1] this core has a VFP unit.
It does indeed, as indicated by the F in the core designation.
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/Cegdejjh.html
>
> Frans
>
> PS: I hope the Pi is a little bit less picky wrt SDHC than the BB
BB picky? I had not noticed.
--
Måns Rullgård
ma...@mansr.com
see eg my post at
http://groups.google.com/group/beagleboard/browse_thread/thread/60d79985a34047f5%29?pli=1
I tried one of those cards with ubuntu on beagle bone a while back and
bumped into the same issue. Didn't dive further in it.
Frans
There are people out there testing cards and posting their real
performance data in r/w operations on various Linux filesystems.
Hopefully the manufactures will get wind of this and clean their act
up and come up with a rating scheme that reflects reality.
Regards,
Brian
There was a patch a while ago on this mailing list which came from
inside TI and incremented a delay counter (by 2 from memory but I
may be wrong). There was a question as to whether this fix could
go into the mainstream and I suppose it may never have. Maybe
someone needs to push it.
David
The system installed and booted but part way through updates it failed
with filesystem errors.
Running fsck.ext4 didn't fix the problem so I reverted to using a 16GB
card and I've chosen a 16GB for the BeagleBone and installed Ubuntu.
The 32GB was formatted as 1 ext4 partition and Ubuntu x86_64 installed
on it and there were no problems with it.
As an aside issue I have often wondered what the rationale is for using
a VFAT partition.
73 ... Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot,
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
> As an aside issue I have often wondered what the rationale is for using
> a VFAT partition.
As a boot partition? well, its a very simple file system format that's
easy to implement in boot code.
Also it's one of the most widely supported ones, regardless of how
"bad" it is.
And nobody forces you to boot from VFAT, you can just as well boot
from "raw" SD or NAND
Are you involved in the Pi? Or why do you fear this?
Till
> On Feb 27, 11:18 am, "Till Harbaum / Lists" <li...@harbaum.org> wrote:
>> Am Montag 27 Februar 2012 schrieb Koen Kooi:> What I fear will happen
>> is people wanting to run a 'desktop' on that 1080p screen. The
>> original beagleboard (720MHz cortex A8) needed a lot of tweaking for
>> that to become "usable" and people were disappointed with that.
>>
>> They seem to handle the Pi more like a phone or other ordinary
>> embedded device. E.g. they are using it as a target for the Qt SDK
>> from the desktop. So you develop on the desktop and then run just
>> your application on the Pi and not an entire desktop. Imho they seem
>> to address the Pi using qml in a pretty similar fashion you guys
>> here address the beaglebone with its javascript thing.
>
> My understanding is that RasPi is to be used as a self-sufficient
> computing platform, not as a target for a cross-development
> environment on a separate PC. RasPi's motto is "An ARM GNU/Linux box
> for $25. Take a byte!" It's target audience is school-children who
> cannot afford their own PCs and cannot afford to risk bricking the
> family PC by doing this dangerous thing called "programming". So
> RasPi is cheap enough to break, and you probably won't break it (once
> they have cases!) since you can always reprogram the SD card from
> scratch.
Reprogram using what, if the RPi is "the" computer?
> We'll see how well it does with native compiling. It will probably do
> great for the intended audience. Sure, if you want to rebuild an
> entire GNU/Linux distro you'll want something with more computing
> power and disk bandwidth. But for creating user-space applications it
> will probably be fine.
Sure, if by userspace you mean "hello world."
--
Måns Rullgård
ma...@mansr.com
The modern PC is far less useful as a teaching device as the 80s crop
of computer were (TRS-80, BBC Micro etc.), it's too expensive and too
much of a closed box.
A device like the RPi combined with good educational materials should
make if possible to replace the current "ICT" curriculum (Word, Excel,
Powerpoint) with something that does not bore most kids out of their
skulls, and get them interested in science and technology.
The floating point performance of the RPi is really not very relevant
here, the relevant questions are:
- will someone develop good educational materials?
- will schools adopt them?
- will the RPi help getting more children interested in science and technology?
--
Gé
Another bootable SD card, a $9.99 USB SD card writer, and 'dd'. Or the
teacher's PC.
> Sure, if by userspace you mean "hello world."
I'm sure the performance of compiling a large C++ program using a lot
of Boost libraries will leave something to be desired (it does on my
quad-core PC).
But editing and running a 5000 line Python program should be fast enough.
I've compiled some larger C programs on the Beaglebone, and that's
reasonably fast, compilers and libraries stay resident in the buffer
cache. Of course, if you can't live without the training wheels
provided by Visual Studio or Eclipse you may have problems :-)
--
Gé
There might be enough GPIOs for most projects on the raspberrypi.
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."
You can get such cable for cheap:
http://www.zoobab.com/nokia-ca42-3-3v
Hi,
is a beagle device comparable to the rasp pi at a similar price point possible?
I really think the raspberry pi is crossing an important price boundary as it is now in the range of
ordinary microcontroller dev boards and is a direct competition to all those AVR and PIC based
boards. And this may imho really make the difference.
Any plans to be as competitive with a TI based unit? There's imho a huge market for "Linux based
microcontroller replacements" where the key factors are price and power consumption as these
are usually the main reasons to not choose a linux board. Additionally Linux adds the
wlan/ethernet/ip connectivity all current µC based boards lack. This is really is something many
people are waiting for (yes, i know uIP and LwIP, but these are pretty limited).
Regards,
Till
With 64 MB of RAM and a slower CPU I think it will require something
special to become popular.
Frans
Beagle: cortex a8 - armv7a
Pi: arm11 - armv6
olimex: arm926 - armv5te
What's next? A $5 MSP430 board?
regards,
Koen
Actually they are $4.30 for the launchpad kit ... but then you have to
pay more than that for shipping ;)
A whopping 128 bytes of RAM!
B
Frans
A whopping 128 bytes of RAM!
between $30 for ARM9 and $5 for MSP430 there
is room for a $20 ARM7 running ucLinux...
Cortex M3/M4 maybee.
On Thu, Mar 8, 2012 at 3:36 PM, Vladimir Pantelic <vlad...@gmail.com> wrote:Koen Kooi wrote:between $30 for ARM9 and $5 for MSP430 there
Op 7 mrt. 2012, om 19:10 heeft robert.berger het volgende geschreven:
Hi everybody,
Looks like a new Olimex Linux board will also be coming for 30 EUR.
http://olimex.wordpress.com/2012/03/07/imx233-olinuxino-development-started-today/
Beagle: cortex a8 - armv7a
Pi: arm11 - armv6
olimex: arm926 - armv5te
What's next? A $5 MSP430 board?
is room for a $20 ARM7 running ucLinux...
On Thu, Mar 8, 2012 at 10:21 AM, Jayanth Acharya <jayac...@gmail.com> wrote:On Thu, Mar 8, 2012 at 3:36 PM, Vladimir Pantelic <vlad...@gmail.com> wrote:Koen Kooi wrote:between $30 for ARM9 and $5 for MSP430 there
Op 7 mrt. 2012, om 19:10 heeft robert.berger het volgende geschreven:
Hi everybody,
Looks like a new Olimex Linux board will also be coming for 30 EUR.
http://olimex.wordpress.com/2012/03/07/imx233-olinuxino-development-started-today/
Beagle: cortex a8 - armv7a
Pi: arm11 - armv6
olimex: arm926 - armv5te
What's next? A $5 MSP430 board?
is room for a $20 ARM7 running ucLinux...
32k of ram? 512K flash? 60MHZ (with crystal upgrade)? Don't think the above is competitive with beagle or RasPi.
BTW, IIRC, I had found a STM ARM7TDMI board w/ 1.8" color TFT, at a Chinese site, selling for around $24 or so... just can't seem to recollect which one/where.
--
Also neither of these boards can run Windows, but both lpc and raspi
are cheaper in doing that than beagle ;) Anyway, who cares about
Ubuntu as long as raspi can run Linux?
--
Best regards,
Siarhei Siamashka
--
Best regards,
Siarhei Siamashka
Yes, this is surely nice.
> BeagleBone is quite a bit more capable than the RPi in terms of general purpose processing power
There are many other boards with ARM processors. And many of them are
a lot more capable than BeagleBone in terms of general purpose
processing power. So BeagleBone is hardly a good choice for those who
are looking for the best possible performance.
A good thing about RPi is that it looks like a very promising
contender for the best price/performance crown.
> and does run things like Windows Embedded Compact 7:
>
> http://www.youtube.com/watch?v=yQrYJyXJR4E
Well, let's see. Some piece of software lists "Windows XP or later" in
its system requirements. Is this "Embedded Compact 7" thing earlier or
later? :)
> Somehow, this thread is turning into a bit flame'ish one. I'd tend to assume that we are at a confluence where too many
> people (myself included) who approach platforms like B'bone or RasPi from the Arduino angle, are meeting industry
> old'timers and possibly leading to some sort of mini conflict of cultures. Board "price", as Jason (I think) mentioned
> earlier on in this thread, has assumed a rather significant dimension in this whole thing, that product capabilities /
> features have begun to look secondary. While one may decide to "not care" and move-on, an alternative approach could be
> to share some insights on how boards are priced. Is it purely RasPi's volume at play here, that they are above to give
> such a phenomenal price ?
the price is not "phenomenal". Lets put it into perspective. Take a $99 android tablet from china.
for $99 retail, it has a BOM (bill of material) of roughly $50. the other 50$ are markup for the
manufacturer and the retailer. Now, from that BOM remove all the (expensive) parts like Wifi chip,
NAND storage, LCD, touchscreen, battery, casing, packaging and assembly and you will end up with a
BOM at 20-25$. And this would be a 1GHz Cortex A8, not the R-PIs, 700MHz ARM11.
How else can one justify difference of more than 100% between an AP, one which is ARM11 and
> the other is a Cortex-A8, much of else being roughly, at-par. RasPi is a 100% non-profit thingy (well, at the surface
> at-least), I am sure there is a lot of commercial interest behind it's success, but it is not unfair for other
> open-boards to have profit objective, just that many people fail to see how it could be something close to 100%
> (assuming AP + memory price difference at those volumes to be not more than total of $10).
Beagles use only components that are freely available, thus making it possible for anybody to
"clone" the design (even at a lower price). The CPU used on the R-PI requires you to sign an NDA
to even have documentation, no idea if you can buy it at all.
As mentioned, the Beagle BOM is open and available and anybody can inquire for prices on all the parts
and come up with his own end price. Conspiracy theories just add noise...
Some of it is just different use cases.
For the kind of stuff I do, for example, -- namely Android platform
development -- the RPi will likely just not do: no serial, no JTAG and,
apparently (I haven't checked this myself), 20% slower CPU. You can add
the serial and JTAG, true, but they're not there to boot. So add $ for
those. In the case of the CPU, though, it's just non-negotiable. See
this post (http://www.opersys.com/blog/beaglebone-android-start) on my
experiments running Android on the 'Bone at 500MHz (USB-powered) vs.
720MHz (DC-powered.) In sum, 20% slower means Android is sluggish. And
then we haven't discussed expandability ...
From my point of view, this whole "debate" is possibly misleading and
it's unfortunate that RPi leadership made comments comparing both. As
Jason said very early on in this thread, there's likely no reason the
price-point couldn't be matched. The question is: what need is the board
trying to fulfill?
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
I've been following this thing from the start and the goals of the Pi
Foundation are very similar to the "One Laptop per Child" effort years
ago. The end goal is to get these into the hands of teachers &
students to interest the next generation in technology (engineering
... which appears to be on the decline with less new students and the
boomers retiring). Having said that, I think the target is
programming, operating systems, windowing systems etc. in general and
not a hard core embedded focus although it could be used for some
embedded projects too.
Regards,
Brian
Op 9 mrt. 2012 om 05:25 heeft Karim Yaghmour <karim.y...@opersys.com> het volgende geschreven:
>
> On 12-03-08 10:59 PM, Jayanth Acharya wrote:
>> Somehow, this thread is turning into a bit flame'ish one. I'd tend to
>> assume that we are at a confluence where too many people (myself
>> included) who approach platforms like B'bone or RasPi from the Arduino
>> angle, are meeting industry old'timers and possibly leading to some sort
>> of mini conflict of cultures. Board "price", as Jason (I think)
>> mentioned earlier on in this thread, has assumed a rather significant
>> dimension in this whole thing, that product capabilities / features have
>> begun to look secondary. While one may decide to "not care" and move-on,
>> an alternative approach could be to share some insights on how boards
>> are priced. Is it purely RasPi's volume at play here, that they are
>> above to give such a phenomenal price ? How else can one justify
>> difference of more than 100% between an AP, one which is ARM11 and the
>> other is a Cortex-A8, much of else being roughly, at-par. RasPi is a
>> 100% non-profit thingy (well, at the surface at-least), I am sure there
>> is a lot of commercial interest behind it's success, but it is not
>> unfair for other open-boards to have profit objective, just that many
>> people fail to see how it could be something close to 100% (assuming AP
>> + memory price difference at those volumes to be not more than total of
>> $10).
>
> Some of it is just different use cases.
>
> For the kind of stuff I do, for example, -- namely Android platform development -- the RPi will likely just not do: no serial, no JTAG and, apparently (I haven't checked this myself), 20% slower CPU.
More like 50% slower, it's an arm11, which someone described as the "most unsuccessfull arm CPU ever"
> You can add the serial and JTAG, true, but they're not there to boot. So add $ for those. In the case of the CPU, though, it's just non-negotiable. See this post (http://www.opersys.com/blog/beaglebone-android-start) on my experiments running Android on the 'Bone at 500MHz (USB-powered) vs. 720MHz (DC-powered.) In sum, 20% slower means Android is sluggish. And then we haven't discussed expandability ...
>
> From my point of view, this whole "debate" is possibly misleading and it's unfortunate that RPi leadership made comments comparing both. As Jason said very early on in this thread, there's likely no reason the price-point couldn't be matched. The question is: what need is the board trying to fulfill?
>
> --
> Karim Yaghmour
> CEO - Opersys inc. / www.opersys.com
> http://twitter.com/karimyaghmour
>
That seems like a reasonable guess.
> it's an arm11, which someone described as the "most unsuccessfull arm
> CPU ever"
I disagree with that assessment. The ARM11 was used in a huge number of
phones, including the iPhones prior to 3GS.
However, I challenge you to find an ARM10 in the wild. Or an ARM8.
--
Måns Rullgård
ma...@mansr.com
I don't think this "decline" is due to not enough "computers"
being available to students or teachers in the UK (or the rest
of the western world)
Don't you?
To what do you ascribe the decline?
I agree with the Pi foundation - there are not enough of the /right/
/kind/ of computer available to students. It has to be cheap and
accessible, and to not be a serious problem if the student breaks
it - which rules out the family PC, because if one of the kids
breaks that with his/her programming experiments, the family's
data are lost.
The other problem is the lack of teachers who can programme and
teach programming. That's not so easy to solve.
Dave
Some years ago a student at a college here in the UK Midlands offered to
help them out of a bind where their NT network was down and all avenues
to putting it right seemed a dead end.
They took him home to collect his Linux PC and he had them up again in
no time. His reward was to be watched closely whenever he approached a
PC. When he asked them why he was told it was because he was a hacker.
Some will definitely learn a different approach but many will probably
scoff at the idea of using something that is different and something
they are unaccustomed to.
That's the cynical view but here is hoping it turns out differently so
we turn out capable people so that in years to come we don't get another
paper from employers entitled "Running on Empty" and having to recruit
employees from abroad to fill the computer skills gap that exists.
Regards
SID.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot,
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
> I agree with the Pi foundation - there are not enough of the /right/The suggestion is that the *cause* of the decline is the lack of
> /kind/ of computer available to students. It has to be cheap and
> accessible, and to not be a serious problem if the student breaks
> it - which rules out the family PC, because if one of the kids
> breaks that with his/her programming experiments, the family's
> data are lost.
>
> The other problem is the lack of teachers who can programme and
> teach programming. That's not so easy to solve.
>
> Dave
computers being available to students. Let's face it, there are MORE
computers, MORE available to MORE students now than there has been at
any time in history. You can't possibly attribute a decline in
interest for computers to the lack of computer availability in any
way!
Making more computers available in more ways may help the problem, but
the lack of computer availability was never the cause of a *decline*
in interest in the first place.
To quote Dave Higton, "To what do you ascribe the decline?" How can
you attribute the decline in interest in computers to the lack of
something that has never been around? You aren't making sense.
> We live in very different worlds. I was one of those computer owners
> in the 80's and what I remember was that there were VERY few of them
> ever bought by anyone other than total geeks like myself.
Ah, now at last I understand /what/ you said didn't exist. You had
lost me.
Indeed we /did/ live in very different worlds. In the UK we had the
ZX80 (the kit), the ZX81, the ZX Spectrum, the BBC Micro, and lots of
other models. And lots of people did have them, mainly for the kids.
> Yes, the computers were not hard to recover, but nobody had them.
That's where your experience differs from many people I know. You
were the odd one out, it seems.
> The ease of
> recovery went away as soon as they started installing hard drives and
> backups got to be more than a dozen floppy disks. Backup media has
> been struggling to keep up ever since and computers have been hard to
> restore ever since.
And this covers the other part of the story. When the computers
were for the kids, it didn't matter if they went wrong. Nowadays,
people live in fear of losing the data on their hard drives, so
that's another reason for the kids not to programme them.
Along with Microsoft's gradual process of making them less hackable,
e.g. stopping putting GWBASIC on them, or indeed any tool that
made them accessible. They had a revenue stream to protect. It
was unthinkable that any ordinary person should be able to come
up with an alternative to what they were selling.
Dave
> How about a real topic, like what sort of case will they put these
> things in?
If you'd been keeping up with the story on RPi's web site, you would
know that they are planning a clear case for later this year, at no
extra cost.
Clear, so that the kids can see inside.
Dave
Just to clarify, "50% slower" interpreted as "2x slower" or as "1.5x
slower" for ARM11 vs. Cortex-A8 comparison at roughly the same clock
frequency and assuming that both of them have L2 cache?
Unless SIMD is involved, 2x performance difference looks highly
unrealistic to me. And even 1.5x performance advantage expectation is
moderately optimistic for A8 if the code is generated by C compiler.
We are yet to run benchmarks on RasPi, but 1.2GHz sheevaplug (also a
single-issue ARM core) was consistently outperforming 720MHz OMAP3530
board some time ago in my tests by something like 1.2x on average
(naturally on integer code).
I am not very happy about prolonging the life of armv6 either, but
maybe RasPi folks were after "maturity, low level of implementation
risk, and low implementation cost" as advertised on ARM website [1]?
Their only strong point is low price while still keeping decent
price/performance ratio, and that's quite an achievement by itself if
it proves to be sustainable in the long run.
1. http://www.arm.com/products/processors/classic/arm11/arm1176.php.
Consistently Really?
http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-9745-20331-820
Sorry, haven't gone back and retested those devices in a long time, so
the results are little dated... But it really depends on the
workload.. (heck at times, the beagle-c4's (256Mb 720Mhz) doubling up
the Sheevaplug. (512mb 1.2Ghz) ;) )
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
Either one would be a reasonable guess. It all depends on the workload
of course.
> and assuming that both of them have L2 cache?
Very few ARM11 chips have L2 cache. I doubt this is one of them.
> Unless SIMD is involved, 2x performance difference looks highly
> unrealistic to me.
The A8 is superior to ARM11 in a number of ways:
- Dual issue.
- L2 cache.
- Far better branch prediction.
Each of these alone can boost performance by 50% for some workloads.
Of course typical values will be a bit lower, but given the liberties
the RPi people take with benchmarking, I think it's fair to be a bit
generous here.
And then there's NEON.
> And even 1.5x performance advantage expectation is moderately
> optimistic for A8 if the code is generated by C compiler.
What generated the code is irrelevant. The compiler is equally good/bad
whatever the target core.
> We are yet to run benchmarks on RasPi, but 1.2GHz sheevaplug (also a
> single-issue ARM core) was consistently outperforming 720MHz OMAP3530
> board some time ago in my tests by something like 1.2x on average
> (naturally on integer code).
Clock for clock, that's a 39% advantage for the OMAP3.
--
Måns Rullgård
ma...@mansr.com
The ZX80 was of its time. The Raspberry Pi is of its time. They
are both attempting to address similar people, by providing a low
cost, accessible computer, with minimal adverse consequences if
someone someone breaks it by software or hardware means.
Dave
I would not give phoronix much credibility after their recent
pandaboard benchmarking stunts :)
And some oddities show up even in your results. For example, take a
closer look at beagle-c2-squeeze vs. beagle-c4-squeeze. Even though
supposedly running the same software and using the same version of
gcc, the performance differences are a bit too extreme in some tests
(Sudokut). And it did not even seem like you were running the hardware
at the expected clock frequencies (600MHz vs. 720MHz), because CPU
dependent tests such as OpenSSL seem to demonstrate more like 500/720
ratio.
> Sorry, haven't gone back and retested those devices in a long time, so
> the results are little dated... But it really depends on the
> workload.. (heck at times, the beagle-c4's (256Mb 720Mhz) doubling up
> the Sheevaplug. (512mb 1.2Ghz) ;) )
Before you get too excited, make sure that it was not a floating point
heavy test, there are lots of these in the phoronix test suite. Unlike
raspi and beagle, sheevaplug does not have a hardware FPU and can't
show impressive results there.
Seems like this is one of them, but not sure about the L2 cache size:
https://github.com/raspberrypi/linux/commit/2fe771a79d07fee48af401711c8b5e80e8623610
>> Unless SIMD is involved, 2x performance difference looks highly
>> unrealistic to me.
>
> The A8 is superior to ARM11 in a number of ways:
>
> - Dual issue.
> - L2 cache.
> - Far better branch prediction.
And roughly twice heavier branch misprediction penalties. Which can
potentially show up on some workloads.
> Each of these alone can boost performance by 50% for some workloads.
> Of course typical values will be a bit lower, but given the liberties
> the RPi people take with benchmarking, I think it's fair to be a bit
> generous here.
>
> And then there's NEON.
And there are also double precision floating point workloads, where
Cortex-A8 performs extremely bad even compared to ARM11.
It's 128K according to:
http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> Quoting rickman <gnu...@gmail.com>:
>
>> Ok Dave,
>>
>> You win. The lack of interest in science and technology today is
>> directly due to the fact that we no longer have the ZX80 in our
>> homes.
>>
>> Long live the ZX80!
>
> The ZX80 was of its time. The Raspberry Pi is of its time. They
> are both attempting to address similar people, by providing a low
> cost, accessible computer,
Requiring an NDA to get anything resembling documentation is not my idea
of accessible.
--
Måns Rullgård
ma...@mansr.com
Oh, I would like access to much more documentation, too. But that
still doesn't prevent the RPi from being sufficiently accessible
to its intended audience. There is (at least) one OS to run on it
from day 1, with more to follow.
Dave
> 2012/3/12 Måns Rullgård <ma...@mansr.com>:
>> Siarhei Siamashka <siarhei....@gmail.com> writes:
>>
>>> Unless SIMD is involved, 2x performance difference looks highly
>>> unrealistic to me.
>>
>> The A8 is superior to ARM11 in a number of ways:
>>
>> - Dual issue.
>> - L2 cache.
>> - Far better branch prediction.
>
> And roughly twice heavier branch misprediction penalties. Which can
> potentially show up on some workloads.
The A8 branch prediction should have much more than twice the hit rate
with a 4x larger branch target buffer and more than 2x larger return
stack. A global history buffer also allows the A8 to predict repeating
patterns of branches, something ARM11 cannot do. Only truly
unpredictable branches would perform worse, and these are very rare.
Moreover, the A8 branch predictor does not need to be flushed on context
switches as is the case for ARM11.
>> Each of these alone can boost performance by 50% for some workloads.
>> Of course typical values will be a bit lower, but given the liberties
>> the RPi people take with benchmarking, I think it's fair to be a bit
>> generous here.
>>
>> And then there's NEON.
>
> And there are also double precision floating point workloads, where
> Cortex-A8 performs extremely bad even compared to ARM11.
I am intentionally ignoring those.
--
Måns Rullgård
ma...@mansr.com
This suggests that there is a 128K cache shared with the GPU. This
sharing means two things: 1) the effective size is smaller, and 2)
arbitration logic probably adds some latency. Compared to the
integrated 256K (typical) L2 cache of A8, this seems rather poor.
--
Måns Rullgård
ma...@mansr.com
So it's the fear of "breaking the family PC" that is holding back
teaching kids how to program? Why does learning to program involve
breaking anything? Can't one learn to program in an environment
that prevents one from doing that?
Even back in the C64/BBC Micro days, most of the programming would
have been in BASIC and the worst you could do was to create an
endless loop.
> The other problem is the lack of teachers who can programme and
> teach programming. That's not so easy to solve.
right
> Dave
>
On 03/10/2012 10:00 PM, Dave Higton wrote:
In message<4F5BB9A2.6090002@gmail.com>
Vladimir Pantelic<vlad...@gmail.com> wrote:
Dave
--
To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard+unsubscribe@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq
You can call it stunts, but on the initial shipments of a brand new
board (to both developers and users) with a newbie arm user behind the
wheel, the results are expected.. I'd argue if the same newbie where
to do the exact thing today, the results would look different...
> And some oddities show up even in your results. For example, take a
> closer look at beagle-c2-squeeze vs. beagle-c4-squeeze. Even though
> supposedly running the same software and using the same version of
> gcc, the performance differences are a bit too extreme in some tests
> (Sudokut). And it did not even seem like you were running the hardware
> at the expected clock frequencies (600MHz vs. 720MHz), because CPU
> dependent tests such as OpenSSL seem to demonstrate more like 500/720
> ratio.
Correct, the C2 was either operating at 500MHz or 600MHz*, with the
fast usb-sata rootfs drive operating behind the known buggy MUSB based
USB controller vs the TI EHCI USB controller on the C4 beagle..
*at some point this was patched/fixed to be default, just can't remember when...
>> Sorry, haven't gone back and retested those devices in a long time, so
>> the results are little dated... But it really depends on the
>> workload.. (heck at times, the beagle-c4's (256Mb 720Mhz) doubling up
>> the Sheevaplug. (512mb 1.2Ghz) ;) )
>
> Before you get too excited, make sure that it was not a floating point
> heavy test, there are lots of these in the phoronix test suite. Unlike
> raspi and beagle, sheevaplug does not have a hardware FPU and can't
> show impressive results there.
True, and i still have a raspi on pre-order.. ;)
> Today, with PCs I wouldn't know how to start teaching kids how to
> program. On a PC it is really boring or way to complicated for someone
> being 10 years old. I then started to experiment a bit with the Arduino
> and kids love it. You have some basic resources from where you can copy,
> you connect a servo and that thing moves. It is something none of their
> friends has. It is cooler than whichever game on a gaming console.
Correct, yet in order to play with the arduino, you need a PC, out of
the box the arduino will do nothing. The very same PC that raspberrypi
claims either does not exist or parents are afraid their kids will
break...
> My guess is that the Raspberry foundation will strive to create exactly
> this kind of community. A meeting place where you can find relevant
> information to get you started and explore (and no links to
> kernel.org/documentation <http://kernel.org/documentation> :-)
let's hope so.
BASIC? if that is what is missing, install an AppleII or C64 emulator
on your PC, phone or tablet. It's cheap, accessible and unbrickable
and exactly the same 80's tech that allegedly made students so much
better at programming back then.
> In the 1980s, most serious computer magazines included a section each
> month with listings that you could type in that would perform an
> interesting task - whether it be converting between celcius and
> fahrenheit, calculating mortgage repayments, or a game such as snakes or
> asteroids. And because most computer owners had the software they
> needed to try the program, some did. If tings went wrong, you could
> simply reboot the computer and be back to a sane environment. That is
the very same tasks you could do today e.g. in a browser based
programming environment, substitute BASIC for Javascript. And getting
the browser to crash would actually be a challenge :)
Oh, I would like access to much more documentation, too. But that
still doesn't prevent the RPi from being sufficiently accessible
to its intended audience. There is (at least) one OS to run on it
from day 1, with more to follow.