Re: Turn up the CPU clocks under Android Termux ??
Thanks for the additional info.
Termux does provide /sys and /proc, so I can query them w/o root.
My problem is to figure out what they say; I'd just like to know what
the frequency of the cpu running my task is, so that I can estimate
how fast the program should run. For example, I get a very low
'bogomips' number ('38'), but I have no idea what that means,
because I get much higher bogomips numbers from my laptops
(4000 - 5000; even my very old 32bit laptop gets 2500).
Termux on 64bit Android phone:
~ $ cd /sys/devices/system/cpu
../system/cpu $ ls -l
total 0
-r--r--r-- 1 root root 4096 Apr 25 09:05 core_ctl_isolated
drwxr-xr-x 9 root root0 Jun 22 1970 cpu0
drwxr-xr-x 8 root root0 Jun 22 1970 cpu1
drwxr-xr-x 8 root root0 Apr 25 06:03 cpu2
drwxr-xr-x 8 root root0 Apr 25 06:03 cpu3
drwxr-xr-x 8 root root0 Apr 25 05:42 cpu4
drwxr-xr-x 8 root root0 Apr 25 05:41 cpu5
drwxr-xr-x 8 root root0 Apr 24 09:07 cpu6
drwxr-xr-x 8 root root0 Apr 25 05:41 cpu7
drwxr-xr-x 5 root root0 Apr 24 09:07 cpufreq
drwxr-xr-x 2 root root0 Apr 25 09:05 cpuidle
drwxr-xr-x 2 root root0 Apr 25 09:05 gladiator_hang_detect
drwxr-xr-x 2 root root0 Apr 25 09:05 hang_detect_gold
drwxr-xr-x 2 root root0 Apr 25 09:05 hang_detect_silver
drwxr-xr-x 2 root root0 Apr 25 09:05 hotplug
-r--r--r-- 1 root root 4096 Apr 25 09:05 isolated
-r--r--r-- 1 root root 4096 Apr 25 09:05 kernel_max
-r--r--r-- 1 root root 4096 Apr 25 09:05 modalias
-r--r--r-- 1 root root 4096 Apr 25 09:05 offline
-r--r--r-- 1 root root 4096 Apr 25 06:08 online
-r--r--r-- 1 root root 4096 Apr 25 09:05 possible
drwxr-xr-x 2 root root0 Apr 25 09:05 power
-r--r--r-- 1 root root 4096 Apr 25 08:49 present
-rw-r--r-- 1 root root 4096 Apr 25 09:05 uevent
drwxr-xr-x 2 root root0 Apr 25 09:05 vulnerabilities
../system/cpu $ cd cpufreq
../cpu/cpufreq $ ls -l
total 0
drwxr-xr-x 4 root root 0 Apr 24 09:07 policy0
drwxr-xr-x 4 root root 0 Apr 24 09:07 policy6
drwxr-xr-x 4 root root 0 Apr 24 09:07 policy7
../cpu/cpufreq $
-Original Message-
From:
Sent: Apr 25, 2023 7:09 AM
To:
Subject: Re: Turn up the CPU clocks under Android Termux ??
There are three separate issues here:
- making sure Termux doesn't sleep (wake lock does that)
- controlling on what core type the process runs ( see taskset )
- controlling the frequency of that core (via CPU governor)
The latter certainly requires root. The middle i have not experimented with It
is highly likely that the scheduler heavily pushes long running programs onto
the efficiency cores as phones optimise for battery life not throughput. It
might even ignore simple corr affinity stuff but that i don't know.
I hope that helps.
24.04.2023 22:20:32 Henry Baker :
> Thanks; I didn't understand your original suggestion that
> 'termux-wake-lock' was an actual termux command.
>
> Sadly, 'termux-wake-lock' didn't help speed things up, either.
>
> So either I've vastly overestimated the speed of my cellphone,
> or there's some other software problem (e.g., something
> getting interpreted instead of getting compiled... ???). Or
> perhaps my cellphone is thermally limited -- it simply may
> not have the ability to dissipate the heat from running any
> faster, so it gets throttled to avoid overheating.
>
> I appreciate your excellent suggestions!
>
> -Original Message-
> From:
> Sent: Apr 24, 2023 12:21 PM
> To:
> Subject: Re: Turn up the CPU clocks under Android Termux ??
>
> On Mon, Apr 24, 2023 at 07:01:39PM +, Henry Baker wrote:
>> So either my program really is running at full speed (which I highly doubt),
>> or Termux itself needs to be fixed to enable full speed.
>
> I dont think you have to fix anything. Have you actually tried
> taking the lock? This can be done through a button in the
> notification. See also: https://wiki.termux.com/wiki/Termux-wake-lock
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Turn up the CPU clocks under Android Termux ??
Thanks; I didn't understand your original suggestion that 'termux-wake-lock' was an actual termux command. Sadly, 'termux-wake-lock' didn't help speed things up, either. So either I've vastly overestimated the speed of my cellphone, or there's some other software problem (e.g., something getting interpreted instead of getting compiled... ???). Or perhaps my cellphone is thermally limited -- it simply may not have the ability to dissipate the heat from running any faster, so it gets throttled to avoid overheating. I appreciate your excellent suggestions! -Original Message- From: Sent: Apr 24, 2023 12:21 PM To: Subject: Re: Turn up the CPU clocks under Android Termux ?? On Mon, Apr 24, 2023 at 07:01:39PM +, Henry Baker wrote: > So either my program really is running at full speed (which I highly doubt), > or Termux itself needs to be fixed to enable full speed. I dont think you have to fix anything. Have you actually tried taking the lock? This can be done through a button in the notification. See also: https://wiki.termux.com/wiki/Termux-wake-lock -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Turn up the CPU clocks under Android Termux ??
I just ran the test with 'Unrestricted' (see below) and Android Termux performance didn't improve. So either my program really is running at full speed (which I highly doubt), or Termux itself needs to be fixed to enable full speed. -Original Message- From: Sent: Apr 24, 2023 11:43 AM To: Subject: Re: Turn up the CPU clocks under Android Termux ?? Thanks for the pointer to 'wakelock'. I looked over the documentation, and it would appear that I have to recompile Termux ?? I then looked up the permissions for Termux, and found under 'App battery usage' 3 choices: 'Unrestricted' Allow battery usage in background without restrictions. May use more battery. 'Optimized' Optimize based on your usage. Recommended for most apps. 'Restricted' Restrict battery usage while in background. App may not work as expected. Notifications may be delayed. I saw that the choice chosen for Termux was 'Optimized'. I'm going to try the 'Unrestricted' option and see if that improves performance while in Termux. -Original Message- From: Sent: Apr 24, 2023 10:14 AM To: Subject: Re: Turn up the CPU clocks under Android Termux ?? On Mon, Apr 24, 2023 at 03:26:59PM +, Henry Baker wrote: > I've noticed how Android/Termux performance falls substantially > when Termux isn't displaying on the screen -- e.g., when I'm > accessing Termux via ssh. > > I'd like to figure out how to use my phone in a 'server mode', > where it's hooked up to power, the screen is off, but it's set > for high performance. I noticed an Acquire wakelock button when I expanded the notification. This might be what you are looking for. https://developer.android.com/training/scheduling/wakelock -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Turn up the CPU clocks under Android Termux ??
Thanks for the pointer to 'wakelock'. I looked over the documentation, and it would appear that I have to recompile Termux ?? I then looked up the permissions for Termux, and found under 'App battery usage' 3 choices: 'Unrestricted' Allow battery usage in background without restrictions. May use more battery. 'Optimized' Optimize based on your usage. Recommended for most apps. 'Restricted' Restrict battery usage while in background. App may not work as expected. Notifications may be delayed. I saw that the choice chosen for Termux was 'Optimized'. I'm going to try the 'Unrestricted' option and see if that improves performance while in Termux. -Original Message- From: Sent: Apr 24, 2023 10:14 AM To: Subject: Re: Turn up the CPU clocks under Android Termux ?? On Mon, Apr 24, 2023 at 03:26:59PM +, Henry Baker wrote: > I've noticed how Android/Termux performance falls substantially > when Termux isn't displaying on the screen -- e.g., when I'm > accessing Termux via ssh. > > I'd like to figure out how to use my phone in a 'server mode', > where it's hooked up to power, the screen is off, but it's set > for high performance. I noticed an Acquire wakelock button when I expanded the notification. This might be what you are looking for. https://developer.android.com/training/scheduling/wakelock -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Turn up the CPU clocks under Android Termux ??
Does anyone on this list know how to crank up the CPU clocks on Android/Termux in order to get maximum performance? I've noticed how Android/Termux performance falls substantially when Termux isn't displaying on the screen -- e.g., when I'm accessing Termux via ssh. I'd like to figure out how to use my phone in a 'server mode', where it's hooked up to power, the screen is off, but it's set for high performance. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
LISP with GC in 436 bytes
FYI -- I don't know if anyone here noticed this hack from 12/18/2021: https://justine.lol/sectorlisp2/ LISP with GC in 436 bytes December 18th, 2021 SectorLISP (https://github.com/jart/sectorlisp) now supports garbage collection. This is the first time that a high-level garbage collected programming language has been optimized to fit inside the 512-byte boot sector of a floppy disk. Since we only needed 436 bytes, that means LISP has now outdistanced FORTH () and BASIC ( (https://github.com/cesarblum/sectorforth (https://github.com/nanochess/bootBASIC))) to be the tiniest programming language in the world. SectorLISP consists of 223 lines of assembly. It provides a LISP system that's powerful enough to let you write your own LISP interpreter in just 40 lines of LISP. It's compatible with all PC models dating back to 1981 which have at least 64kb of RAM. This isn't a toy because SectorLISP can run the proof assistant (https://justine.lol/sectorlisp2/proof.html) that was included in LISP 1.5. This is a follow-up to a previous announcement made in October that SectorLISP now fits in one sector (https://justine.lol/sectorlisp/). There's been many changes over the past few months that made it possible to shave away another hundred bytes from the i8086 assembly implementation. It left plenty of room to add a 40 byte [!] garbage collector.
Re: An assembly question from the past
Actually, 64-bits is also interesting. I only asked about 32-bits, since I had lots of old 32-bit machines around; bare metal on a Raspberry Pi (32 or 64 bits) would also be interesting. RPi4's are hard to get just now, but RPi3's run 64 bits (albeit more slowly). I haven't played with Arm VM's but I presume that they are just as good as Intel VM's. An aside: if one is executing on a 64-bit machine, how hard is it to execute a 32-bit 'application'? Can one easily start up a 32--bit thread inside a 64-bit machine? This 32 inside 64 question is purely theoretical (for the moment)... -Original Message- From: Sent: Mar 31, 2022 2:59 AM To: Subject: Re: An assembly question from the past On Wed, Mar 30, 2022 at 05:13:20PM -0700, C K Kashyap wrote: > This may be of interest to you Henry - https://picolisp.com/wiki/?PilOS Right, but it seems Henry looks for a 32-bit machine, but PilOS needs 64 bits. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: An assembly question from the past
I haven't been following this thread terribly closely, so I hope this question isn't off-base. Is there a version of picolisp that runs on 80386/80486/80586 'bare metal' (or at least 'bare VM') -- talking directly to a HW serial port and reading from a FAT file system? -Original Message- From: Sent: Mar 30, 2022 10:38 AM To: Subject: Re: An assembly question from the past On Wed, Mar 30, 2022 at 08:13:00AM -0700, C K Kashyap wrote: > Just to give some background - I've been working on the attempt to port > miniPicoLisp to windows (more like making vanilla C as the only > dependency). Good, but isn't miniPicoLisp plan vanilla C anyway? I think it uses only stdio library functions. > For the stack - I believe that Pil > successfully existed without coroutines for decades right :) Yes. Coroutines are very nice in some situations, but with more programming effort you can always implement a conventional solution instead. > Somehow llvm - even though it's "industry standard" now - I feel that it > imposes too much as a dependency - the very fact that it's written in c++ > is a turn off for me :) I agree with both statements. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Picolisp on Termux ? Picolisp on OpenWrt/Lede ?
I'm probably not the best person for this (at least not yet), for several reasons: I've had zero experience with Picolisp (so far), and have been hoping to use it on either Termux or OpenWrt or both. I've barely been able to compile OpenWrt according to the standard directions; however, I've never compiled any of my own programs for OpenWrt -- not even a C "hello world!" -- OpenWrt doesn't seem to make it very easy to add new programs when doing a system build. Although I use Termux a lot, I'm just starting to learn how to compile programs for Termux -- probably starting with Clang/LLVM and Rust. -Original Message- From: Jeronimo Pellegrini Sent: Oct 19, 2021 11:21 AM To: Henry Baker , Subject: Re: Picolisp on Termux ? Picolisp on OpenWrt/Lede ? I used to have instructions for compiling picolisp on OpenWRT, but -- I can't remember exactly what the problem was, but I couldn't compile it anymore. But it's probably something easy to fix. Here's a repository with some examples of languages packaged for OpenWRT: https://gitlab.com/jpellegrini/openwrt-packages Don't laugh -- yes, there's Algol 68 and BASIC (*) there, but there's also Scheme and Forth. I could never build a Common Lisp implementation as an OpenWRT package though, unfortunately. Anyway, you may be able to re-use some of the Makefiles there. For Termux - both Chibi Scheme and STklos Scheme can be compiled from source on Termux. I think some people got ECL working also, but I didn't try. J. (*) Actually, bwBASIC is quite interesting. It implements several different BASIC dialects. Henry Baker writes: > Is anyone willing to copy Picolisp to the Termux and/or OpenWrt repositories? > > It would be nice to have another scripting language available for these > platforms. > > -Original Message- > From: > Sent: Oct 19, 2021 6:51 AM > To: > Subject: PilCon tomorrow > > Hi all, > > reminder for tomorrow's PilCon! > > As ever on a 20th, it will be at 16:00 UTC on > > https://meeting.itship.ch/PilCon > > We can revisit and perhaps refine last time's issues. > > ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Picolisp on Termux ? Picolisp on OpenWrt/Lede ?
Is anyone willing to copy Picolisp to the Termux and/or OpenWrt repositories? It would be nice to have another scripting language available for these platforms. -Original Message- From: Sent: Oct 19, 2021 6:51 AM To: Subject: PilCon tomorrow Hi all, reminder for tomorrow's PilCon! As ever on a 20th, it will be at 16:00 UTC on https://meeting.itship.ch/PilCon We can revisit and perhaps refine last time's issues. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Digging into Symbols
The "move-to-front" heuristic is equivalent to the LRU caching policy. The "move-up-by-one" heuristic converges to LFU (least frequently used) caching policy. Perhaps LFU is what you really want? BTW, "move-up-by-one" has a side-effect on every invocation, as does "move-to-front". However, you can do "move-up-by-one" only every 1/N times, and still converge to LFU. At 12:55 PM 4/27/2020, Wilhelm Fitzpatrick wrote: >I've been digging down to really understand the symbol implementation in >Picolisp, since symbols are used for so many purposes within the language. > >One surprising thing I learned last night is that (get ...) has a side effect! >It moves the key that was accessed to the head of the symbol "tail". I assume >this is a performance optimization to cause recently accessed properties to >"bubble up" to the front of the list in case they are re-accessed soon. > >A few questions: > >1. I understand why (cdr) doesn't function on a symbol (semantically it's not >a pair) but I'm curious why (car) is allowed to work (returning the VAL)? > >2. Is there anyway within the REPL to inspect the tail structure of the symbol >directly? This is mostly from curiosity. > >3. Again from curiosity, I'm wondering why the bytes of the name are seemingly >stored "backwards"? I'm assuming this also provides some performance >optimization. > >-wilhelm > >-- >UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
PicoLisp v. MicroPython ?
MicroPython (micropython.org) is apparently an implementation of Python intended for *bare metal* implementations. Is PicoLisp aiming for some of the same applications? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Tiny Lisps for OpenWRT/LEDE ?
I seem to recall that OpenWRT used to have a tiny Scheme as part of its distribution, but that seems to have disappeared in more recent releases. Do any of you know of any Tiny Lisps for OpenWRT/LEDE? www.openwrt.org www.lede-project.org Thanks in advance for any pointers/links. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Cheap OpenWRT/LEDE target device: zsun
FYI -- This tiny $12 zsun device simply plugs into a USB port (for power) and you talk to it with wifi: https://wiki.hackerspace.pl/projects:zsun-wifi-card-reader https://wiki.openwrt.org/toh/zsun/wifi-card-reader https://www.amazon.com/Wireless-Reader-Android-Windows-Support/dp/B00TX44IZC/ This zsun device talks ONLY wifi, so you have to keep one wifi AP open to talk to the device itself. I highly recommend using the OpenWRT "extroot /overlay" technique with this zsun device -- NOT because it needs more flash memory, but because it makes possible to quickly recover if you make a configuration error: you simply take the little micro SD card out, put it into a PC, change the config files back to something sane, re-insert the uSD back into the zsun, and reboot. Beats the heck out of a bricked zsun device. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Newbie (!)
Hi all: I just discovered your project today, and was quite intrigued by what you've accomplished. I am particularly interested in "bare metal" implementations of Lisp & Lisp-like languages; part of my interest is analogous to the MirageOS "unikernal" concept; part of my interest is in gaining access to HW--e.g., page tables for more efficient implementation of large arrays. I've worked on tiny languages before -- e.g., "Comfy" for the 8-bit Apple][/Attari 6502: http://home.pipeline.com/~hbaker1/sigplannotices/sigcol03.pdf http://home.pipeline.com/~hbaker1/sigplannotices/sigcol04.pdf My approach is to write a machine-language compiler in a subset of Common Lisp, and then simply port that subset to the bare metal. However, I don't want to do too much work, so I'd like to abstract away many of the machine language issues. I was hoping to come up with a machine of 3 sizes: 16-bit, 32-bit or 64-bit "words"; this would enable a "small", "medium" and "large" versions of this Lisp. The machine would have some number of "registers" of the standard word size, some of which (I hope) would map directly into machine registers. Most operations would operate on words, so as not to have to worry about byte ordering. The byte stuff would likely have to be done as an escape mechanism to incorporate raw bits into the instruction stream. I don't want to have to re-invent C, relocatable binaries, etc., so the idea is to completely dispense with assembler, C, loaders, etc., by compiling directly into memory (a la the original 1960's Lisps). So long as the compiler is *one-pass*, and doesn't do any complex optimizations, it can run at *line speed* -- i.e., it can compile at the same rate that it can read Lisp S-expressions from a file system. Hence, there is very little advantage in ever storing compiled code in a file system. (Perhaps another way to look at this is as a 'just-in-time' compiler, where 'just-in-time' is when the code is loaded; since the compilation process could be functional, one could conceivably *page* these compilations in/out of memory a la Maclisp/Macsyma's load-on-demand functions.) The low-level portion of this Lisp would be *stackless*, and would look more like an Actor machine which is passed arguments + a "continuation" thunk/closure. A stackless machine would enable painless multiprocessing, whereby a context switch can occur at every function call. Since iterations are just tail-recursions, context switches can occur very often and very quickly. An initial experiment is a tiny *functional* Lisp based on ref counts. This eliminates the need for a traditional GC, and can potentially provide better real-time response. BTW, here is the factorial function written in this functional Lisp: (defun fact1(f n) (if (zerop n) 1 (* n (funcall f f (1- n) (defun factorial (n) (funcall #'fact1 #'fact1 n)) (Of course, to compile this into an Actorish execution model, you need to compile into continuation-passing form.) --- Since you all have been looking at tiny Lisps, do you have any recommendations of tiny Lisps to look at & play with? Thanks very much for any info & help. Henry Baker Santa Barbara, CA home.pipeline.com/~hbaker1 -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Subscribe
Hello Henry Baker <hbak...@pipeline.com> :-) You are now subscribed Subscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
