[Vm-dev] Touch/MultiTouch Events

Phil B pbpublist at gmail.com
Sat Sep 26 23:35:39 UTC 2020


Tim,

On Sat, Sep 26, 2020 at 6:20 PM tim Rowledge <tim at rowledge.org> wrote:

>
>
>
> > On 2020-09-26, at 11:04 AM, Phil B <pbpublist at gmail.com> wrote:
> > [snips]
> >
> > 2GB is plenty of RAM for a handful of running applications... just not a
> web browser with 50 open tabs.  The majority of Debian packages (that don't
> have full desktop GL or GL ES 3 requirements) run on it including Gimp etc.
> Not terribly well, but they do run.
>
> I've been running most of my work on assorted Pi with 1Gb or less for ...
> however long it is that Pi have been around, so yes, I understand that. And
> the browser thing is just another indication of utterly the WWW
> infrastructure has been screwed up. We'd be a lot better off if Squeak were
> the in-browser language.
>

I was just using that as an example of the kind of desktop task one
wouldn't want to try on a low-powered device even though the software is
mostly technically there.  Yes, I know the RPi is similarly mostly there
(to a degree).  The difference is that on other devices where we're running
things like Mobian, they use the actual Debian (or whatever base distro
you're using) ARM repos which have advantages in terms of package selection.


>
> >
> > Where Squeak is going to have problems is that it's only able to take
> advantage of a single core @ ~1.1GHz and the lack of JIT support.
>
>
> Err, what lack of jit support would that be? ARM32 has been Cog'd for a
> long time now (coming up on 6 years I think) and ARM64 is working well,
> though is not totally finished in some part of the FFI stuff IIRC.
>

Most (all?) current Pinephone distros run ARM64. Given the previously
mentioned anemic storage performance and already taxed SoC, throwing
multi-arch into the mix to run ARM32 code (especially just for Squeak)
wouldn't be a good experience.  Isn't the current state of Cog on ARM64 DIY
with major caveats such as FFI? (which doesn't help me as I'm very
dependent on FFI)


> My Pi4 (running 32 bit Raspbian) benchmarks at around 35% of my 4.3GHz/i7
> iMac. I'm not expecting a huge increase when I flip to AARCH64 but there
> will likely be some.
>

Your Pi 4 relative performance isn't relevant for current Linux mobile
devices.  The power and thermal envelopes of the Pi 4 don't fit that use
case.  Realistically, most mobile SoC's that can be used on a remotely open
device today are going to have significantly less performance.  The A64 is
at the lower end of the range and it is what it is.  The motivation for
going to AARCH64 is primarily to avoid multi-arch rather than any
significant performance boost inherent in 64-bit.


>
> And multi-core? Well yes I suppose. Except that one can very easily spawn
> multiple running images using Dave Lewis' OSProcess package, including in
> ways that do some work and return the results.The spawning takes very
> little time; for example on said Pi4 it takes 39mS to do
>     UnixProcess forkHeadlessSqueakAndDoThenQuit: [UnixProcess helloWorld]
> I suspect we could do very useful things with that.
>

OSProcess helps (to a degree) only where you have coarse-grained
parallelism needs and/or latency isn't an issue.


> >
> > One other not so surprising issue with Pine64 devices is the not great
> flash memory performance: ~80MB/s with eMMC, ~20MB/s with microSD.  While
> it's not as bad as older Raspberry Pi devices (thanks to the eMMC), it's in
> the same class of performance.  You'll feel this when loading things much
> more than you're likely to notice the 2GB of RAM.
>
> On my Pi4 again, loading a fresh Squeak trunk image takes ~1-2 sec.
>

Again, apples and oranges and not terribly apropos when running on
currently available, reasonably open, mobile devices.  Sure, eventually
devices based on bargain basement sub-10nm SoCs will appear.  But in the
meantime (i.e. next several years), we have what we have.


>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- His mind wandered and never came back.
>
>
>
Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200926/d1be198b/attachment-0001.html>


More information about the Vm-dev mailing list