Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
Home
Features
News
Forums
Classifieds
Links
Downloads
Extras
OS4 Zone
IRC Network
AmigaWorld Radio
Newsfeed
Top Members
Amiga Dealers
Information
About Us
FAQs
Advertise
Polls
Terms of Service
Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
35 crawler(s) on-line.
 31 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 OneTimer1:  5 mins ago
 NutsAboutAmiga:  12 mins ago
 amigang:  13 mins ago
 Mr-Z:  19 mins ago
 Kronos:  20 mins ago
 michalsc:  22 mins ago
 Karlos:  22 mins ago
 zipper:  35 mins ago
 amigakit:  52 mins ago
 Abu_the_monkey:  1 hr 2 mins ago

/  Forum Index
   /  General Technology (No Console Threads)
      /  Not always “big is better”: the importance of choosing data types – An example with CPython
Register To Post

Goto page ( Previous Page 1 | 2 )
PosterThread
cdimauro 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 4-Jul-2024 21:17:21
#21 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3688
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
Profile     Report this post  
bhabbott 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 5-Jul-2024 17:36:49
#22 ]
Regular Member
Joined: 6-Jun-2018
Posts: 381
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
Profile     Report this post  
bhabbott 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 5-Jul-2024 17:59:51
#23 ]
Regular Member
Joined: 6-Jun-2018
Posts: 381
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
Profile     Report this post  
cdimauro 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 5-Jul-2024 20:07:55
#24 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3688
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
Profile     Report this post  
Karlos 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 6-Jul-2024 14:58:57
#25 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4478
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
Profile     Report this post  
kolla 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 8-Jul-2024 11:19:10
#26 ]
Elite Member
Joined: 21-Aug-2003
Posts: 3032
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
Profile     Report this post  
bhabbott 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 8-Jul-2024 19:52:47
#27 ]
Regular Member
Joined: 6-Jun-2018
Posts: 381
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
Profile     Report this post  
Karlos 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 8-Jul-2024 21:54:12
#28 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4478
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
Profile     Report this post  
kolla 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 9-Jul-2024 8:23:36
#29 ]
Elite Member
Joined: 21-Aug-2003
Posts: 3032
From: Trondheim, Norway

We don’t need Python to make slowmess bloatware when we have Hollywood.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Not always “big is better”: the importance of choosing data types – An example with CPython
Posted on 10-Jul-2024 1:57:40
#30 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3688
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
Profile     Report this post  
Goto page ( Previous Page 1 | 2 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle