I've just published a new ConfigurationOfSmallapack Currently, there is one test failing because I did not finish the support of LegacyFFI for invoking methods with more than 15 arguments (see below). The other tests are passing, so you may try it now.
gory details: The failing test requires the Opal Compiler to generate fallback code for invoking primitive 117 (ExternalFunction invokeWithArguments:) under the hood... Old Compiler workaround was hackish, and is extremely complex to implement in cleaner Opal architecture (Old compiler enabled mixing AST rewrite/code generation phase without a problem) The plan was either to enhance primitive 120 to handle the case of many arguments passed through a single array... Or to switch to UnifiedFFI (but even there, I don't remember if invoking primitive 117 was that straight forward...) Le jeu. 25 avr. 2019 à 20:16, Jimmie Houchin <[email protected]> a écrit : > Thanks. > > I appreciate your working to make this happen. No pressure from me on > time. I am blessed that you are contributing this to the community and that > I can benefit from your labors. At your convenience. > > I look forward to using Smallapack when available. I am thrilled to be > able to stay with Pharo and not have to use Python/Numpy. :) > > Thanks. > > Jimmie > > > On 4/25/19 12:38 PM, Nicolas Cellier wrote: > > Hi Jimmie, > The Metacello Configuration is not ready for Pharo7. > I have succeeded in loading Smallapack yesterday without Metacello, and > could run some of the tests. > I had to modify a few methods because of Pharo refactorings, and there is > still some work to make it fully operational. > When ready, I'll update the Metacello configuration and keep you informed. > > Le jeu. 25 avr. 2019 à 19:06, Jimmie Houchin <[email protected]> a > écrit : > >> When I attempt to install via Metacello in Pharo 7, I get the following >> warning. >> >> This package depends on the following classes: >> Parser >> MessageAsTempNode >> Compiler >> MessageNode >> >> >> I do not know how to proceed from there. Any help greatly appreciated. >> >> Thanks. >> >> Jimmie >> >> >> On 4/24/19 12:20 AM, Nicolas Cellier wrote: >> >> Hi, >> I recommand inquiring about Smallapack, the Smalltalk interface to >> LAPACK, on squeaksource.com or github. You'll get the speed of numpy. >> There is a Metacello configuration. I have not checked the port on current >> Pharo, but I can reactivate if there is some interest. >> >> Le mer. 24 avr. 2019 à 05:55, Jimmie Houchin <[email protected]> a >> écrit : >> >>> I just recently discovered FloatArray by accident. >>> >>> I was close to having to use Python/Numpy due to considerable >>> performance differences. Performance is very important. >>> >>> In one of my test using a 212000 item array of floats and doing a sum on >>> each iteration through the array Pharo was taking 17 minutes verses >>> Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40 >>> seconds. That is acceptable. >>> >>> However when looking at the FloatArray comment it says it uses 32bit >>> floats. I need 64bit. I don't even know where to look to create 64bit >>> FloatArrays. I am surprised that they didn't get converted when moving >>> to 64bit Pharo. >>> >>> Would I need to change VM source? Compile a new VM and create image side >>> classes? I have not messed with VM in years. I do not know where the >>> FloatArray plugin would be. >>> >>> Any pointers would be a great help. If this needs to be on the vm-dev >>> list I can move it there. >>> >>> Thanks. >>> >>> Jimmie >>> >>> >>>
