Poster | Thread |
cdimauro
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 4-Jul-2024 20:17:21
| | [ #21 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 4115
From: Germany | | |
|
| @matthey
Quote:
matthey wrote: cdimauro Quote:
Using AREXX ports could be emulated with other languages (I don't recall now which Amiga Python implementation has some libraries for it).
|
The ARexx message ports are normal Amiga message ports. Any program can send messages to the public ARexx ports so other languages can too. |
I don't know the details, but I recall that you needed AREXX master to run in order to enable AREXX applications for exchanging messages through their AREXX ports.
I was referring to this one, before. Quote:
The RP2040 SoC RPi Pico with 264 kiB SRAM uses it. Only a CLI text based interface is available. The Amiga 1000 had a GUI, preemptive multitasking OS and enough memory for ARexx with 256kiB of memory. It wasn't even optimized with 68020 code which would improve the code density and more is possible with ColdFire and other optimizations. The AmigaNone is a fat overpriced PPC desktop computer though. Only Amiga1 makes it impossible to proliferate the 68k Amiga. |
A good part of the Amiga o.s. was written in assembly. Hence, it used much less space compared to C/C++ compiled code.
That's why comparisons like those can give no concrete information, besides that hand-optimized assembly code is much more compact and efficient. |
|
Status: Offline |
|
|
bhabbott
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 5-Jul-2024 16:36:49
| | [ #22 ] |
|
|
|
Regular Member |
Joined: 6-Jun-2018 Posts: 459
From: Aotearoa | | |
|
| @cdimauro
Quote:
cdimauro wrote: @bhabbott
[quote]
tinypy is a minimalist implementation of python in 64k of code |
Still too big.
The advantage of an interpreter is that you can work 'interactively', typing in code and executing it immediately, rather that having to go through an edit/compile/execute/debug cycle. That can speed up development, especially for 'trivial' code that only needs a few lines. And the interpreter is always there so you don't need a separate development environment. The down sides are that the interpreter takes up a lot of resources and execution speed takes a big hit.
OTOH, modern computers are so powerful that the size of the development system isn't an issue and small programs compile almost in real time. Powerful debuggers allow interactive execution with source code and variables shown. For cross development, simulators and emulators can be used to quickly test code safely, with greater control and insight than on the real hardware. And of course the target doesn't have to host an interpreter, which is a big deal on small low powered systems.
Quote:
Since you retired, you've plenty of time which you can waste still writing assembly code. |
I talked about AREXX being written is asm purely to explain its small footprint. I haven't seen the source code, but according to Thomas Richter it's an unmaintainable mess, and I'm not surprised (few asm coders do a good job of structuring and commenting their code).
As for what languages I code in, you already know I used C for the GAL programmer. I have only been retired for 1.5 years so most of my coding was done while working. For commercial stuff I use whichever language gets the job done quickest. This includes asm, C, BASIC, and javascript (but not python because none of the projects I worked on used it and I would have to spend time learning the language). For example yesterday I made a device using a Microchip PIC and code that I originally wrote back in 2017, slightly modified to suit the current application. Not going to be using python on an MCU with only 1k of program memory! (and which needs to operate in real time with 1us response time while running at 4 MHz).
You may be able to bang out code faster in python but that doesn't mean it will save time compared to another language. For non-trivial stuff it relies on libraries which people have put a lot of hard work into producing, so you are benefiting from the time they 'wasted'. However to use those libraries you still have to spend time reading the documentation and understanding how they work. That might not be so bad, but a lot of seemingly simple python code relies on libraries that aren't available on the Amiga, which is an instant show-stopper. Much of the coding I have done would be impossible or very difficult to do in python. I'm not saying that making your python code more efficient isn't a good idea, just that it's a poor example because systems that run it are generally so powerful that a bit of inefficiency doesn't matter. On systems where it does matter, python is a poor match anyway due to its high resource usage and slow execution speed. And since this an Amiga forum, that is relevant to us. |
|
Status: Offline |
|
|
bhabbott
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 5-Jul-2024 16:59:51
| | [ #23 ] |
|
|
|
Regular Member |
Joined: 6-Jun-2018 Posts: 459
From: Aotearoa | | |
|
| @matthey
Quote:
matthey wrote:
MicroPython has been gaining in popularity.
https://micropython.org/ Quote:
MicroPython is packed full of advanced features such as an interactive prompt, arbitrary precision integers, closures, list comprehension, generators, exception handling and more. Yet it is compact enough to fit and run within just 256k of code space and 16k of RAM.
| The RP2040 SoC RPi Pico with 264 kiB SRAM uses it. |
That's nice - if you want to program in python and their device is suitable for your application. But how easy is it to deploy on other platforms? (I'm allergic to proprietary microcontroller boards with no second source, especially Raspberry Pi).
Quote:
The Amiga 1000 had a GUI, preemptive multitasking OS and enough memory for ARexx with 256kiB of memory. It wasn't even optimized with 68020 code |
Interesting. I wasn't aware that AREXX could run on the A1000 (thought it was KS2.0+ only).
|
|
Status: Offline |
|
|
cdimauro
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 5-Jul-2024 19:07:55
| | [ #24 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 4115
From: Germany | | |
|
| @bhabbott
Quote:
bhabbott wrote: @cdimauro
Quote:
cdimauro wrote: @bhabbott
[quote]
tinypy is a minimalist implementation of python in 64k of code |
Still too big. |
Yes, but it's much lower than 256kB, albeit still double the 32kB. Quote:
The advantage of an interpreter is that you can work 'interactively', typing in code and executing it immediately, rather that having to go through an edit/compile/execute/debug cycle. That can speed up development, especially for 'trivial' code that only needs a few lines. And the interpreter is always there so you don't need a separate development environment. The down sides are that the interpreter takes up a lot of resources and execution speed takes a big hit. |
Exactly: productivity vs speed/space. Quote:
OTOH, modern computers are so powerful that the size of the development system isn't an issue and small programs compile almost in real time. Powerful debuggers allow interactive execution with source code and variables shown. For cross development, simulators and emulators can be used to quickly test code safely, with greater control and insight than on the real hardware. |
It doesn't change the situation: high-level languages can't be beaten in terms or productivity, even on modern/powerful system.
There's a reason why Python gained so much consensus in the last year and dominates. Support is important, but it's not the only relevant piece of the cake. In fact, even C/C++ have much bigger support, but Python is the most used/preferred language. Quote:
And of course the target doesn't have to host an interpreter, which is a big deal on small low powered systems. |
That's ok, Python isn't yet suitable for all scenarios / use cases. You've to wait for SPy AKA Static Python. Quote:
Quote:
Since you retired, you've plenty of time which you can waste still writing assembly code. |
I talked about AREXX being written is asm purely to explain its small footprint. I haven't seen the source code, but according to Thomas Richter it's an unmaintainable mess, and I'm not surprised (few asm coders do a good job of structuring and commenting their code). |
Another big reason to put a tombstone on it and rewrite it in a more maintainable way. IF it still makes sense. Quote:
As for what languages I code in, you already know I used C for the GAL programmer. I have only been retired for 1.5 years so most of my coding was done while working. For commercial stuff I use whichever language gets the job done quickest. This includes asm, C, BASIC, and javascript (but not python because none of the projects I worked on used it and I would have to spend time learning the language). |
"It was nice to learn Python; a nice afternoon" - Donald Knuth
The cool thing is that... it's the truth. Quote:
For example yesterday I made a device using a Microchip PIC and code that I originally wrote back in 2017, slightly modified to suit the current application. Not going to be using python on an MCU with only 1k of program memory! (and which needs to operate in real time with 1us response time while running at 4 MHz). |
Or course (not yet, at least: see above). Quote:
You may be able to bang out code faster in python but that doesn't mean it will save time compared to another language. |
It depends on what you need to do. When I've written my last embedded application for the AVR, I heavily used it for quickly prototyping the code. Once the code was stable and the tests passed, then I've rewritten it in C. Quote:
For non-trivial stuff it relies on libraries which people have put a lot of hard work into producing, so you are benefiting from the time they 'wasted'. |
Nothing to say about that. But they created the necessary wrappers to enable way more people to use those libraries. Quote:
However to use those libraries you still have to spend time reading the documentation and understanding how they work. |
Well, that happens for every library and for every language.
The difference is that with Python it's more likely that you've the library that you're looking for. Quote:
That might not be so bad, but a lot of seemingly simple python code relies on libraries that aren't available on the Amiga, which is an instant show-stopper. Much of the coding I have done would be impossible or very difficult to do in python. |
Then try with AREX.
Jokes aside, porting Python (3.13 is arriving: better to start with it) itself is already a HUGE milestone, because it has A LOT of things already embedded.
After this, libraries can be slowly ported to improve the situation.
But at least you can count on an ecosystem which gives an enormous value, when it's being ported to a system. Quote:
I'm not saying that making your python code more efficient isn't a good idea, just that it's a poor example because systems that run it are generally so powerful that a bit of inefficiency doesn't matter. On systems where it does matter, python is a poor match anyway due to its high resource usage and slow execution speed. |
That's ok. As I've said, Python isn't yet for every scenario. Quote:
And since this an Amiga forum, that is relevant to us. |
AFAIR Amiga had accelerators. And moderns one are way faster. Quote:
bhabbott wrote: @matthey
Quote:
The RP2040 SoC RPi Pico with 264 kiB SRAM uses it. |
That's nice - if you want to program in python and their device is suitable for your application. But how easy is it to deploy on other platforms? (I'm allergic to proprietary microcontroller boards with no second source, especially Raspberry Pi). |
That's only one of microcontrollers that support Python. |
|
Status: Offline |
|
|
Karlos
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 6-Jul-2024 13:58:57
| | [ #25 ] |
|
|
|
Elite Member |
Joined: 24-Aug-2003 Posts: 4629
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| Reflecting that Python is too bloated and slow to be used in an 8-bit microcontroller ecosystem is like complaining that your caravan is too much baggage for your bicycle. It's something that should be entirely self-evident that was never intended for that purpose.
And while you can try to shrink it all the way down I to something you can just about pull along, at some point it's not really much of a caravan anymore.
Python is a language to be productive with when you have ample CPU power. And what it can't do directly, it has ample native library bindings for. Just look at modern AI workloads, they're insanely computationally expensive but people just glue native GPU acceleration code together and orchestrate it all from python.
Python isn't my thing personally, but it's certainly more than adequate for the tasks it was intended for and some that it wasn't. _________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
kolla
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 8-Jul-2024 10:19:10
| | [ #26 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 3262
From: Trondheim, Norway | | |
|
| I have python 3.12.4 on m68k, it’s what Gentoo portage is mainly written in, woop-di-doo. Cannot be bothered on AmigaOs though, square peg in a round hole. _________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
bhabbott
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 8-Jul-2024 18:52:47
| | [ #27 ] |
|
|
|
Regular Member |
Joined: 6-Jun-2018 Posts: 459
From: Aotearoa | | |
|
| @Karlos
Quote:
Karlos wrote: Reflecting that Python is too bloated and slow to be used in an 8-bit microcontroller ecosystem is like complaining that your caravan is too much baggage for your bicycle. It's something that should be entirely self-evident that was never intended for that purpose.
And while you can try to shrink it all the way down I to something you can just about pull along, at some point it's not really much of a caravan anymore. |
Problem is people learn python thinking that they will be able to run it on low powered systems, then get into trouble when eg. their IOT device draws 4W continuously and flattens the battery in 10 minutes.
Quote:
Python is a language to be productive with when you have ample CPU power. |
And when you do, coding efficiency isn't that important. That's why I say it's a poor language to talk about smaller being better.
Quote:
Python isn't my thing personally, but it's certainly more than adequate for the tasks it was intended for and some that it wasn't. |
That's debatable. It certainly isn't a good choice for the Amiga, yet some fans are using it simply because they are familiar with the language and/or have access to preexisting code that they can use.
Sadly that's a common theme on the Amiga these days. The way things are going it won't be long before you will need a PiStorm with the latest most powerful RPi overclocked by 100% to run the new 'Amiga' software being produced. |
|
Status: Offline |
|
|
Karlos
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 8-Jul-2024 20:54:12
| | [ #28 ] |
|
|
|
Elite Member |
Joined: 24-Aug-2003 Posts: 4629
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @bhabbott
Nobody is going to be writing large Amiga applications in python*. It's there as a scripting language.
*For the same reason very few large applications are being written in anything. Who's going to do it? _________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
kolla
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 9-Jul-2024 7:23:36
| | [ #29 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 3262
From: Trondheim, Norway | | |
|
| We don’t need Python to make slowmess bloatware when we have Hollywood. _________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
cdimauro
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 10-Jul-2024 0:57:40
| | [ #30 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 4115
From: Germany | | |
|
| @bhabbott
Quote:
bhabbott wrote: @Karlos
Quote:
Karlos wrote: Reflecting that Python is too bloated and slow to be used in an 8-bit microcontroller ecosystem is like complaining that your caravan is too much baggage for your bicycle. It's something that should be entirely self-evident that was never intended for that purpose.
And while you can try to shrink it all the way down I to something you can just about pull along, at some point it's not really much of a caravan anymore. |
Problem is people learn python thinking that they will be able to run it on low powered systems, then get into trouble when eg. their IOT device draws 4W continuously and flattens the battery in 10 minutes. |
Let's clarify: this is what YOU think that people are thinking.
Normally people learn Python because... rolling drum... they want to solve their problems with minimal efforts.
Which is exactly the reason why Python has a so large audience nowadays. Quote:
Quote:
Python is a language to be productive with when you have ample CPU power. |
And when you do, coding efficiency isn't that important. That's why I say it's a poor language to talk about smaller being better. |
Again, it's YOUR problem. Efficiency is important only when... rolling droum #2 ... it's found to be necessary.
And again #2, this is exactly the reason why Python has a so large audience nowadays: many problems are quickly (and elegantly) solved thanks to its extremely high productivity. Quote:
Quote:
Python isn't my thing personally, but it's certainly more than adequate for the tasks it was intended for and some that it wasn't. |
That's debatable. |
That's NOT debatable: FACTs are FACTs.
So, and again #3: YOUR problem, because you don't understand how to use the right tool to solve the specific problem. YOU have a limited vision and experience, clearly. Quote:
It certainly isn't a good choice for the Amiga, |
Let me guess: it's, again #4, YOUR limited vision?
Because Python can run on Amigas. NOT the original ones, of course, because they have limited resources, but AFAIR/K our beloved machines could be expanded & accelerated, right? Quote:
yet some fans are using it simply because they are familiar with the language and/or have access to preexisting code that they can use. |
Whatever is the reason... WHY NOT?!? Quote:
Sadly that's a common theme on the Amiga these days. The way things are going it won't be long before you will need a PiStorm with the latest most powerful RPi overclocked by 100% to run the new 'Amiga' software being produced. |
And what's the problem with that? PiStorm is THE very welcome solution for the "good old" (!) machines, so that you can get plenty of memory and A LOT of processing power for very cheap price. Not to the same ballpark of modern PCs, but, hey, it's WAY better than your crappy (NOWADAYS) Blizzard 1230, to give an example.
The thing is very simple, Bruce: you can continue use your Amigas as they were in the '80s and 90's. No problem with that: Amiga is a dead platform and entered the retrogaming & retrocomputing fandom ages ago.
Then enjoy them for what they offer and do NOT pretend to talk about their limited resources & processing power.
But as long as you want to exit from your cave and enjoy some modern software, which requires more resources & processing power, then you've to think about more modern hardware. And PiStorm is here for that, unless you come with a 1+Ghz 68k processor in ASIC (which I know that would be the preferred solution. I think all here agree on that).
@kolla
Quote:
kolla wrote: We don’t need Python to make slowmess bloatware when we have Hollywood. |
It looks that too many people here are affected by some form of schizophrenia: it's not WE, but YOU.
See above: then go back to your cave and be happy.
I, on the exact contrary, prefer Python because it's way more productive (much better syntactic constructs and an ENORMOUS pile of library for practically everything).
But we know that you're NOT a developer, right? Then why don't you stop talking of things that you've no clue at all, and go back to your sysadmin walled garden?
We already had meynaf spreading non-sense / load of balls about Python, and that was enough, thanks! |
|
Status: Offline |
|
|
kolla
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 16-Aug-2024 8:58:56
| | [ #31 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 3262
From: Trondheim, Norway | | |
|
| |
Status: Offline |
|
|
cdimauro
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 16-Aug-2024 19:18:46
| | [ #32 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 4115
From: Germany | | |
|
| @kolla: KUDOS to the guy! It's a good starting point (MicroPython is used on embedded systems = less resources available, like on the old Amigas).
|
|
Status: Offline |
|
|
Karlos
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 18-Aug-2024 13:06:16
| | [ #33 ] |
|
|
|
Elite Member |
Joined: 24-Aug-2003 Posts: 4629
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @cdimauro
Quote:
Normally people learn Python because... rolling drum... they want to solve their problems with minimal efforts |
Quite. A case in point, I have a small number of tools I use for supporting the AB3D2 mod I'm working on. One, for example, consumes the set of game modification properties, which is defined as a simple JSON schema, into a (big endian) binary that is loaded by the game at runtime. Ideally this would be portable C, linked against libjson and the time may come where I do this. However, since I was able to implement it very quickly and iteratively in php and I'm building it all on Linux I just used that. Would I recommend it for AmigaOS? Hell no._________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
cdimauro
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 19-Aug-2024 4:15:22
| | [ #34 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 4115
From: Germany | | |
|
| @Karlos: why not? The problem isn't the Amiga OS, rather the hardware.
Nowadays it's possible to run the Amiga OS with more than adeguate resources for running PHP or Python. |
|
Status: Offline |
|
|
kolla
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 19-Aug-2024 8:01:30
| | [ #35 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 3262
From: Trondheim, Norway | | |
|
| @cdimauro
Then do it - please port/build/whatever modern python3 to AmigaOS 3. Last edited by kolla on 19-Aug-2024 at 08:02 AM.
_________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
cdimauro
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 19-Aug-2024 19:53:40
| | [ #36 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 4115
From: Germany | | |
|
| |
Status: Offline |
|
|
kolla
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 19-Aug-2024 21:45:15
| | [ #37 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 3262
From: Trondheim, Norway | | |
|
| @cdimauro
Yes, you can even claim some beer money from doing it!
_________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
cdimauro
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 20-Aug-2024 4:30:07
| | [ #38 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 4115
From: Germany | | |
|
| @kolla
Quote:
kolla wrote: @cdimauro
Yes, you can even claim some beer money from doing it!
|
Sorry, not in my scope.
BTW, mazze was tinkering about it: some years ago he has shown a screenshot of something running on AROS, albeit still not complete. That could be a good starting point, but dropping Python 2.7 and directly going to 3.12 (probably the bounty need to be changed). |
|
Status: Offline |
|
|
kolla
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 20-Aug-2024 8:49:46
| | [ #39 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 3262
From: Trondheim, Norway | | |
|
| @cdimauro
Quote:
Oh come on - are you not a so called software developer? You claim the OS is not a problem, you claim resources exists now to do this… how hard can it be?!
I have built python 3.12 on 68k already, and it works great - but it is NOT AmigaOS, and I am NOT a so called software developer - so clearly OS does matter?
Last edited by kolla on 20-Aug-2024 at 08:51 AM.
_________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
cdimauro
| |
Re: Not always “big is better”: the importance of choosing data types – An example with CPython Posted on 20-Aug-2024 20:00:43
| | [ #40 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 4115
From: Germany | | |
|
| @kolla
Quote:
kolla wrote: @cdimauro
Quote:
Oh come on - are you not a so called software developer? You claim the OS is not a problem, you claim resources exists now to do this… how hard can it be?!
I have built python 3.12 on 68k already, and it works great - but it is NOT AmigaOS, and I am NOT a so called software developer - so clearly OS does matter?
|
That's the reason: you are NOT a developer, so you don't know how hard it can be. But unfortunately it hasn't stopped you to talk of things that clearly have no clue at all.
Do you know why you have built your Python 3.12? Because someone has already ported it to your platform. So, it's quite easy to checkout the repo and build it. Done!
Porting Python 3.12 to Amiga OS, AROS, whatever OS, requires someone which has already experience on porting software to the selected platform, or... a lot of time to spend tinkering and trying it.
So, again: not in my scope. |
|
Status: Offline |
|
|