Dear Elias, I saw some posts about this in the past, but my issues regarding basic functionality overrode my performance concerns at that time. Now that I believe basic functionality is getting good, my attention shifts to your issue. Several minutes to a fraction of a second to do anything bears investigation. I'd bet that, along with your test code, observations, and input, Juergen can improve this situation significantly.
This is certainly a very significant issue. Thanks. Blake On Sat, Jun 28, 2014 at 8:55 AM, Elias Mårtenson <[email protected]> wrote: > Well, there is a very specific case that is exposed when trying to build > up large arrays. That specific case has been discussed here a few times. > It's underlying cause is that GNU APL proactively copies the array it's > working on in case the user (i.e. the function that performs work on the > data) of that array modifies it. > > I have had a few stabs at solving this one, but none of my solutions have > been good enough yet. My experiments have, however, shown the potential for > improvement. For example, in the program below, the time taken to load a > 10k-line file was reduced from several munites to a fraction of a second: > > https://github.com/lokedhs/apl-tools/blob/master/io.apl#L8 > > Regards, > Elias > > > On 28 June 2014 21:44, Blake McBride <[email protected]> wrote: > >> Interestingly, I think performance could be the real ticket to a large >> resurgence of APL. The world has moved from faster processors to more >> processors (and threads). APL is unique in its ability for the programmer >> to express operations that can be parallelized. Ultimately, APL's ability >> to translate array operations into parallel operations will determine its >> success. As a first step, taking advantage of multiple cores is critical. >> Ultimately adding support for things like Nvidia Cuda would propel GNU APL >> into a leading language! >> >> I know Juergen has worked on getting GNU APL to effectively use multiple >> cores. I really didn't follow that much because, at the time, I was just >> looking for it to work. Currently, there are no open items I am aware of >> in terms of getting GNU APL to "work". I'm sure I and others will find >> more things as we use the system, but I am also confident that this is a >> significantly decreasing number. I am excited about all of this. >> >> In terms of your million row table, now that we've gotten as far as we >> have, I strongly encourage you to create a simple example of the speed >> issue you encountered for Juergen's evaluation. >> >> Thanks. >> >> Blake >> >> >> >> On Sat, Jun 28, 2014 at 8:18 AM, Elias Mårtenson <[email protected]> >> wrote: >> >>> I agree with the suggestion to implement more extensions. There are a >>> few really interesting ones such as the power operator. >>> >>> However, performance is something that needs to be worked on as well. >>> Right now there are cases where performance deteriorates very quickly, such >>> as when constructing and working with large arrays. Right now GNU APL is >>> pretty much impossible to work with for 2D arrays of ten thousand rows or >>> more. >>> >>> I had to work with a million row table once, and I very quickly gave up >>> the idea of using APL for it. >>> >>> Regards, >>> Elias >>> On 28 Jun 2014 21:10, "Blake McBride" <[email protected]> wrote: >>> >>>> Dear Juergen, >>>> >>>> Thanks. If you are using the Dyalog standard then you should match my >>>> (WASD custom) keyboard, so I'll be interested in the layout once you >>>> correct ]KEYBOARD. >>>> >>>> I am hoping you can included my WASD keyboard design and setup file >>>> with GNU APL. This would make a high quality GNU APL keyboard available to >>>> everyone. >>>> >>>> Lastly, as a tangent, I hoped that down the road, once GNU APL is very >>>> stable with respect to the IBM standard, you may start to add operators >>>> provided by other APL vendors - so long as they don't conflict with the IBM >>>> standard. If you did this, you would slowly start making use of more of >>>> the currently unused APL characters. >>>> >>>> Thanks for everything. Your system is very usable now. I really like >>>> it. GNU APL contained the critical mass needed to get me back into APL >>>> after a 30 year hiatus. I have spent a bunch of time getting my old tools >>>> up and running on your system from old printouts I had. I pretty much have >>>> that going now. I am looking forward to making real use of GNU APL and my >>>> old framework again. Thanks a lot!! >>>> >>>> Blake >>>> >>>> >>>> >>>> On Sat, Jun 28, 2014 at 7:33 AM, Juergen Sauermann < >>>> [email protected]> wrote: >>>> >>>>> Hi Blake, >>>>> >>>>> these days GNU APL is following Dyalog APL because they are selling >>>>> their keyboards (and >>>>> I bought one). I just had forgotten to update the ]KEYBOARD command; >>>>> the config files shipped >>>>> with GNU APL should already reflect the Dyalog layout. >>>>> >>>>> IBM seems to offer only APL keycaps, and Unicomp did not even bother >>>>> to answer an inquiry >>>>> that I sent them. >>>>> >>>>> /// Jürgen >>>>> >>>>> >>>>> >>>>> On 06/27/2014 07:41 PM, Blake McBride wrote: >>>>> >>>>> I noticed that for the ]KEYBOARD command, the comment symbol ⍝ appears >>>>> in two places; on the C key, and on the \ key. I think, perhaps, that >>>>> keeping it on the \ key and removing it from the C key makes sense for the >>>>> following reason. The Z, X, C, and V keys are often mapped to the very >>>>> convenient four characters each with a quad and one of the four arrow keys >>>>> (up, down, right, left) which are very useful for keyed or component file >>>>> IO. >>>>> >>>>> I also, regretfully, noticed that I created my custom keyboard using >>>>> the Dyalog standard rather than the standard used by GNU APL. Apparently, >>>>> both the Dyalog standard, and the GNU APL standard differ from the IBM >>>>> standard. Perhaps Standard is a poor word... >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> Blake >>>>> >>>>> >>>>> >>>>> On Fri, Jun 27, 2014 at 10:54 AM, Juergen Sauermann < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Fred is correct. I have updated the ]KEYBOARD command to show >>>>>> the new layout (as for dyalog keyboards). ⍙ is Alt-shift-. (two keys >>>>>> right from M). SVN 345. >>>>>> >>>>>> /// Jürgen >>>>>> >>>>>> >>>>>> >>>>>> On 06/27/2014 05:15 PM, Frederick H. Pitts wrote: >>>>>> >>>>>>> Elias, >>>>>>> >>>>>>> My keyboard is configured to have ⍶, ⍹, and ⍷ above ⍺, ⍵ and >>>>>>> ∊, >>>>>>> respectively, so that their locations are easy to remember. I would >>>>>>> have >>>>>>> liked to placed ⍙ above ∆ but that location was already occupied by >>>>>>> ⍋, >>>>>>> so I placed ⍙ above ⌊ on the 'd' key. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Fred >>>>>>> >>>>>>> On Fri, 2014-06-27 at 22:44 +0800, Elias Mårtenson wrote: >>>>>>> >>>>>>>> Any suggestions where I should put the ⍶ and ⍹ symbols on the Emacs >>>>>>>> keymap? The ]KEYB command doesn't display a mapping for them. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Elias >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >> >
