With some of the amazing specs of the Raspberry Pi 4 I wonder if the 4GB ve rsion would be fast enough to replace a desktop PC - just for basic computi ng such as web browsing, word processing, spreadsheets, file handing etc.
I ask because I have just been trying to use Twitter via Chromium on a Rasp berry Pi 2 running Raspbian and Twitter was unusable. Half the tweet could be typed before any characters became visible and clicks within the text wo uld take a while to move the cursor.
So what do you guys think about how fast a 4GB RPi 4 would be in comparison ?
It may well work? but modern web browsing is not "basic computing" any more, but rather among the tougher tasks a machine will be asked to undertake. Having lots more memory will certainly help.
It sounds as if it would be fast enough and has enough connectivity to replace my house server (Dual Athlon with 4GB RAM) if I used a USB3 external drive in place of its SATA internal drive.
However, when the Athlon box dies I'll probably replace it with a miniITX system running something an Intel i5 or i7 chip because I do some development on it and often move binaries between it and a couple of laptops, which both run x64 chips - the convenience of not having to recompile C code as part of that move is the main reason for not using an RPi 4 in this case. That and the fact that all my Intel kit runs under Fedora.
It's much faster then the RPi 2. My initial tests on the 4 GB version suggest it would be fine for routine Web browsing, and for basic word/excel/etc. tasks. Maybe even simple photo editing. In short, everything which many users need, but not "power" users.
Have you made any comparison of compilation speeds, say a decent-sized C programs? For comparison a program I wrote (9000 lines split into 15 source files and 11 header files) takes:
0.730 s on a Lenovo T440 (i5 at 1.9qGHZ, 8Gb RAM) 1.366 s on an AMD dualAthlon at 1.0 GHz, 4 GB RAM)
24.314 s on my RPI2, an early 512MB Pi 1B+ which claims 698 bogoMIPS
The T440 and the dual Athlon box are running Fedora 30 and the RPi is running Raspbian 4.19.42. All three systems were fully updated on Friday.
I'd be most interested to know how its compilation speed compares with the dual Athlon because, if/when that dies, the obvious replacement candidates are an RPi 4 or an i5-equipped mini ITX system.
On Sat, 29 Jun 2019 01:42:01 -0700 (PDT), James Harris declaimed the following:
You would be moving from a 900MHz quad core (presuming you mean RPi 2 Model B) to a 1.5GHz quad core (Rpi 3B is 1.2GHz and RPi 3B+ is 1.4GHz). Since Raspbian is still built as a unified (common to all models) 32-bit OS, the 64-bit cores of the RPi 4 (and RPi 3) may be underutilized -- especially if one is running computationally heavy jobs. The 2B is running
60% of the speed of the 4B.
The main speed up may be that the 4 appears to have true Ethernet on-board, and not a USBEthernet adapter. That means your keyboard/mouse going through USB won't be competing with your network (presuming wired Ethernet -- I'm not sure what impact using a WiFi connection would have).
The other significant change may be in the graphics driver. From what I've read, the 4 is capable of directly poking the graphics processor, while older models have to go through some proprietary library.
Using a USB3 external drive for user data and temp files (eg: mounting /home and /var onto an external drive) might help speed some things up.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
This really surprises (and disappoints) me. The debian base is capable of all sorts of processor optimisations, and the people doing the Pi have the advantage of knowing *exactly* what differences there are between models.
No, I haven't. One compile that I have (NTP) took about 25 minutes on a RasPi-1, down to ~5 minutes on a 3B. I would expect a factor in the order of perhaps two better for a 4 GB RasPi-4. So /maybe/ your compile would come down to "a few seconds", but perhaps not as fast as the dual-Athlon. As I noted, my comments referred to the generic "desktop" as per the thread title.
If you like to send me your program, and if it's not like most C/C++ programs I see which require about a day to get all the required libraries and then don't compile, I'd be happy to check it for you. My address is on the bottom of my home page:
formatting link
The second compile might be quicker if the OS is caching the source files. Oh, and would you mean graphical desktop (which I hardly ever use) or command-line?
I'll pass on this, thanks: like quite a lot of developers I do have a personal support library or two and latish on a warm day like this has been, I'm quite likely to omit stuff I shouldn't.
One thing I forgot to mention is that all the times I quoted were for a second or third compile.
Unsurprisingly, repeated compile times on the T440 and dual Athlon were a factor of 2-3 faster than the first compile. When I've looked in the past 'top' has always made it obvious that this is due to Linux caching files in RAM. I was a little surprised to see that this effect was entirely absent for my Pi - obviously 500MB isn't enough memory to let file caching have any significant effect on compilation speed for non-trivial programs.
On Sat, 29 Jun 2019 19:24:18 +0100, Folderol declaimed the following:
And would have to maintain different downloads/builds confusing neophytes. They already have to create a build different from pure Debian. Debian has ARMEL, ARMHF, and 64-bit. The ARMHF is for devices for v7 ARM architecture and a hardware floating point (VFP3, as I recall) -- but Raspbian isn't the exact same...
formatting link
""" Raspbian - Uses the hard-float version of the "new" ABI (EABI) like Debian armhf but targets v6 rather than v7. Currently tracks Debian jessie and stretch. Primarily but not exclusively targeted at the Raspberry Pi. GNU Triplet: arm-linux-gnueabihf """
ARM v6 has a different...
formatting link
""" VFPv2 An optional extension to the ARM instruction set in the ARMv5TE, ARMv5TEJ and ARMv6 architectures. VFPv2 has 16 64-bit FPU registers.
VFPv3 or VFPv3-D32 Implemented on most Cortex-A8 and A9 ARMv7 processors. It is backwards compatible with VFPv2, except that it cannot trap floating-point exceptions. VFPv3 has 32 64-bit FPU registers as standard, adds VCVT instructions to convert between scalar, float and double, adds immediate mode to VMOV such that constants can be loaded into FPU registers.
VFPv3-D16 As above, but with only 16 64-bit FPU registers. Implemented on Cortex-R4 and R5 processors and the Tegra 2 (Cortex-A9). """
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
The work involved to maintain two concurrent releases (with a lot of customisations) is their main reason apparently, yes, while the vast majority of the install base (the Pis out there) isn't 64 bit compatible. But their main software man also keeps saying: give me one good reason why
64 bit is better than 32. See their blog on the new Buster release. Well, it gets a bit embarrassing with lost optimisations when the current chip is armv8, for crying out loud. He says it doesn't make a difference but I wonder.
Wasn't the drive to 64 bit more about accessing more RAM?
I went 64 bit on my desktops for no good reason. The boards were there. Linux could drive them. Why not? Maybe a bit faster in computationally bound stuff like video processing
Biggest speed up for ME was SSD. Once you have enough RAM that is
Doing compiles out of an SD card disk is pants. Worse than even a hard drive.
I developed my Pi app on a 64 bit intel platform and only when it worked did it get compiled under Pi ARM.
Took ages BUT I assumed that was disk access speeds - I have only the SD card...
--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."
Billy Connolly
remember that writing to a micro SD card is abominably slow. One should probably regard them as EAROM. Cached writes possibly more important than reads when compiling.
My Pi app needs fast scratch space to share between concurrently running proceses (one writes, the other reads). It only has 512MB RAM, so I configured a 1MB RAM drive on it.,
I use my 3B+ as a general desktop machine already, it is noticeably faster than the 3B it replaced, as the small fan in the case stops it thermally throttling. But the one thing that lets it down is the 1GB of memory, as any serious web use causing it to start swapping to the USB attached SSD, and slows down drastically.
4GB of memory in the Pi 4 should transform the experience. Plus the USB3 will allow the SSD to operate at its full speed when needed.
IIRC the article in The Register said its set up to boot from either SD card on a USB3 external storage device, so why bother with an SD card on it since its got two USB3 sockets: just stick an SSD or HDD in one of the USB3 sockets.
Experience with my Athlon box shows that 4GB RAM allows enough disk caching to dramatically speed up both C and Java compilations.
I didn't notice quite such a speed up with an older Lenovo R61i (1.4GHz Core Duo chip and 3GB RAM), so it looks as though disk caching becomes a significant speed-up factor somewhere between 2 and 4 GB RAM.
Agreed. I didn't notice much speed-up, if any, when I moved my Fedora systems from 32bit to 64 bit on the same hardware.
Yep. When my Lenovo R61i's 120 GB HDD died I replaced it with a Sandisk
128GB SSD - mainly because its disk supporting hardware wouldn't accept any disks I could buy (smallest one anywhere was 320GB).
Now disk intensive operations that DON'T involve multiple accesses to the same file, e.g. booting it, backups and system upgrades are much faster than before but repeat compilation speeds and, of course, CPU intensive tasks such as rkhunter scans for binary changes, haven't changed very much at all.
More address space. CPUs with only 32-bit logical addressing can still access more than 4GB physical RAM, but each process is still stuck in
4GB (often less in practice). That?s a problem both for certain lagre applications, and for security improvements like ASLR.
64-bit GPRs are handy for some applications but rarely essential.
For both Intel and ARM the 64-bit instruction sets double the number of architectural GPRs. Particularly on Intel where the 32-bit situation is pretty poor, that?s a big improvement for anyone writing in assembler.
The difference is not trivial if you are doing complex and high resolution video and/or audio generation and processing. You are likely to be using long ints and doubles in tight loops - and I'm not talking about just playi ng MP3s.
On top of this I think there are extra features in the BCM2711 that the Pi
4 software doesn't use in order to maintain compatibility.
I don't buy the argument about confusing newbies with different OS versions - especially when these users are most likely to get the thing as a complete package
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.