[squeak-dev] Smallapack

Yoshiki Ohshima Yoshiki.Ohshima at acm.org
Tue Aug 9 22:26:02 UTC 2016


Correction: (sorry)

In a 64 bit image, TestCBlas runs fine but the ones listed above fails
in a 32-bit image.

On Tue, Aug 9, 2016 at 3:12 PM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org> wrote:
> Thanks!
>
> I am trying this from a vanilla 5.0 image and I see that
> ConfigurationOfSmallapack-nice.18 is loaded.  Now, however, the
> following tests from Smallapack-SUnitTests category fail:
>
> #('TestCBlas>>#testCsscal' 'TestCBlas>>#testSaxpy'
> 'TestCBlas>>#testSgemv' 'TestCBlas>>#testSgemvTrans'
> 'TestCBlas>>#testSger' 'TestCBlas>>#testSscal' 'TestCBlas>>#testStrsm'
> 'TestLapackMatrix>>#testMatrixProduct' 'TestLapackMatrix>>#testSum'
> 'TestRandMatrix>>#testOperationTiming')
>
> As I wrote, TestCBlas used to be all green.  I'll check what has
> changed since -nice.16...
>
> On Sat, Aug 6, 2016 at 4:56 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> This should be fixed in ConfigurationOfSmallapack-nice.18
>> BTW, I think you can provide the absolute path to the .dylib instead of
>> copying in local repository...
>>
>>
>> 2016-08-06 23:29 GMT+02:00 Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com>:
>>>
>>> Hi Yoshiki,
>>> thanks for reporting, I'll try better...
>>>
>>>
>>> 2016-08-01 0:48 GMT+02:00 Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>:
>>>>
>>>> I see you have some changes but it appears that evaluating the
>>>> Installer do it goes into an infinite loop of #moduleName and
>>>> #masOsxModuleName.
>>>>
>>>> (Thanks again!)
>>>>
>>>> On Sat, Jul 30, 2016 at 8:23 AM, Yoshiki Ohshima
>>>> <Yoshiki.Ohshima at acm.org> wrote:
>>>> > But some of TestLapackMatrix tests fail.  A few external functions
>>>> > cannot be found, it looks like.
>>>> >
>>>> > On Sat, Jul 30, 2016 at 7:55 AM, Yoshiki Ohshima
>>>> > <Yoshiki.Ohshima at acm.org> wrote:
>>>> >> Great!
>>>> >>
>>>> >> Before (I got into a meeting and then entered the "Friday mode", I was
>>>> >> going down the path of trying to call the Framework functions but
>>>> >> copying files anyway was a simpler solution for now.
>>>> >>
>>>> >> Yes, I got all tests green.  Thank  you!
>>>> >>
>>>> >> On Fri, Jul 29, 2016 at 3:24 PM, Nicolas Cellier
>>>> >> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> >>> OK, what I did on my Mac:
>>>> >>>
>>>> >>> 1) look under the Squeak app and edit the Contents/Info.plist
>>>> >>> 2) change value of SqueakPluginsBuiltInOrLocalOnly to "No"
>>>> >>>    otherwise library loading is restricted to the Squeak app bundle
>>>> >>> 3) copy the veclib framework library files (dylib) in same directory
>>>> >>> as
>>>> >>> squeak image
>>>> >>> 4) launch Squeak
>>>> >>> 5) install Smallapack
>>>> >>>     follow instruction from
>>>> >>>
>>>> >>> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak
>>>> >>> 6) change CBlasLibrary class>>moduleName 'libcblas.dylib' ->
>>>> >>> 'libBlas.dylib'
>>>> >>>     nowadays, cblas and blas are in the same dylib...
>>>> >>> 7) change CLapackLibrary class>>moduleName 'libclapack.dylib' ->
>>>> >>> 'libLapack.dylib'
>>>> >>>     idem
>>>> >>> 8) re-initialize the cache (I know, I know, there are too many...)
>>>> >>>     CBlasLibrary install. CLapackLibrary install. LapackMatrix
>>>> >>> resetBlasInterfaces; resetLapackInterfaces.
>>>> >>> 9) run the TestCBlas suite
>>>> >>>
>>>> >>> It should be green
>>>> >>> I will commit the changes later, and will probably implement
>>>> >>> moduleNames as
>>>> >>> a Preference (pragma oriented).
>>>> >>> No need to override code anymore :)
>>>> >>>
>>>> >>> I think step 3) is necessary because of ioLoadModuleRaw() in
>>>> >>> platforms/iOS/vm/OSX/sqMacUnixExternalPrims.m
>>>> >>>
>>>> >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/iOS/vm/OSX/sqMacUnixExternalPrims.m
>>>> >>> It would only look those frameworks:
>>>> >>>
>>>> >>>                 static char *frameworks[]=
>>>> >>>                 {
>>>> >>>                         "",
>>>> >>>                         "/CoreServices.framework/Frameworks",
>>>> >>>                         "/ApplicationServices.framework/Frameworks",
>>>> >>>                         "/Carbon.framework/Frameworks",
>>>> >>>                         0
>>>> >>>                 };
>>>> >>>
>>>> >>> But I did step 3) before I tried 1) + 2), adn did not retry, so maybe
>>>> >>> I'm
>>>> >>> wrong...
>>>> >>> Scanning all the frameworks is not a solution. And what if we want a
>>>> >>> specific version?
>>>> >>> It would be far better to be able to specify the path to the library
>>>> >>> from
>>>> >>> within the image like VW...
>>>> >>>
>>>> >>>
>>>> >>> 2016-07-29 19:41 GMT+02:00 Nicolas Cellier
>>>> >>> <nicolas.cellier.aka.nice at gmail.com>:
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> 2016-07-29 19:28 GMT+02:00 Nicolas Cellier
>>>> >>>> <nicolas.cellier.aka.nice at gmail.com>:
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> 2016-07-29 19:02 GMT+02:00 Yoshiki Ohshima
>>>> >>>>> <Yoshiki.Ohshima at acm.org>:
>>>> >>>>>>
>>>> >>>>>> First question:
>>>> >>>>>>
>>>> >>>>>> The Mac OS comes with Accelerate.Framework and that contains BLAS.
>>>> >>>>>> But probably I still should compile those libraries, right?
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>> No, it's better to link to accelerated library.
>>>> >>>>> I don't have a Mac handy here to verify how to link to it though.
>>>> >>>>> I'll be able to check latter in the evening
>>>> >>>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> I've downloaded the code, and I see it now: the library names are
>>>> >>>> hardcoded (see implementors of moduleName).
>>>> >>>> For Mac it is libblas.dylib and libcblas.dylib
>>>> >>>> Also note that there is a preference for switching to cblas (blas
>>>> >>>> functions with C interface).
>>>> >>>> This should be faster because we pass some parameters by value
>>>> >>>> rather than
>>>> >>>> allocating them and pass reference...
>>>> >>>>
>>>> >>>> Module names could also be replaced by Preferences eventually, but
>>>> >>>> by now,
>>>> >>>> you'll have to override...
>>>> >>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> On Thu, Jul 28, 2016 at 4:11 PM, Yoshiki Ohshima
>>>> >>>>>> <Yoshiki.Ohshima at acm.org> wrote:
>>>> >>>>>> > Thanks!
>>>> >>>>>> >
>>>> >>>>>> > On Thu, Jul 28, 2016 at 4:04 PM, Nicolas Cellier
>>>> >>>>>> > <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> >>>>>> >> Hi Yoshiki,
>>>> >>>>>> >>
>>>> >>>>>> >> Thanks for inquiring about Smallapack.
>>>> >>>>>> >>
>>>> >>>>>> >> This problem has been solved in 2011 as the post tells.
>>>> >>>>>> >> Moreover, it was about alignment of squeak objects that was on
>>>> >>>>>> >> multiple of 4
>>>> >>>>>> >> on SqueakV3 memory.
>>>> >>>>>> >> Spur is 8 byte aligned, so the problem would have also vanished
>>>> >>>>>> >> without any
>>>> >>>>>> >> patch for those being patient :)
>>>> >>>>>> >>
>>>> >>>>>> >> For the 15 arguments limit, Smallapack comes with it's own
>>>> >>>>>> >> compiler,
>>>> >>>>>> >> so it's
>>>> >>>>>> >> a non issue.
>>>> >>>>>> >> Maybe I should make the documentation more clear on
>>>> >>>>>> >>
>>>> >>>>>> >>
>>>> >>>>>> >> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak
>>>> >>>>>> >> ?
>>>> >>>>>> >>
>>>> >>>>>> >> Unfortunately, there's no Sparse Matrix representation in
>>>> >>>>>> >> Lapack.
>>>> >>>>>> >> If you know of a good package for that, it could be integrated.
>>>> >>>>>> >>
>>>> >>>>>> >> If you have other questions, don't hesitate to ask.
>>>> >>>>>> >>
>>>> >>>>>> >> cheers
>>>> >>>>>> >>
>>>> >>>>>> >> Nicolas
>>>> >>>>>> >>
>>>> >>>>>> >> 2016-07-29 0:22 GMT+02:00 Yoshiki Ohshima
>>>> >>>>>> >> <Yoshiki.Ohshima at acm.org>:
>>>> >>>>>> >>>
>>>> >>>>>> >>> I am trying to do a bit of linear algebra stuff that involves
>>>> >>>>>> >>> to
>>>> >>>>>> >>> solve
>>>> >>>>>> >>> a sparse 2D matrix (for a variation of doing least square
>>>> >>>>>> >>> fit).
>>>> >>>>>> >>>
>>>> >>>>>> >>> There was a message from Nicolas:
>>>> >>>>>> >>>
>>>> >>>>>> >>>
>>>> >>>>>> >>>
>>>> >>>>>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/161113.html
>>>> >>>>>> >>>
>>>> >>>>>> >>> Is this where it stands today, too?  It looks like that arg
>>>> >>>>>> >>> count
>>>> >>>>>> >>> problem is still there in 5.0, but is it in a way non-issue as
>>>> >>>>>> >>> it is
>>>> >>>>>> >>> still FFI based?
>>>> >>>>>> >>>
>>>> >>>>>> >>> Thanks!
>>>> >>>>>> >>>
>>>> >>>>>> >>> --
>>>> >>>>>> >>> -- Yoshiki
>>>> >>>>>> >>>
>>>> >>>>>> >>
>>>> >>>>>> >>
>>>> >>>>>> >>
>>>> >>>>>> >>
>>>> >>>>>> >
>>>> >>>>>> >
>>>> >>>>>> >
>>>> >>>>>> > --
>>>> >>>>>> > -- Yoshiki
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> --
>>>> >>>>>> -- Yoshiki
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> -- Yoshiki
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > -- Yoshiki
>>>>
>>>>
>>>>
>>>> --
>>>> -- Yoshiki
>>>>
>>>
>>
>>
>>
>>
>
>
>
> --
> -- Yoshiki



-- 
-- Yoshiki


More information about the Squeak-dev mailing list