ankith26
Posts: 218
Joined: Mon Mar 25, 2019 11:08 am
Location: /home/pi/pythonprojects/test.py
Contact: Website

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:17 am

They mean multithreading.
I sat thinking for 5 minutes on what to put here. Finally I put something like this.
Check out my github page @ https://github.com/ankith26

jahboater
Posts: 5022
Joined: Wed Feb 04, 2015 6:38 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 8:46 am

ejolson wrote:
Wed Jan 15, 2020 3:06 am
It looks like you've discovered another great software request: Develop a new programming language for beginners to learn how to write parallel code.
Occam ?

Technocolour
Posts: 85
Joined: Thu Jul 04, 2019 6:23 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 9:01 am

W. H. Heydt wrote:
Tue Jan 14, 2020 9:42 pm
Heater wrote:
Tue Jan 14, 2020 9:05 pm
Technoclour,
I remember its progress bar going from empty to full and ... nothing.
As far as I can tell getting progress bars to work properly is an unsolved problem in Computer Science.

Microsoft and countless others have been trying to solve this problem for three decades or more without any progress. (See what I did there?)
I suspect part of the problem is deciding how measure the progress in the first place.
Fair points.

But a simple removal of the bar when full, and a replacement text saying something like:

"Preparing install.

Please do not shut down the computer. The computer will reboot automatically when done. (Warning, may take up to 30 minutes or more depending on hardware and storage!)"

Would have solved the confusion for me.

User avatar
rin67630
Posts: 848
Joined: Fri Mar 04, 2016 10:15 am

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 9:46 am

I have not much hope to convince, but I do find Processing to be a very good approach to teach serious programming.
It is a complete ecosystem around Java, but can cope with Python or other languages as well.
The most important thing it that it has a huge organized library of ready-made searchable examples (including examples for each library) and can run and debug them interpreted or compiled right from the GUI. You can do pretty much everything from the GUI and that is important for inexperienced programming candidates.
Unfortunately the Processing compiler does not issue a stand alone code that runs OOB on the Pi. :(
I'd love to have that fixed and possibly to have Processing in the Recommended Software (once it runs satisfactorily).

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24923
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 10:08 am

rin67630 wrote: I have not much hope to convince, but I do find Processing to be a very good approach to teach serious programming.
It is a complete ecosystem around Java, but can cope with Python or other languages as well.
The most important thing it that it has a huge organized library of ready-made searchable examples (including examples for each library) and can run and debug them interpreted or compiled right from the GUI. You can do pretty much everything from the GUI and that is important for inexperienced programming candidates.
Unfortunately the Processing compiler does not issue a stand alone code that runs OOB on the Pi. :(
I'd love to have that fixed and possibly to have Processing in the Recommended Software (once it runs satisfactorily).
I think it the Processing Devs you need to convince, not us. We have no experience of it whatsoever (I don't even know what it is), so asking us to do work on it is very out of scope. It would take months just to get familiar with the code base, so it would be a massive effort that took away dev work from everything else. For example, when we needed work done on Scratch we had to contract it in, same with the 3D driver, same with acceleration in Chromium and VLC etc. I suppose money could be thrown at the Processing Devs, but I think it's something they should be doing anyway.

edit: Processing does run on the Pi. https://pi.processing.org/get-started/ Not sure how good it is, but clearly the devs are thinking about it.

And why is this multithreaded stuff just coming up now? Multithreading has been available in most languages for years, people have been writing multithreaded code for years. It's not a new thing and there is lots of documentation on things like pthreads etc. You could write multithreaded code on the Pi1, so it's not like its a new Pi thing. Python has a threading library already.

Clusters are the same, been around for years.

So why is the topic suddenly hot?


Also, just to clarify, the question about software was really about things like the kernel and the packages we directly support, rather than getting some random package working but there is some mileage I suspect in suggestions like this.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

Heater
Posts: 14415
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 10:36 am

jamesh,
So why is the topic suddenly hot?
There has been a lot of discussion about this everywhere these last few years.

Back in the day our computers had only one core. Every couple of years the performance we got out of our single core machines doubled. See Moore's Law. As such nobody much thought about creating software that could make use of multiple cores.

Now a a days, with the end of Moore's law, core speeds have not been rising so rapidly. But to make up for that our PC's now have multiple cores and hyper-threading. So there they sit, mostly unused as our single threaded programming does not get any faster.

Ergo the increased interest in being able to create multi-threaded code. In programmers who know how to do it properly. In languages that help the rest do it more easily.

Turns out all the multi-threading/multi-core/parallel processing business is hard to do. What with endless data races, and the killer Amdahl's law preventing you from using cores efficiently.

I think that is what ejolson is talking about when he speaks of getting kids doing parallel programming. So that this is a natural for the next generation.

You are right, people have been writing multi-threaded code for years. Just not most programmers most of the time.

Anecdote :

My first paid programming work was on a multi-core, shared memory system. It was a rack of four Intel 8 bit 8085 boards sharing a memory board. They needed four processors to keep up with the machine they were controlling. All nice assembly language.

That was a lesson in Moore's Law and the futility of doing such a thing. As the software guy I ended up spending ages tracking down and fixing the race conditions in their bus arbitration hardware logic. By the time they got it designed, built and working properly they could have done the whole job with a single i286 !
Memory in C++ is a leaky abstraction .

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24923
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 11:32 am

Heater wrote:
Wed Jan 15, 2020 10:36 am
jamesh,
So why is the topic suddenly hot?
There has been a lot of discussion about this everywhere these last few years.

Back in the day our computers had only one core. Every couple of years the performance we got out of our single core machines doubled. See Moore's Law. As such nobody much thought about creating software that could make use of multiple cores.

Now a a days, with the end of Moore's law, core speeds have not been rising so rapidly. But to make up for that our PC's now have multiple cores and hyper-threading. So there they sit, mostly unused as our single threaded programming does not get any faster.

Ergo the increased interest in being able to create multi-threaded code. In programmers who know how to do it properly. In languages that help the rest do it more easily.

Turns out all the multi-threading/multi-core/parallel processing business is hard to do. What with endless data races, and the killer Amdahl's law preventing you from using cores efficiently.

I think that is what ejolson is talking about when he speaks of getting kids doing parallel programming. So that this is a natural for the next generation.

You are right, people have been writing multi-threaded code for years. Just not most programmers most of the time.

Anecdote :

My first paid programming work was on a multi-core, shared memory system. It was a rack of four Intel 8 bit 8085 boards sharing a memory board. They needed four processors to keep up with the machine they were controlling. All nice assembly language.

That was a lesson in Moore's Law and the futility of doing such a thing. As the software guy I ended up spending ages tracking down and fixing the race conditions in their bus arbitration hardware logic. By the time they got it designed, built and working properly they could have done the whole job with a single i286 !
Now that my grandmother is fully conversant with sucking eggs, how about answering the question - why now??? Why is it suddenly the next generation that needs to learn it, hasn't the current generation also leant it, and the previous one?

(There is a possibility that I have some cognitive bias here, as I have been writing multithreaded code for about 25 years, in teams where it is common, so it's odd for me to find people who have no idea about it)
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24923
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 11:40 am

ankith26 wrote:
Wed Jan 15, 2020 2:51 am
But python, the main language for teaching beginners does not support parallel multithreaded tasking.
And I guess java is too much for teaching beginners.
Just noticed this comment whilst tidying the thread.

AFAIK, Python does support multithreading. Not sure to what extent, but certainly enough to teach the basics I suspect.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

dickon
Posts: 702
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 11:52 am

jamesh wrote:
Wed Jan 15, 2020 11:32 am
Now that my grandmother is fully conversant with sucking eggs, how about answering the question - why now??? Why is it suddenly the next generation that needs to learn it, hasn't the current generation also leant it, and the previous one?
They haven't. As Alan Cox famously said, 'Threads are for people who can't program state machines.'. That hasn't dated well -- we've got better at adding threads (in both hardware and software) so using them makes much more sense than it did when he wrote that -- but people are still wary of them, and race conditions and deadlocks frighten people off.

I like threads, FWLIW.

Daniel Gessel
Posts: 113
Joined: Sun Dec 03, 2017 1:47 am
Location: Boston area, MA, US
Contact: Website Twitter

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 12:15 pm

It has been noted that having the compositor on is a big hit for GL programs (maybe others, I haven’t benchmarked). For those of working with GL, it’s a concern that compositing is on by default (because we want our programs to run fast “out of the box”).

Maybe there’s an alternative compositor (or an existing way to do this on the current compositor) that could fastpath a window if it’s marked opaque and is not obscured?

ankith26
Posts: 218
Joined: Mon Mar 25, 2019 11:08 am
Location: /home/pi/pythonprojects/test.py
Contact: Website

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 12:16 pm

ankith26 wrote:
Wed Jan 15, 2020 5:26 am
In order for Python to achieve true multithreading, the GIL(which is everyone’s friend) has to be removed.
But GIL is important for the python interpreter to work. In order to solve this problem, python should be a compiled language(which is totally against its core beliefs) or it must run one some virtual machine using JIT compilers(like hove java does, it is quite successfully doing this).
So the real solution is to make a language with python-like syntax and java-like JIT compiler and virtual machine.
You get all the advantages of python and are freed of its downsides(speed, multithreading etc) this way
But python wants to remain an interpreted language so I don’t see the above solution working.
I would definitely love to work on such an open-source project, but I do not have so much technical know how on such topics, you see, I am only good at python itself.
This is my older post here.
I mention here that python lacks “true multithreading”.
Python multithreading module executes code PSUEDO-concurrently - by executing only one thread at a time.
On one core and only one thread, it runs the code.
But it tries to achieve multitasking, but not by real multithreading.
I sat thinking for 5 minutes on what to put here. Finally I put something like this.
Check out my github page @ https://github.com/ankith26

Heater
Posts: 14415
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 1:20 pm

jamesh,
Now that my grandmother is fully conversant with sucking eggs, how about answering the question - why now??? Why is it suddenly the next generation that needs to learn it, hasn't the current generation also leant it, and the previous one?
Whilst our grandmothers get on with their new egg sucking skills, what I was trying to say was:

I don't think the current generation has learned it. Or at least it has not been widely practiced. There was no need to, we only had single core machines, writing single threaded code is much simpler to write, reason about and debug.

Meanwhile the languages in common use don't support parallel processing very well. C does not. Not until you mix in pthreads or OpenMP. It's a mess. C++ only recently got threads standardized. Python can do it, very inefficiently, and with the sloth of Python who would think to use threads in Python to gain performance? Is it even possible? Javascript does not have threads at all. And so on, and so on.

It's relatively recently that languages like Go turned up to make threaded/parallel programming manageable for the average code monkey.

As to "why now"? As I said, performance cannot be gained by waiting a year and buying a faster core. As used to be the case all my life. Rather one has to go multi-threaded to make use of the power of all the cores one now gets.
There is a possibility that I have some cognitive bias here, as I have been writing multithreaded code for about 25 years,...
I suspect so. I have done my fair share of work on multi-processor, multi-core systems. However it was mostly about distributing different tasks over different cores, rather than distributing a single algorithm over many cores. Which is a far harder proposition.
Memory in C++ is a leaky abstraction .

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24923
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 1:26 pm

Daniel Gessel wrote:
Wed Jan 15, 2020 12:15 pm
It has been noted that having the compositor on is a big hit for GL programs (maybe others, I haven’t benchmarked). For those of working with GL, it’s a concern that compositing is on by default (because we want our programs to run fast “out of the box”).

Maybe there’s an alternative compositor (or an existing way to do this on the current compositor) that could fastpath a window if it’s marked opaque and is not obscured?
We use xcompmgr because if you don't have a compositor, window dragging on the desktop got very stuttery and slow. It can easily be turned off in raspi-config. Since desktop use is a bigger use case than 3D users, that gets the benefit.

We did try different compositors before choosing xcompmgr, the others were worse.

I suspect there are bugs in all of these compositors that if fixed would improve things, but we don't have the resource to track them down.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24923
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 1:28 pm

ankith26 wrote:
Wed Jan 15, 2020 12:16 pm
ankith26 wrote:
Wed Jan 15, 2020 5:26 am
In order for Python to achieve true multithreading, the GIL(which is everyone’s friend) has to be removed.
But GIL is important for the python interpreter to work. In order to solve this problem, python should be a compiled language(which is totally against its core beliefs) or it must run one some virtual machine using JIT compilers(like hove java does, it is quite successfully doing this).
So the real solution is to make a language with python-like syntax and java-like JIT compiler and virtual machine.
You get all the advantages of python and are freed of its downsides(speed, multithreading etc) this way
But python wants to remain an interpreted language so I don’t see the above solution working.
I would definitely love to work on such an open-source project, but I do not have so much technical know how on such topics, you see, I am only good at python itself.
This is my older post here.
I mention here that python lacks “true multithreading”.
Python multithreading module executes code PSUEDO-concurrently - by executing only one thread at a time.
On one core and only one thread, it runs the code.
But it tries to achieve multitasking, but not by real multithreading.
None of that matters if you are teaching it. Which I believe was the point?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24923
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 1:33 pm

Heater wrote:
Wed Jan 15, 2020 1:20 pm
jamesh,
Now that my grandmother is fully conversant with sucking eggs, how about answering the question - why now??? Why is it suddenly the next generation that needs to learn it, hasn't the current generation also leant it, and the previous one?
Whilst our grandmothers get on with their new egg sucking skills, what I was trying to say was:

I don't think the current generation has learned it. Or at least it has not been widely practiced. There was no need to, we only had single core machines, writing single threaded code is much simpler to write, reason about and debug.

Meanwhile the languages in common use don't support parallel processing very well. C does not. Not until you mix in pthreads or OpenMP. It's a mess. C++ only recently got threads standardized. Python can do it, very inefficiently, and with the sloth of Python who would think to use threads in Python to gain performance? Is it even possible? Javascript does not have threads at all. And so on, and so on.

It's relatively recently that languages like Go turned up to make threaded/parallel programming manageable for the average code monkey.

As to "why now"? As I said, performance cannot be gained by waiting a year and buying a faster core. As used to be the case all my life. Rather one has to go multi-threaded to make use of the power of all the cores one now gets.
There is a possibility that I have some cognitive bias here, as I have been writing multithreaded code for about 25 years,...
I suspect so. I have done my fair share of work on multi-processor, multi-core systems. However it was mostly about distributing different tasks over different cores, rather than distributing a single algorithm over many cores. Which is a far harder proposition.
Multithreaded code has been used on single core machines since forever. The techniques for writing the code remain the same (at least from a teaching people perspective) as when using multi core machines, you still have to guard for race conditions etc. Write good multi threaded code on your single core device, and it will work on a multi core device, but better (within some bounds)

Parallel ALGORITHMS on the other hand are a different thing entirely. As you say, splitting up a single task to make it more efficient when used over multiple processes (which can be on a single OR multiple cored device), is actually a difficult task. Think of a sorting algorithm, they are very different when written in parallel vs single thread.

So, is that actually what people are asking about?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

Heater
Posts: 14415
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 1:50 pm

dickon,
As Alan Cox famously said, 'Threads are for people who can't program state machines.'
I love it. Thanks for that.

Reminds me of porting a protocol stack to the PC and MS-DOS years ago. No threads to be found there. I replaced them all with state machines and it worked a treat.
That hasn't dated well -- we've got better at adding threads (in both hardware and software) so using them makes much more sense than it did when he wrote that
Oddly enough, those who are into threaded programs, for example builders of web servers, have come to the conclusion that threads are not an efficient way to proceed. Especially if you want millions of then running at the same time. Hence nginx uses asynchronous programming techniques based on an event loop.

Recently languages like C++ and Rust have adopted 'async' features to wrap that up in syntax. Basically buidling those event loops and state machines into the language so that programmers don't have to write them explicitly. Even Python and Javascript have sprouted 'async/await' keywords.

There might be a new generation programmers coming along using threads and/or async naturally as languages like Rust bring them memory safety and ensure no data races.
Memory in C++ is a leaky abstraction .

Daniel Gessel
Posts: 113
Joined: Sun Dec 03, 2017 1:47 am
Location: Boston area, MA, US
Contact: Website Twitter

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 2:08 pm

jamesh wrote:
Wed Jan 15, 2020 1:26 pm
Daniel Gessel wrote:
Wed Jan 15, 2020 12:15 pm
It has been noted that having the compositor on is a big hit for GL programs (maybe others, I haven’t benchmarked). For those of working with GL, it’s a concern that compositing is on by default (because we want our programs to run fast “out of the box”).

Maybe there’s an alternative compositor (or an existing way to do this on the current compositor) that could fastpath a window if it’s marked opaque and is not obscured?
We use xcompmgr because if you don't have a compositor, window dragging on the desktop got very stuttery and slow. It can easily be turned off in raspi-config. Since desktop use is a bigger use case than 3D users, that gets the benefit.

We did try different compositors before choosing xcompmgr, the others were worse.

I suspect there are bugs in all of these compositors that if fixed would improve things, but we don't have the resource to track them down.
Yes, window dragging with the compositor off, to put it technically, “sucks”. Sounds like the best way forward in the short term is to remind users about the option in raspi-config and in the long term to enhance xcompmgr ourselves!

X-Gen
Posts: 87
Joined: Fri Dec 06, 2019 12:08 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 4:33 pm

jamesh wrote:
Wed Jan 15, 2020 1:33 pm
Heater wrote:
Wed Jan 15, 2020 1:20 pm
jamesh,
Now that my grandmother is fully conversant with sucking eggs, how about answering the question - why now??? Why is it suddenly the next generation that needs to learn it, hasn't the current generation also leant it, and the previous one?
Whilst our grandmothers get on with their new egg sucking skills, what I was trying to say was:

I don't think the current generation has learned it. Or at least it has not been widely practiced. There was no need to, we only had single core machines, writing single threaded code is much simpler to write, reason about and debug.

Meanwhile the languages in common use don't support parallel processing very well. C does not. Not until you mix in pthreads or OpenMP. It's a mess. C++ only recently got threads standardized. Python can do it, very inefficiently, and with the sloth of Python who would think to use threads in Python to gain performance? Is it even possible? Javascript does not have threads at all. And so on, and so on.

It's relatively recently that languages like Go turned up to make threaded/parallel programming manageable for the average code monkey.

As to "why now"? As I said, performance cannot be gained by waiting a year and buying a faster core. As used to be the case all my life. Rather one has to go multi-threaded to make use of the power of all the cores one now gets.
There is a possibility that I have some cognitive bias here, as I have been writing multithreaded code for about 25 years,...
I suspect so. I have done my fair share of work on multi-processor, multi-core systems. However it was mostly about distributing different tasks over different cores, rather than distributing a single algorithm over many cores. Which is a far harder proposition.
Multithreaded code has been used on single core machines since forever. The techniques for writing the code remain the same (at least from a teaching people perspective) as when using multi core machines, you still have to guard for race conditions etc. Write good multi threaded code on your single core device, and it will work on a multi core device, but better (within some bounds)

Parallel ALGORITHMS on the other hand are a different thing entirely. As you say, splitting up a single task to make it more efficient when used over multiple processes (which can be on a single OR multiple cored device), is actually a difficult task. Think of a sorting algorithm, they are very different when written in parallel vs single thread.

So, is that actually what people are asking about?
All I'm asking for is a way to use my pi zero with a GUI.
Raspbian is great, but not tuned for this low end hardware. Mainly the browser. But it would be nice to have a text based GUI (believe it or not, but it used to exist, an ultra low memory asci/terminal based GUI and programs).

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6164
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 4:40 pm

X-Gen wrote: Raspbian is great, but not tuned for this low end hardware. Mainly the browser. But it would be nice to have a text based GUI (believe it or not, but it used to exist, an ultra low memory asci/terminal based GUI and programs).
There's no shortage of TUI applications still.

I haven't tried it, but twin should work:
https://github.com/cosmos72/twin/

If that's what you're into there are plenty of browsers you can use - like elinks. Throw in a file manager like midnight commander and you should be covered.

ejolson
Posts: 4237
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 4:48 pm

X-Gen wrote:
Wed Jan 15, 2020 4:33 pm
Raspbian is great, but not tuned for this low end hardware. Mainly the browser. But it would be nice to have a text based GUI (believe it or not, but it used to exist, an ultra low memory asci/terminal based GUI and programs).
Good news! Raspbian Lite is available at

https://www.raspberrypi.org/downloads/raspbian/

Load tmux if it isn't already installed and run that on the console.

Edit: The above post also has an idea.

jahboater
Posts: 5022
Joined: Wed Feb 04, 2015 6:38 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 5:12 pm

Heater wrote:
Wed Jan 15, 2020 1:20 pm
Meanwhile the languages in common use don't support parallel processing very well. C does not. Not until you mix in pthreads or OpenMP.
C does have threads natively.
See the C18 ISO standard.

ejolson
Posts: 4237
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 5:24 pm

jahboater wrote:
Wed Jan 15, 2020 5:12 pm
Heater wrote:
Wed Jan 15, 2020 1:20 pm
Meanwhile the languages in common use don't support parallel processing very well. C does not. Not until you mix in pthreads or OpenMP.
C does have threads.
See the C18 standard.
I searched for C18 threads and found

Image

on the MSC website. I'm thinking MSC doesn't stand for Microsoft C.

Though I'm not sure it makes the best teaching language for introducing parallel processing into the beginning curriculum for students at early levels, do you have a link to the C18 standard?

dickon
Posts: 702
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 5:26 pm

According to its Wikipedia entry, it's just a bugfix of C11, so look for that.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24923
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 5:37 pm

X-Gen wrote:
Wed Jan 15, 2020 4:33 pm
jamesh wrote:
Wed Jan 15, 2020 1:33 pm
Heater wrote:
Wed Jan 15, 2020 1:20 pm
jamesh,

Whilst our grandmothers get on with their new egg sucking skills, what I was trying to say was:

I don't think the current generation has learned it. Or at least it has not been widely practiced. There was no need to, we only had single core machines, writing single threaded code is much simpler to write, reason about and debug.

Meanwhile the languages in common use don't support parallel processing very well. C does not. Not until you mix in pthreads or OpenMP. It's a mess. C++ only recently got threads standardized. Python can do it, very inefficiently, and with the sloth of Python who would think to use threads in Python to gain performance? Is it even possible? Javascript does not have threads at all. And so on, and so on.

It's relatively recently that languages like Go turned up to make threaded/parallel programming manageable for the average code monkey.

As to "why now"? As I said, performance cannot be gained by waiting a year and buying a faster core. As used to be the case all my life. Rather one has to go multi-threaded to make use of the power of all the cores one now gets.

I suspect so. I have done my fair share of work on multi-processor, multi-core systems. However it was mostly about distributing different tasks over different cores, rather than distributing a single algorithm over many cores. Which is a far harder proposition.
Multithreaded code has been used on single core machines since forever. The techniques for writing the code remain the same (at least from a teaching people perspective) as when using multi core machines, you still have to guard for race conditions etc. Write good multi threaded code on your single core device, and it will work on a multi core device, but better (within some bounds)

Parallel ALGORITHMS on the other hand are a different thing entirely. As you say, splitting up a single task to make it more efficient when used over multiple processes (which can be on a single OR multiple cored device), is actually a difficult task. Think of a sorting algorithm, they are very different when written in parallel vs single thread.

So, is that actually what people are asking about?
All I'm asking for is a way to use my pi zero with a GUI.
Raspbian is great, but not tuned for this low end hardware. Mainly the browser. But it would be nice to have a text based GUI (believe it or not, but it used to exist, an ultra low memory asci/terminal based GUI and programs).
Others have commented on the text UI, but with regard to Raspbian and GUI's on the lower power devices, it's difficult to see where they can be sped up. The browser is clearly slow, but that in all likelihood is because its just badly written in places and there is not much we can do to rewrite Chromium, or reduce its RAM requirements! As for the desktop itself, it's based on LXDE which is a pretty low end with regard to power requirement already. I guess all these things COULD be improved and sped up, but at colossal cost. If something is running slow it usually requires a LOT of work to improve, and I think that probably that dev time (not that we would have enough people to do it!) would be better spent in other areas. We've already grabbed all the low hanging fruit.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

User avatar
paddyg
Posts: 2462
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: Future of raspberry pi - software related

Wed Jan 15, 2020 5:46 pm

Harking back a few posts to the "why not invent a new language that beginners can use (like python) but takes advantage of multithreading." That's already been invented and it's... python. Libraries such as numpy, tensorflow, numba and others spot opportunities for parallel processing and "just do it" (often using GPU cores if possible (yes that's a vote from me for CUDA on the pi)).
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

Return to “General discussion”