Re: Raspberry Pi
Geez, I remember 8-bit CPUs, and computers with vacuum tubes. But
every time the word size doubles there's a transition period then it
becomes the norm. Maybe the hardware design is capable but not
optimized for the difference at first. Maybe the fact that a Pi 3B
can run either as 32 or 64 bit means it's slower at 64 than something
that's 64 only. There were weird CPUs like the 8088 and 8086 where
(if I remember this right) the 8086 was wide enough but the 8088 had
to do an extra cycle or two. And 640k max memory, don't want to go
back to that. Or 64k.
On 3/1/20, Pete Batard <pete@akeo.ie> wrote:
> On 2020.03.01 16:30, Gene Heskett wrote:
>>> Debian 10.3 ARM64 should install and work just fine on the Pi 3,
>>> including full graphical mode. No need for 32-bit.
>>
>> Yes, I've done it, works fine, with one glaring exception all the 64 bit
>> fans refuse to recognize.
>
> I think you're assuming a bit too much with that statement with the idea
> that the world is populated by close-minded 64-bit ARM "fans".
>
> I don't have a particular bone with either. OP mentioned that they had
> been trying to install "debian-10.3.0-arm64-xfce-CD-1.iso", then someone
> replied that they should got with ARM 32 and raspbian instead, and all I
> said is that it wasn't necessary when you can get
> debian-10.3.0-arm64-xfce-CD-1.iso installed on a Pi 3 without too much
> trouble.
>
> So this is not exactly a "You *should* use 64-bit" matter. I just stated
> that OP could install the distro they were originally planning to
> install, and pointed to guides that explain how they should proceed to
> do so.
>
>> When called upon to run machinery that demands microsecond responses in
>> order to run that machinery smoothly AND accurately, the increased
>> latency caused by the 64 bits much larger stack frame to be stored, and
>> pulled back into active service when an interrupt from the machine is
>> received, slowing the response to the interrupt from 5 microseconds to
>> 50 or more is not tolleratable. armhf is much faster, and when doing
>> software stepping, which when the step timing has jitter in its timed
>> pulses, very rapidly kills motor torque with increases in the timeing
>> jitter, with a 50 microsecond jitter killing over 75% of a motors usable
>> power.
>
> Yes. All archs and software implementations on top of specific archs
> have advantages and drawbacks. But it seems to me like you are trying to
> imply that 64-bit should be avoided altogether on account of the one
> scenario you exposed above, whereas, just like there exists scenarios
> where 32-bit has the edge over 64-bit, there also exist scenario where
> 32 vs 64-bit won't make much of a significant difference, which, in lack
> of further indication, we can probably assume is OP's planned use.
>
> OP expressed their interest to use 64-bit Debian and said nothing about
> running machinery with it, so I hope you can appreciate that an answer
> that aims at helping OP go with the original arch they said they wanted
> to install, but seemed to have trouble installing, is not exactly
> invalidated by the point you raise.
>
> In other words, the point you make is very valid and something 64-bit
> users might indeed want to be made aware of. But it would have been made
> better without preceding it with what seems to me a rather reductive
> opinion of folks who do think that, just like 32-bit, 64-bit has its place.
>
> Regards,
>
> /Pete
>
>
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Reply to: