Raspberry Pi on Raspberry Pi
blog.mythic-beasts.com
blog.mythic-beasts.com
From a software standpoint, imagine the possibilities of millions of people walking around with devices that are as powerful as the compute resources Google had in 1998. It's realizations such as this that make me excited
What I love about the Raspberry Pi is the possibilities it brings at affordable prices. For example, students learning about how distributed systems work can build a cluster of Raspberry Pis for just a few hundred dollars. They have access to the same open source software that major tech companies use for their infrastructure, like Linux and various distributed software projects such as Apache Spark.
In an age where sometimes I'm cynical about the direction of tech and our industry, it's realizations such as this and product announcements like this new Raspberry Pi that make me remember why I love computing.
Yes. A slight correction, though: 100 GFLOPS per CPU core.
Some new server Xeons can do 64 single precision FLOPS per cycle per core. Most other modern x86 CPUs can do up to 32 SP FLOPS per cycle per core.
AFAIK, RPi4's Cortex A72 will have to do with just 8 FLOPS/cycle/core. Similar to original Intel Core, Nehalem and Penryn. FPU wise (and probably otherwise as well), per clock cycle, RPi4 is not far from the famous Core 2 Quad Q6600. :-)
Or one Cortex A72 core @1.5 GHz has comparable floating point performance as a hypothetical Pentium 4 at 6 GHz.
(These figures count one FPU multiply-add as two FLOPS, but that seems to be industry standard way...)
It has to support and parse a billion more formats. Including the fact that MS word file formats are in some cases literal dumps from word's memory (iirc).
Rendering things properly is also a difficult problem to solve. Look how difficult it has been for much of the 21st century, to get a webpage uniform across all major browsers, and then realised that you not only have to display the same across all major browsers, but also be 30 years backwards compatible.
While that is an additional load if you deal with those formats, the root of things like startup and runtime bloat lie elsewhere.
> Rendering things properly
These should not affect startup performance though.
But even with LibreOffice's clunkiness, I still use it at home. While I am partial to Apple Keynote for presentations, I prefer LibreOffice Writer and LibreOffice Calc to Apple Pages and Apple Numbers, respectively. And whenever I'm on a Linux or FreeBSD machine, LibreOffice is available for me to use, while iWork and Microsoft Office are not options.
Try making the same claim using a thrift store laptop for < $200 which is all the computing power a whole lot of people have access to (if any). Yes computing is fine (and a little better than 20 years ago) for software made and used by wealthy people. You have to slide down the curve a bit to discover the frustration with everything being terribly hungry for ever-increasing resources.
Of course if you upgrade to a top quartile computer every few years you're going to have a relatively good time.
$200 computers obey Moore's law too.
https://www.theregister.co.uk/2019/06/24/microsoft_round_up/
Since i already have one i might want to use it for other things. The reason computers are slow is this sort of "since you already have that resource, might as well use it" thinking - which makes sense if only one program does it, but if almost all programs do it then it breaks down quickly.
But the underlying problem here is higher resolution screens than needed. Most people don't actually need a 4k display. Sometimes, they can't really see small print that easily anyway and what they need is UI's designed with large print in mind.
FWIW yeah, i agree that most people do not really need 4K displays but that is another matter.
Which is exactly why you want to save the GPU for what it does best – drawing pixels.
> and pretty much every single GPU accelerated text drawing operation i've seen allocates permanent GPU resources (textures mainly).
Makes sense as a concern, and it's not something I've looked into. (I don't use alacritty.) On the other hand, how much memory are we actually talking about? On my system (total screen resolution 2880x1800), a typical terminal glyph has a roughly 14x16 bounding box; let's bump that up to 20x20 to account for padding. Stored as 8-bit RGBA, that would take 1600 bytes. An atlas of "hundreds" of glyphs would then be expected to take up on the order of hundreds of KB... which seems pretty negligible? A larger font, multiple atlases, or more characters per atlas would require more memory, but I still don't see how you get to an amount worth worrying about. I could be missing something.
It seems the increase in utility we've got from being able to use teraflops of massively parallel GPU with Gigabytes of ram available - doesn't exactly match the 6 orders of magnitude or so more resource use... "It scrolls soooo smoothly, and you can use the poop emoji in your source code!!!" ;-)
</old_man type='grumpy'>
Computers feel as slow as ever (which was the topic a few nodes above) despite being much faster in theory not because of a single program but because all (or well, the overwhelming majority) the programs in your computer abuse resources - even if a little. It is death from a thousand little abuses.
In my experience GPU rendering does provide buttery smooth scrolling and output for tons and tons of text. Now you can `cat` that 1 GiB log file that much faster!
I still prefer libvte-based terminals though.
And the main reason was to save memory and computing power. And even today, a GPU is designed to do graphics, that's in the name. Text rendering is graphics, so why not use it? It is more efficient than a CPU, and the reason it isn't done more isn't because one needs huge GPUs, but rather because it is more difficult for the devs.
Because CPUs today are powerhouses and text is a rather simple task, devs take the easy way and do text rendering on the CPU. But when you throw Unicode, anti-aliasing and high resolution into the mix, things that modern terminals should support, it stops being so simple, and the GPU regains value.
"Using the GPU for rendering enables optimizations that simply aren't possible without it"
Though let's be honest here, if the OS were designed properly then the terminal application would not need to worry if there is a GPU or not. The graphics libraries and drivers should take care of all that.
i've always wondered what would happen to this sentiment if something like V8, Node, Electron or NW.js was already part of the [Windows, Linux, macOS] platforms and didn't need to be distributed with every app.
[0] For lack of a better term.
The internet might have been a mistake.
This is unfortunate, its something I use a lot. Guess I'll wait to get a Pi4.
The Pi is great for things like DIY HTPC's, kiosk displays, IoT controllers, education, etc... but using it how this service is using it seems wrong--or misused--for some reason. I feel like an offensive stance is being taken against the Pi 4 for not being client production ready, when it seems like the foundation's attitude is if you want to go full client production, use the compute module.
More seriously, perf per watt is king in datacenters, no matter what the source.
https://www.theregister.co.uk/Print/2012/05/03/unsung_heroes...
I found it here:
> The 1176JZ(F)-S is the same CPU used in the original iPhone,[23] although at a higher clock rate, and mated with a much faster GPU.
https://en.wikipedia.org/wiki/Raspberry_Pi#Processor
that said, you could probably make statements like "ARM is used in spaceships" or "Broadcom is used in switching hardware" too
Note that the other Pis did just fine running typical workloads, as long as I kept the overall deployment memory constraints in check.
Can I buy the chips? Can I get the technical documentation?
If I can't build my own RPi in volume, this is STILL a problem.
For who?
If I want to deliver a quarter million of these I can't.
Remember that boards like the RPi are either loss leaders for the SoC vendor, or a way to offload excess capacity. Their pricing does not necessarily reflect what an actual customer for an actual SBC product will pay, regardless of scale.
A competitor who doesn't worry about such details will have an advantage in many markets.
At one time, the denizens of a site called "Hacker News" might have been expected to grasp this idea intuitively.
The post they responded to said that the Raspberry Pi is unsuitable to all "real products" because they can't buy 250k of them - you might actually be arguing against their definition of "real product"? rhinoceraptor merely pointed out that that isn't the goal of the Raspberry Pi, and one thus should use something else if it doesn't fit the requirements. If that's your situation, your competitors will have the same problem. If it isn't, then "use something else" doesn't apply to you.
The whole point of Raspberry Pi is to provide a convenient SBC for people who don't have those engineering resources. If you're somewhere in the middle, there's the Compute Module.
Complaining about this is akin to complaining that your VW bus can't tow a house.
They are used in industry already (digital signage particularly).
This shouldn't disqualify the RPi, in my opinion. We're moving incrementally towards a world of open firmware and open hardware from a totally closed world. It feels like we're making forward progress. We shouldn't punish incremental steps on this path, nor should we stop asking for more open hardware.
That's a pretty big difference.
All this means that people serious about a product have to avoid a RaspberryPi, and this is terribly unfortunate because it has such a wonderful community.
This feels like a dramatically different category of thing than what the Pi is, to the point where comparison starts to get less meaningful.
But frankly I'm not sure the RPi folks should give a damn. They're selling whole computers. That they don't fit into someone else's product pipeline is unsurprising.
It's like complaining you can't turn a MacBook air into a blade. It's true, but it's also a bit wrong to expect you could have in the first place.
For similar systems in quantity, a guy I know used toradex
But as others have said it is not a problem as far as the Raspberry Pi foundation is concerned because their primary mission isn't to produce a board for use in commercial products.