Submitted via IRC for TheMightyBuzzard
The results are in: The Raspberry Pi 3 is the most desired maker SBC by a 4-to-1 margin. In other trends: x86 SBCs and Linux/Arduino hybrids get a boost.
More than ever, it's a Raspberry Pi world, and other Linux hacker boards are just living in it. Our 2017 hacker board survey gives the Raspberry Pi 3 a total of 2,583 votes — four times the number of the second-ranked board, the Raspberry Pi Zero W.
[...] Note that by "votes" we are referring to Borda rankings that combine 1st, 2nd, and 3rd choice rankings [...]
So, which if any credit-card-sized computers are you lot playing around with?
Source: http://linuxgizmos.com/2017-hacker-board-survey-raspberry-pi-still-rules-but-x86-sbcs-make-gains/
This discussion has been archived.
No new comments can be posted.
2017 Hacker Board Survey: Raspberry Pi Still Rules, but x86 SBCs Make Gains
|
Log In/Create an Account
| Top
| 60 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
(1)
(Score: 4, Informative) by takyon on Thursday June 22 2017, @01:39PM
x86 SBCs you say? Aaaaahhhhhhh! [soylentnews.org]
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 2) by richtopia on Thursday June 22 2017, @01:47PM (37 children)
I did quite a bit of research on the sub $100 SBC about a year ago. For most applications the Raspberry Pi is the correct choice, purely because the level of community support is outstanding. This is particularly important for applications using the io pins or driving hardware.
For my personal webserver, I am using an ODROID-C2. We actually replaced a Raspberry Pi 3 in a user kiosk running a Java applet and the UI went from painfully slow to modern web interface. ODROID also has been making single board computers longer than the Raspberry Pi has been around and probably has the second largest following after the Raspberry Pi community.
(Score: 2) by cafebabe on Thursday June 22 2017, @02:07PM (33 children)
The general conclusion among friends is that a Raspberry Pi is a cheap pile of junk but there are millions of them and millions of people know how to use them [soylentnews.org].
1702845791×2
(Score: 2) by rufty on Thursday June 22 2017, @03:05PM (1 child)
Going the other way, the BeagleBone [beagleboard.org] is quite nicely designed, especially for hard realtime IO, eg, MachineKit [machinekit.io], but the community is much smaller than the Pi's, so sometimes you're just on your own.
(Score: 2) by LoRdTAW on Thursday June 22 2017, @03:47PM
Machine kit is really interesting. It's a fork of Linux EMC with a broader application than just CNC motion. They are moving the PLC/PAC tasks to the RT core as well as enabling cores to be dedicated to RT tasks. E.g. for a quad core system you can dedicate one core for motion, one core for RT IO (EtherCAT/Profinet/CANopen, etc.) and the other two cores for non RT stuff like HMI and other OS userspace stuff (insert IoT, m2m, manufacturing 4.0 buzzwords here).
That's something I've been waiting for to possibly bring real competition to the Automation market to compete with or complement systems like Beckhoff (great hardware, but a wintel whore), Advantech, Delta, Aerotech (another great company but wintel whore), and others. If they can do real-time I/O and CiA 402 over CANopen or EtherCAT then they have my full attention.
(Score: 3, Interesting) by LoRdTAW on Thursday June 22 2017, @03:12PM (6 children)
The biggest drawback in the lack of a decent amount of PWM and analog I/O. All of that requires yet another board and more protocol/library overhead. Plus the fact that USB is the only high speed I/O it has which is also shared with the USB Ethernet chip.
The ODROID-C2 is an improvement with its hardware gigabit MAC, 2GB DDR and two analog inputs. But it still lacks enough analog and PWM. I'd love to see a board that really caters to the GPIO side of things and brings more Analog, PWM, CAN and serial busses to the GPIO. Maybe an extra GPIO header.
The OpenRex is a great board but it was close to $200 and the i.MX6 is getting really long in the tooth. Maybe one day we'll have a proper sub $50 board with proper GPIO, Ethernet, Wifi/BT and plenty of CPU/RAM.
(Score: 2) by DannyB on Thursday June 22 2017, @04:41PM (3 children)
Can't you have Pi / BeagleBone / etc that speaks I2C to a few slave Arduinos that have lots of PWM and analog I/O. That way you can have high level logic on the Pi, and low level control on the Arduinos.
Police can legally stop you for having too much tent on your window.
(Score: 2) by LoRdTAW on Thursday June 22 2017, @07:36PM (2 children)
You certainly can. But that increases the part count and complicates things. I'd prefer that the I/O be part of the SoC to keep things simple. I'd like to see at least 6-8 ADC inputs @ 12 bits minimum along with 4+ 16 bit PWM outputs. Then give me a simple interface to them via /dev/gpio or something.
(Score: 0) by Anonymous Coward on Saturday June 24 2017, @05:44AM (1 child)
The BBB already meets your requirements. It has seven 12-bit ADCs and eight 16-bit PWMs. All are easy to use from userspace.
(Score: 2) by LoRdTAW on Saturday June 24 2017, @12:39PM
You know, I have had a lot of problem with the BBB hardware. Had two boards died on me, both from eMMC failures.
(Score: 2) by tonyPick on Friday June 23 2017, @01:28PM (1 child)
How so?? It's a Quad GHz Arm9, with real GigE, Sata and PCIe, available off the shelf in a bunch of form factors [boundarydevices.com], or with the Rex open designs [imx6rex.com] and with good quality public datasheets and current support
Sure it's a $200-ish board, but ISTM the feature set is pretty competitive for that price point; The processor isn't exactly a slouch and five years old isn't archaic for an embedded part.
(Score: 2) by LoRdTAW on Friday June 23 2017, @05:11PM
I got a little mixed up. For some reason I was thinking it was Arm V6 like the Pi B+. Turns out I was thinking of the i.MX3x series which is Arm V6.
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @04:04PM (8 children)
Haven't had one of my raspi's fail yet, but the sdcard interface was questionable, especially when I was still running r/w.
Wishlist items are a real gigabit network interface, and a better interface to (external) storage.
(Score: 2) by kaszz on Thursday June 22 2017, @05:01PM (6 children)
What is your review of the Raspberry-Pi SDcard interface? is it only R/W mode that screws up? and how?
Any difference in reliability between models?
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @06:55PM (5 children)
I got a lot of these:
[14601686.810114] Transfer to device 4 endpoint 0x1 frame 2041 failed - FIQ reported NYET. Data may have been lost.
and when the filesystem was mounted r/w eventually it would become corrupt. This particular machine still gets it in dmesg, but worst case I just reboot the machine. It is either a version 2 or version 3 pi. Its kernel is
Linux xx03 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux
Interestingly, it doesn't happen on a newer kernel. This one is a version 1 pi, and doesn't have those dmesg entries:
Linux xx13 4.4.26+ #915 Thu Oct 20 17:02:14 BST 2016 armv6l GNU/Linux
These machines are semi-embedded, and have in toto been very reliable.
(Score: 2) by frojack on Thursday June 22 2017, @08:39PM (4 children)
Power problem is my bet. I couldn't even get my Pi 3 to mine to run until I got a proper power supply.
No, you are mistaken. I've always had this sig.
(Score: 2) by kaszz on Friday June 23 2017, @04:58PM (3 children)
Pi3 at 6.7 watt isn't that much? considering how much a PC uses up..
(Score: 2) by frojack on Friday June 23 2017, @09:13PM
What I meant to say is that just any random USB power supply is unlikely to be stable given the Pi's variable demands.
No, you are mistaken. I've always had this sig.
(Score: 2) by richtopia on Saturday June 24 2017, @04:39PM (1 child)
I have a dedicated USB power supply zip tied in my networking corner for my rpi server and any other usb devices. Too many usb power supplies or ports on existing devices are not reliable or deliver sufficient power.
Something like this:
https://www.amazon.com/dp/B00OQ19QYA/ref=cm_sw_r_cp_dp_T1_ZtPtzbQRQKZV0 [amazon.com]
(Score: 2) by kaszz on Sunday June 25 2017, @02:21AM
The connector sucks mechanically?
(Score: 3, Insightful) by driverless on Friday June 23 2017, @10:30AM
Which is basically an Odroid...
(Score: 3, Touché) by jimtheowl on Thursday June 22 2017, @04:48PM (7 children)
Is this not simply cattle mentality?
The better the product works as advertised, the less support you will require.
(Score: 1, Insightful) by Anonymous Coward on Thursday June 22 2017, @07:24PM
When you think of the flows of resources that are required for humanity to get through a day, it becomes rather frightening; there is definitely safety in numbers: If there is a humongous number of people engaged with a certain project, then it's a pretty good bet that said project won't evaporate into the ether before you've spent your own resources on it.
(Score: 2) by tibman on Thursday June 22 2017, @07:47PM
It helps because you know the product is making money and less likely to be discontinued.
SN won't survive on lurkers alone. Write comments.
(Score: 3, Interesting) by JoeMerchant on Friday June 23 2017, @02:57AM
There are so many hidden side benefits to cattle mentality:
- product lifetime, run with the herd and your board will be produced in greater numbers for a longer time
- software support, pre-made goodies that you don't have to develop on your own
- developer support, people suss out all the crazy edge cases and quirks and document them
- cost, higher volumes, lower prices
- delivery times, more in stock, less waiting
- accessories
But, yeah, if you got something that works better and/or costs less, sure, go for it. Problem is: Pi is so close to zero cost that it's almost impossible to beat the above on price, and so the only rational reason to go away from Pi is if you need more power - and the Pi3 is so freaking powerful compared to anything you might have bought 10 years ago, you have to need heavy graphics or supercomputing to have a good reason to go upmarket.
🌻🌻 [google.com]
(Score: 3, Interesting) by TheRaven on Friday June 23 2017, @09:20AM (1 child)
sudo mod me up
(Score: 2) by jimtheowl on Friday June 23 2017, @02:29PM
It doesn't have to be part of the biggest 'herd' to be the better choice for a given project.
(Score: 3, Informative) by cafebabe on Friday June 23 2017, @02:51PM
This is not the mentality of, for example, using Windows because it is "supported". A minority of Raspberry Pis will still be available in 10 or 20 years. For a similar scenario, the Nokia 3210, released in 1999 [wikipedia.org], is still widely available [ebay.com]&\160;- and that isn't because Nokia (Microsoft) offers good support.
In 20 years, when an embedded system stops working (and the company which made it ceased trading 10 years before), when a junior technician opens the box and blows away the dust, the junior technician can ask the senior technician "What's a Raspberry Pi?" and the senior technician can answer "Oh God! I thought I'd seen the last of those!" which is one step better than "We're completely screwed!" but, admittedly, not by much. (And, unlike systems deployed with the Feb 2016 version of Raspian, current deployments might handle the 2038 problem [wikipedia.org].)
Paradoxically, by envisioning such future-proofing, this scenario is less likely to happen. Mainstream components make customers more confident. Products have higher re-sale value. Confident customers keep a business viable. Viable business is able to offer long-term support.
1702845791×2
(Score: 0) by Anonymous Coward on Saturday July 01 2017, @12:30PM
Because the support is usually community-based, and 99.9%* of people just do their own thing with it and don't contribute back to the community, which is fine, but doesn't leave a whole lot of people to get help from, which considering the ones providing help are only doing it occasionally in their spare time, having a user-base of millions to start with really helps.
*Yes, I did pull this number out of my arse, but it feels right. If you have a better number based on evidence, please provide it.
(Score: 2) by moondrake on Thursday June 22 2017, @04:59PM (4 children)
Interesting journal entry...
But now I am curious, what would be a good choice for an embedded project that needs more than a microcontroller?
(Score: 2) by LoRdTAW on Thursday June 22 2017, @07:39PM (1 child)
That depends on the application. You need to know your requirements first, then spec accordingly.
(Score: 2) by moondrake on Friday June 23 2017, @08:09AM
Right. But the criticism of OP is more general. Fundamental design issues with the Pi. So I was on purpose asking for a comparable device, with less problems.
Note that I am not asking for a solution to a personal or work-related project. Though I occasionally play a bit with Arduino's for datalogger projects (I work at an university), I rarely see the need to use something with an OS.
(Score: 2) by cafebabe on Friday June 23 2017, @03:19PM (1 child)
For a minority of cases, a Mac Mini is a good choice. It can be removed from its biscuit tin case and placed in a 19 inch rack with three PCI cards. Reluctantly, an x86 with ECC RAM remains the default choice.
1702845791×2
(Score: 2) by moondrake on Friday June 23 2017, @09:01PM
thanks! Now that is somewhat unexpected...
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @08:19PM
That blog entry is a year old, and for some reason they were trying to use Rasbian, and probably with a cheap SD card.
I've been running Fedora 24 (custom: standard ARM image but with full hardware support added) with a Sandisk Extreme Pro SD card.
It controls two (so far) of my lab instruments: frequency counter (Aim TTi TF960 - hacked to change VendorID & DeviceId to use generic FTDI driver), time standard (Trimble Tunderbolt-E GPS disciplined oscillator) monitored with Lady Heather utility.
I spun my own Fedora 25, as it too lacks hardware support for the RPi. I use it on two other RPi that I own.
I also wrote two shell scripts to update and install RPi hardware support from the official repositories (WiFi and Bluetooth support comes from a 3rd-party repo that only a determined RPI hacker would discover).
(Score: 3, Informative) by driverless on Friday June 23 2017, @09:53AM
+1. Awful hardware design, but a ton of support. Like the OP, my favourite low-cost embedded device is an Odroid, which is sort of like a Pi with the hardware done right. The downside is that there's a lot less support there.
(Score: 2) by KiloByte on Thursday June 22 2017, @02:28PM
Odroid for speed, Pine64 for doing the work done cheapest, yet still more powerful than RasPi... I see no reason to choose that.
Ceterum censeo systemd esse delendam.
(Score: 2) by frojack on Thursday June 22 2017, @08:14PM (1 child)
If starting over, would you go with that same model or would you opt for the ODROID-XU4?
It seems you were looking for a somewhat traditional computer rather than a project board, and it seems the XU$ is aimed more at that market, with better USB, Ethernet, and memory options (to say nothing of being faster, and only slightly more expensive.
No, you are mistaken. I've always had this sig.
(Score: 2) by richtopia on Saturday June 24 2017, @04:58PM
Perhaps, especially now that the XU4 is discounted. The biggest difference between the two of them in my mind is USB 3.0 support, so if you are looking for a file storage server it is a must. Otherwise the memory is similar and the CPU between the two models is debatable which is faster (different generations, clockspeeds, and number of cores really depends on your application).
I probably would still go with the C2 because I do like the lower power requirements and passive cooling. If ODROID added a USB 3.0 controller to the board it would be an easy choice, but that would increase the cost and defeat the C2's market niche (there is a thread on the ODROID forums about that).
Last recommendation: check out DietPi for your operating system needs no matter the board you choose (they even rate all the boards they support, their favourite is the C2). I dislike how they run by default as root but for many home projects it is acceptable: http://dietpi.com/ [dietpi.com]
(Score: 3, Interesting) by fishybell on Thursday June 22 2017, @03:19PM (3 children)
For me, it's all about the ESP8266 ESP-12S [adafruit.com].
It's got built-in wifi, it's (mostly) arduino compatible, its manufacturer [espressif.com] provides two different firmwares: one bare metal, and one running an RTOS.
(Score: 2) by jdccdevel on Thursday June 22 2017, @05:27PM
Does the ESP-12S have a built in filtering voltage regulator and resistors to keep the thing stable?
I'm using a ESP-01 module (uses the same chip) in a project and I'm having a heck of a time getting it to run with any sort of stability. The majority of the information out there doesn't talk about the supporting circuitry (pull down resistors, power smoothing caps, etc) that I needed to use to get it to run even the most basic sketches. (The chip is apparently really sensitive to floating GPIO Pins and power fluctuations.) I ended up scouring the documentation for a couple of days to find out WTF was going on. (Wifi network scanning is particularly unstable. I can't get the thing to run wifi scans for more than a minute without restarting.) I'm waiting on some small caps to see if they finally fix the last of my stability issues.
Apparently the ESP-01 module is one of the trickier ones to work with because the board is so minimalistic. This is the first time I've used a ESP8266 for anything though, so baptism by fire I guess. That said, I would recommend buying a ESP8266 module without at least some power filtering built in.
There's also the ESP-32 [espressif.com] based boards from the same manufacturer. Dual core, built-in Wifi/Bluetooth, 12 Analog inputs, SD card support and many other goodies. It looks to be targeting the market between the Arduino and something like a Raspberry Pi.
(Score: 2) by DeathMonkey on Thursday June 22 2017, @05:44PM
Yeah, what's going on with the ESPs these days is amazing!
However, they aren't single-board-computers so I don't think they're included in the survey.
(Score: 2) by TheGratefulNet on Thursday June 22 2017, @06:36PM
wemos d1 mini (and clones) for the win.
"It is now safe to switch off your computer."
(Score: 3, Informative) by lx on Thursday June 22 2017, @03:28PM
Here is the non-thumbnail version. [linuxgizmos.com]
(Score: 3, Insightful) by kaszz on Thursday June 22 2017, @04:29PM (3 children)
Let's get rid of the x86 encumbrance and go for MIPS and ARM as they are cheaper and performs more instructions per unit of energy. Besides the capital of trust for Intel is gone.
The Raspberry-Pi product line however have some drawbacks:
* Doesn't make use of a internal high speed bus for Ethernet, WiFi etc.
* Too expensive for use a controller nowadays but too weak for serious processing too.
* Inability to go down in deep sleep mode. Instead it will draw 100-200 mA no matter what. Needs external circuit to fix this.
(Score: 2) by TheGratefulNet on Thursday June 22 2017, @04:49PM (2 children)
no architecture-defined power button. stupid stupid stupid! after all these years, not even a tactile button on the board to act as a graceful shutdown trigger.
elephant-in-the-room bug (usb ethernet) still sucks, by design.
connector arrangement is still not embed-friendly (all over the place, on all 4 edges of the board).
after all these years, still no sata ports, either.
I have a bunch of pi's at home and we use them at work, but I really don't love this platform. it has so many flaws. only good thing is that so many people use it, it has good software support.
"It is now safe to switch off your computer."
(Score: 2) by LoRdTAW on Thursday June 22 2017, @07:54PM (1 child)
The Pi SoC sucks but everything you listed is addressed on other boards. The pi will never get any better unless there is a major change in the SoC design which I doubt will happen due to cost (PCIe, SATA, GbE MAC, etc). Besides, SATA is on its way out. Better to stick with PCIe. That has room to grow at least and you can add whatever peripheral you want.
(Score: 2) by kaszz on Friday June 23 2017, @01:54AM
Other boards may have these things. But they cost significantly more..
And the documentation and support simply isn't the same.
(Score: 3, Funny) by DannyB on Thursday June 22 2017, @04:49PM (3 children)
Task:
To blink an LED.
A blinking LED is required on a control panel to indicate a warning condition.
Hardware engineer:
Easy, I'll use a 555 chip, a few resistors and a capacitor.
Done. Did I win a prize?
DIY Maker:
Easy. I'll use an Arduino with the blink sketch and a resistor.
Done. I have more billable hours than the first guy.
Senior Software Engineer:
You guys have it all wrong.
Such a system would never be flexible enough for a real application where a blinking LED indicator is required.
Consider the inflexibility of the 555 approach. What if the marketing people change the requirements from a simple on/off blink to a different blink pattern. The simplest example would be the double blink.
Blink, Blink, long pause, Blink, Blink, etc.
Then consider the lack of sophistication that the Arduino has. With a simple microcontroller you can't have a web interface to configure the LED's blink rate. You would have to re flash the firmware.
With a more sophisticated controller, like a Raspberry PI, or even better, a Beagle Bone, the system could automatically check on the internet for software updates; and automatically download and apply them. For security, downloads could be signed with 4096 bit keys using private certificates from the manufacturer. (This also ensures ongoing contracts since no other vendor would have the private certificates.)
Higher end boards provide more flexibility. The LED controller could have it's own WiFI connection to not burden the rest of the system to provide its internet access.
Since the specification is a blinking LED for a warning condition. Extreme reliability is required. Therefore we might consider abandoning Linux for an RTOS running on a Raspberry Pi.
Imagine the inflexibility the project would be saddled with if we had used a 555 or an LM3909.
Police can legally stop you for having too much tent on your window.
(Score: 3, Touché) by kaszz on Thursday June 22 2017, @05:03PM
My solution: Buy a pre-made blinking LED. They do exist.
(Score: 2) by LoRdTAW on Thursday June 22 2017, @07:57PM
You have senior software engineer confused with DIY maker.
(Score: 2) by JoeMerchant on Friday June 23 2017, @02:59AM
So, if you need a few lights controlled via network commands, I think the Pi is the way to go.
If the lights just need to blink stupidly in response to a switch closure or something, then, yeah, 555 will do the trick.
🌻🌻 [google.com]
(Score: 2) by kaszz on Friday June 23 2017, @02:02AM (7 children)
What is your opinion on the return on effort to program a 8-bit microcontroller for the benefit of small code size and definitely low power usage vs using a 32-bit microcontroller that nowadays seems to have an equivalent cost. Something on the order of $2 vs $5. The benefit being that you can keep the knowledge and development environment for both small and larger projects. Same source code tricks, compiler, loader, cables, architecture, device setup etc.
Actual MCUs (architectures) can be ATmega, ARM, 8051, MIPS etc.
So if you want to build a network where some nodes will measure temperature, turn light on/off and others will collect small video clips. Would it be better to go full 32-bit or separate into 8-bit for simple nodes and 32-bit for nodes needing some capacity?
(Score: 2) by TheRaven on Friday June 23 2017, @09:22AM (3 children)
sudo mod me up
(Score: 2) by kaszz on Friday June 23 2017, @03:26PM (2 children)
I noticed the cost.. about 45 US$ ;(
Would almost be profitable to DIY..
(Score: 2) by TheRaven on Saturday June 24 2017, @11:55AM (1 child)
sudo mod me up
(Score: 2) by kaszz on Sunday June 25 2017, @02:12AM
Considering the price it's almost a no brainer to compete with these DIP-ARM-prototypes on price and function.
(Score: 2) by cafebabe on Friday June 23 2017, @04:28PM (2 children)
An ARM micro-controller which only executes 16 bit Thumb instructions is a relatively good choice in typical circumstances. However, there are conditions where ARM should be avoided. This is mostly a generic consideration of 8 bit instruction sets, 16 bit instruction sets, 32 bit instructions, larger instruction sets and miscellaneous instruction sets.
An 8 bit instruction set may be close to optimal code density. In a general purpose computer, this minimises RAM (or virtual memory) required for program. However, In a general purpose computer, an 8 bit instruction set provides the least defense against executable code passing through ASCII filters or suchlike. In a device with finite ROM, an 8 bit instruction set provides maximum functionality. A 16 bit instruction set and the same size ROM may attain slightly more than 90% of the code density. Two address instructions, such as MOV, are generally of similar size but 16 bit loop and jump instructions may be larger.
GCC uses a legacy algorithm for register allocation which is a middling choice suitable for a desktop environment. With -fira-region=one, GCC uses all available registers and correctly counts the cost of instruction prefixes when accessing extended registers. [soylentnews.org]
If your code has an unusual quantity of case statements or subroutine calls, an 8 bit instruction set may be the best choice. If your code has sections of heavy computation, a micro-controller which can switch between 16 bit instructions and 32 bit instructions may be the best choice. In typical cases, a 16 bit instruction set is good enough for new projects but may be problematic for legacy projects which already target an 8 bit instruction set.
1702845791×2
(Score: 2) by kaszz on Friday June 23 2017, @04:51PM (1 child)
I'm just thinking that when the minimum clock frequency for ARM is 48 MHz and memory sizes in 128 kB or more. It will not matter much that code density goes down? ie any advantages are nullified by the pure capacity in speed and memory.
(Score: 2) by cafebabe on Friday June 23 2017, @06:11PM
For a micro-controller with 4KB of ROM, code density is very important. For a micro-controller with 64KB ROM, it is probably acceptable to be within 10% of optimal code density. However, as the size of the program increases, processor complexity acts as a magnifier for size and bandwidth. Where energy consumption is of minimal concern, there comes a point where all the crazy 100 million transistor stuff becomes worthwhile. Stuff like speculative execution, object-oriented branch prediction, 144 virtual registers and the associated out-of-order reconciliation hardware. For example, a 4GHz Xeon core with a peak instruction decode of 5 bytes per cycle has a peak execution rate of 20GB/s per core - and many parties with high density legacy code want that pushed further. Back in the land of sanity, PIC, AVR, SuperH, MIPS and ARM are all useful.
1702845791×2