Next major NetRexx release
Locked
 
|
There has been some discussion of the features desired in the next major release of NetRexx: jsr199, jsr223, regexp, list api, etc. Some of these items already have test implementations in experimental NetRexx versions. But it recently occurred to me that there is another critical area that needs support soon: multi-threading
Integrated circuit electronics speeds seem to have plateaued and processor manufacturers now increase power by adding more processors to each chip. Even tiny cell phone devices can now have quad processors. What seems to be lacking is computer language support to easily make use of that added power. I suggest that NetRexx would benefit from the addition of a simple api for making use of multiple processors. While such an api might not be able to cover all possible use cases, even handling simple cases would be valuable. Does anyone else see this feature as a useful addition? Are there any other significant areas of computing that should be considered for future support in NetRexx? -- Kermit -- Sent from my Android tablet with K-9 Mail. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Next major NetRexx release
|
|
My understanding is that groups all over the world are trying to crack the problem of parallelization of programming languages, and it has proven a very tough nut. Could you give an idea of the simple cases you would attack? On Sun, Jul 28, 2013 at 12:04 AM, Kermit Kiser <[hidden email]> wrote: There has been some discussion of the features desired in the next major release of NetRexx: jsr199, jsr223, regexp, list api, etc. Some of these items already have test implementations in experimental NetRexx versions. But it recently occurred to me that there is another critical area that needs support soon: multi-threading -- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Next major NetRexx release
|
|
On Sun, Jul 28, 2013 at 1:33 AM, George Hovey <[hidden email]> wrote:
> My understanding is that groups all over the world are trying to crack the > problem of parallelization of programming languages, and it has proven a > very tough nut. This looks like an interesting read http://www.vogella.com/articles/JavaConcurrency/article.html FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Next major NetRexx release
|
|
On Sun, Jul 28, 2013 at 2:01 AM, Fernando Cassia <[hidden email]> wrote:
> > This looks like an interesting read > http://www.vogella.com/articles/JavaConcurrency/article.html See also "Java concurrency without the pain" http://www.javaworld.com/javaworld/jw-06-2013/130619-j101-java-concurrency-part-1.html FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
I have used java threads on most occasions I needed parallelism, and they are not too hard; there have been developments in java that purportedly even make it easier.
However, I would be a big proponent of added multithreading support to NetRexx itself if we could do it the way that ooRexx designed it, with 'unguarded' methods and 'reply'. best regards, René. On 28 jul. 2013, at 06:04, Kermit Kiser <[hidden email]> wrote: > There has been some discussion of the features desired in the next major release of NetRexx: jsr199, jsr223, regexp, list api, etc. Some of these items already have test implementations in experimental NetRexx versions. But it recently occurred to me that there is another critical area that needs support soon: multi-threading > > Integrated circuit electronics speeds seem to have plateaued and processor manufacturers now increase power by adding more processors to each chip. Even tiny cell phone devices can now have quad processors. What seems to be lacking is computer language support to easily make use of that added power. I suggest that NetRexx would benefit from the addition of a simple api for making use of multiple processors. While such an api might not be able to cover all possible use cases, even handling simple cases would be valuable. > > Does anyone else see this feature as a useful addition? Are there any other significant areas of computing that should be considered for future support in NetRexx? > > -- Kermit > -- > Sent from my Android tablet with K-9 Mail._______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by George Hovey-2
Simple cases where it is needed are worker threads in user interface programs (like those in Java Swing interfaces), these need to run in parallel with the GUI thread because otherwise they lock up message dispatching, freezing the GUI. But there are a lot of algorithms around that benefit from parallellism/multithreading, and my take on it is that the simpler and safer the mechanism is, the more likely it is that the developer chooses to use it. I understood from reading the docs that all programs in Erlang are parallel by default; I quite like the ooRexx implementation and think it would be beneficial for people not wanting to delve deeply into JVM thread synchronization issues, but need to e.g. write a JVM GUI application in NetRexx - without threads those look really bad and unresponsive.
best regards, René. On 28 jul. 2013, at 06:33, George Hovey <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Fernando Cassia-2
yes, those were what I meant with the recent improvements. I think this new concurrency framework could serve our implementation better than plain old threads.
René. On 28 jul. 2013, at 07:04, Fernando Cassia <[hidden email]> wrote: > On Sun, Jul 28, 2013 at 2:01 AM, Fernando Cassia <[hidden email]> wrote: >> >> This looks like an interesting read >> http://www.vogella.com/articles/JavaConcurrency/article.html > > See also "Java concurrency without the pain" > http://www.javaworld.com/javaworld/jw-06-2013/130619-j101-java-concurrency-part-1.html > > FC > > -- > During times of Universal Deceit, telling the truth becomes a revolutionary act > Durante épocas de Engaño Universal, decir la verdad se convierte en un > Acto Revolucionario > - George Orwell > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
It sounds similar to the solution I used in my parallel program. That program has 66 subtasks which can run at the same time. The input data files are the same for the tasks and do not change. Output does not overlap. I use a pool of threads with a fixed but tunable number - currently equal to available processors plus one I think. The subtasks come from a task queue. It seems like a simple pattern that would cover a lot of cases. With a little adjustment it could even handle the case of requests that arrive asynchronously. My program used to take more than 20 minutes. Now it runs in about 3 minutes on my hex-core system, so improvements can be dramatic.
-- Kermit "René Jansen" <[hidden email]> wrote: yes, those were what I meant with the recent improvements. I think this new concurrency framework could serve our implementation better than plain old threads. -- Sent from my Android tablet with K-9 Mail. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Kermit,
I wonder if we can combine the closures issue (NETREXX-22) and the threads implementation into one solution using the Java 8 lambda expressions. My reasoning is as follows: 1) ooRexx has a nice, understandable multithreading approach, notation-wise, usable for NetRexx 2) if I am not mistaken, this approach also covers the ooRexx collection classes 3) Java 8 is mainly about lambdas and closures 4) These lambdas, apart from being en vogue, enable one to easier and more consistently implement multithreading 5) The Java collection classes are going to receive lambda support 6) an example of this support would be foreach(x = x + 42) on collections, and the implementation of default methods on interfaces (cf. http://www.lambdafaq.org ) Without generics, annotations and now lambdas there is a chance that Java will outrun NetRexx in functionality, i.e. that there is a only subset of Java programs that can be generated using NetRexx, and (worse) we cannot transparently interface anymore to all JVM code. It would be good if Mike and Rick could give us their vision on this, and suggestions for implementing these features within the cultural framework of the Rexx language. Of course, all views of non-language architects are also highly appreciated. best regards, René. On 30 jul. 2013, at 21:31, Kermit Kiser <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Next major NetRexx release
|
|
Urgent indeed! On Fri, Aug 2, 2013 at 5:42 AM, René Jansen <[hidden email]> wrote:
-- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |