⎕TL threading

This topic is specifically for discussions on the new APL64 Project currently in development. This topic is open for all to browse. However, to post, one must have a registered account on the APLDN forum only available to APL+Win licensee under a current APL+Win Subscription.

Moderators: Tech Support, phpbb_admin

⎕TL threading

Postby Davin Church » September 26th, 2018, 2:15 am

Hooray!! This is wonderful! We really need something like this, even for improving responsiveness in business applications. I also think this will do great things for APL as a language, including competing better against other languages that can easily make use of multiple cores! Adding support for more primitive functions would be welcome as well.

However, I would also like to see this applied to operators -- especially Each. (Outer and Inner Products could be handled similarly to Each.) Sure, I sometimes have large vectors that can nicely benefit from multi-core processing. But WAY more often I need to call a small subroutine (self-contained with no side effects) on each element of a large array. This will benefit processing speed (in my applications, where I use them extensively) more than all the single primitive threadings put together.

Granted, multi-threading user-functions with side effects would be a significant problem, but I can think of a couple of potential ways around that. One way is to detect if the function can possibly produce any side effects (writing to globals, using Execute, or calling unsafe subroutines/APIs would be in that category) and only multi-thread it if it obviously had no way to produce side effects. Another possibility is to implement an operator such as APL2's "PEACH" (parallel-each) operator, to be used explicitly (in place of Each) to tell the interpreter that you WANT it split up onto multiple cores (and that you've determined that it's acceptable to do so).

In addition, if we can get in-line expression-functions or composed-functions, how about being able to multi-thread those with Each (and similar operators) as well? They shouldn't be any problem if we can already do limited user-defined functions and wouldn't have many of the complications found with user-defined functions.

So what might be the possibilities of multi-threading some operators here?
Davin Church
 
Posts: 577
Joined: February 24th, 2007, 1:46 am

Re: ⎕TL threading

Postby Davin Church » October 30th, 2018, 1:39 pm

In your 10/29 Q&A you talk about the problems involved in multi-threading the Each operator, and I agree that there are many difficult issues. (And I don't mind discussing technical details about how some of them could be dealt with.) But I think that providing it is terribly important to the language as a whole. For instance, in my applications I would probably need this kind of threading at least 95% of the time as compared to all the single primitives added together. Having a primitive arithmetic operation multi-thread is very important for a certain small subset of applications that deal with huge arrays with primitive functions, but outside that area almost everything is going to need to use Each.

For instance, take a trivial example that I run into a lot ... a long nested vector of character strings needs to have spaces trimmed off the end of each item. I can run my utility function on it with Each to do them all, but this really needs to be done in parallel across multiple cores for speed. If I can't do it with my user-defined function, then I'll want to do something like:
Code: Select all
      (-+/¨^\¨' '=⌽¨X)↓¨X
But this also requires heavy (and multiple) uses of Each, which still need to be distributed across cores. And I don't want to have to change my coding style (or existing code) to make use of it.

Much work that needs threading is of a similar form, small little expressions to be repeated many thousands of times, embedded in a line of code (even several times per line). This is not a reasonable thing to be distributing via either Web Services, :FOR, or :FORK(?). It really needs to be handled implicitly and automatically within a line of code without the programmer using other facilities or taking any explicit steps to invoke it.

This leads to my other reason, about the APL language in general. APL is built from the ground up to be an array processing language and is best suited (IMHO) to make use of multiple cores without any changes to our applications or style of programming at all. I think it's terribly important that we provide such an invisible way to multi-thread to the programming community at large, to give them incentive to use APL instead of having to force their way through programming in other languages to do it the hard way (with explicit invocations everywhere they can afford to add them). This makes APL much faster overall, since every major operation could make use of many cores without requiring lots of explicit programming for each one. If we (as APL programmers) want APL to flourish in the larger programming community, then I think this one specific feature would be the most useful and important thing we could do of any language feature we have to offer or are planning for. I think it is well worth, in the long term, a LOT of extra effort to make sure this capability is available and seamless to the world at large.
Davin Church
 
Posts: 577
Joined: February 24th, 2007, 1:46 am


Return to APL64 Project

Who is online

Users browsing this forum: No registered users and 1 guest

cron