Thanks to remind us. It skipped our mind. I will raise the point tomorrow and discuss with marcus. Stef
On 16 May 2019, at 20:26, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Any feedback on this? Did someone tried to use Smallapack in Pharo? Jimmie?
Le jeu. 25 avr. 2019 à 22:50, ducasse <stepharo@netcourrier.com <mailto:stepharo@netcourrier.com>> a écrit : Thanks nicolas. We will discuss this during the sprint tomorrow.
On 25 Apr 2019, at 22:43, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote:
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 <jlhouchin@gmail.com <mailto:jlhouchin@gmail.com>> 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 <jlhouchin@gmail.com <mailto:jlhouchin@gmail.com>> 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 <http://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 <jlhouchin@gmail.com <mailto:jlhouchin@gmail.com>> 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