Which 64 bit OS is recommended for the Pi3, for I cannot locate such on the wiki?
Perhaps NOOBS runs in the 64bit manner but in the AArch32 option?
Which 64 bit OS is recommended for the Pi3, for I cannot locate such on the wiki?
Perhaps NOOBS runs in the 64bit manner but in the AArch32 option?
On Wed, 25 Apr 2018 16:28:17 +0100, Gareth's Downstairs Computer declaimed the following:
Since the foundation provides one image for all R-Pi versions, they are (to my understanding) still 32-bit OS versions on all devices.
-- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
Debian does have an arm64 image. It does install and run.
This seems to work OK for me:
Fedora 28 has approved work on AArch64, but apparently only for 'server' builds, not other 'spins'
I certainly can't see anything downloadable ...
No, nothing from the foundation, they only do 32 bit for full compatibility with older models. SuSE Linux has a 64 bit version for the Pi, and that?s the one Eben mentioned in the Q&A video they posted on the blog, so you could say that that is the recommended OS.
There are none officially recommended at the Pi site.
Here is one from openSUSE:
I installed the Leap 42.3 and it runs fine on the Pi 3, but I recently bought a Pi 3b+, and it doesn't start up there! And here is one from Gentoo:
That works fine on the Pi 3b+ too!
And finally you should find a fitting FreeBSD one here:
HTH!
-- aen
[snip]
An arm64 image can be found at
Last I read, the Pi3+ is not yet supported in FreeBSD.
hth,
bob prohaska
AN> > Why do you want a 64 bit build? AN> Because 64 bit are twice as good as 32 bit?
Except when talking about compatibility, then it's only 1/2 as good as
32-bits. In fact, why do you suppose they have the option to add 32-bit architecture onto 64-bit debian linux's apt-get? So you can install the 32-bit applications that wouldn't run otherwise....John H. Guillory Phone: 601-754-9233 Fidonet: 1:396/60.0@fidonet E-Mail: snipped-for-privacy@yahoo.com Dovenet: vert/mainline BBS: kingcoder.net Black5: time/mainline Amateur Radio Net: time/mainline
CG> >> limitations, the 8051 and 6303 being the worst in CG> >> my experience! CG> Worse than 8086/8? Must have been bad... If it's anything like the 6502, no DIV instrunction or MUL instruction, I can't for the life of me figure out how in the world I ever wrote assembly language programs on the commodore! Yet, for some reason I was able to write my own interrupt vector request routine that allowed me to have 3-4 split borders and background colors on the screen at the same time.
John H. Guillory Phone: 601-754-9233 Fidonet: 1:396/60.0@fidonet E-Mail: snipped-for-privacy@yahoo.com Dovenet: vert/mainline BBS: kingcoder.net Black5: time/mainline Amateur Radio Net: time/mainline
Why do you want a 64 bit build?
-- Andrew Gabriel [email address is not usable -- followup in the newsgroup]
Because 64 bit are twice as good as 32 bit?
SCNR
On a sunny day (Fri, 27 Apr 2018 11:46:30 +0200) it happened Andreas Neumann wrote in :
Not even in theory, I did some web searching for that question myself, wanted benchmarks.
started reading here:
Things may even slow down.
Because the next language plan is to be 64 bit; its where the future lies.
All variables to be 64 bit.
Definitely a 6dB improvement on the ease of programming. For the first time an architecture exists where no effort need be expended on programming your way around its limitations, the 8051 and 6303 being the worst in my experience!
Yes, but will improve all the time. In some ways like the specification for the processing of GSM mobile communication. ISTR that the needed technology was not around at the time of specifying, but every confidence was that it would appear.
This argument raged when 64 BIT INTEL came out. I read it up extensively. And then went 64bit and never looked back. Graphics processing was a LOT better.
And indeed anything that accesses memory in large chunks is twice as good.
Disk performance and file sizes were slightly worse, that's all.
-- "Anyone who believes that the laws of physics are mere social conventions is invited to try transgressing those conventions from the windows of my apartment. (I live on the twenty-first floor.) " Alan Sokal
Well C takes care of all that, except yupu have to remembert int_32 and int_16 if you want those sizes..
-- "Anyone who believes that the laws of physics are mere social conventions is invited to try transgressing those conventions from the windows of my apartment. (I live on the twenty-first floor.) " Alan Sokal
On a sunny day (Fri, 27 Apr 2018 13:14:06 +0100) it happened The Natural Philosopher wrote in :
Yes, as for the Pi3 the 1 GB memory size limitation may work against it, as mentioned in those links I referenced. And memory access to SDcard is always a bottle neck.
I would appreciate if somebody who nows runs the 32 bit debian and wants to go 64 bit, runs one or more of the many benchmarks available, and again after the upgrade to 64 bit. That will provide a reality check..
As to 32 versus 64, I have some PCs with 32 bit Linux, deliberately, for compatibility reasons at that time and a laptop with 64 bit Linux, but the processors and architecture are completely different (AMD single core, Intel i5) different graphics chips (one on board, one nvidia, laptop has choice between Intel and AMD graphics (had both). So that is comparing apples and oranges for 'graphics speed'.
Run the test, inform us all.
In this case the only likely effect is that compiled executables will be a bit bigger because a 64 bit pointer is 8 bytes compared with 4 for a 32 bit pointer and will run a bit slower because (I think) the 64 bit pointer will need two fetches compared with one for a 32 bit pointer.
And, seeing that a 31 bits is a bigger address space than there is RAM on an RPi3 (4GB address space, 1GB RAM less that used by the GPU and screen buffer), using 64 bit pointers gains you nothing.
-- Martin | martin at Gregorie | gregorie dot org
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.