MacResearch

The response below is correct. I just thought I would add that accessing vecLib directly is deprecated. We keep it around for pre-MacOS X.3 apps. You should be using -framework Accelerate at link time and #include {less than sign}Accelerate/Accelerate.h{greater than sign} to use the headers.

Our LAPACK is callable from C/C++/ObjC/ObjC++ and fortran

http://developer.apple.com/hardware/ve/vector_libraries.html

It is difficult to anticipate your motivations for wanting a C++ library.

Most of the time, when I read requests for a C or FORTRAN library to have C++ interfaces, it is usually because the requester wants the degree of syntactic sugar he is accustomed to in the rest of his C++ application. Probably due to my own perverse tendencies to write mostly in C and occasionally in assembly -- these are the most useful when writing actual high performance code -- it is difficult for me to fully empathize with such a requirement. Largely it seems to me, such attempts are simply trading inherent quality for cosmetic beauty, a cosmetic beauty that your users will never see.

In any case, if you are looking for syntactic sugar, a cursory glance at lapack++ suggests it will not disappoint. With apologies to the developers of lapack++, who certainly know more about this product than I do, I don't see much meat here. In my book, that would include vector code, intelligent cache blocking, etc. The library, to it's credit, does appear to call through to the standard LAPACK/BLAS rather than trying to do the heavy lifting itself.

There is a place for C++ in HPC, as products like MacSTL and Blitz++ demonstrate. Unfortunately, I don't see much evidence of that sort of effort here.

Regardless of motivation, you should be able to use the C interfaces to the LAPACK in Accelerate.framework just like any other C programming interface that you are using without any trouble. Apple has wrapped the declarations with extern "C" {} to make sure the linkage is usable from C++. Just call them normally. The routines are all in the clapack.h header in Accelerate.framework.

Hello again,

My main motivations for wanting the C++ library were portability of the code to other OS and simplicity. But as I am not an expert I might be wrong.

I would define myself more as a physicist than a programmer. So I always try to get a good compromise between the time I need to program a code and the time I effectively use it for my research.

I will follow your advice and see I can make it work well this way.

Thanks
jc

Hi Justin,

Indeed these are things I'm hoping to cover in the performance tutorial. Unfortunately with the holidays/MacWorld etc... it's been slower to get published. I actually have most of the tutorial examples, it's a matter of writing it up. I will expedite this.

Can you provide a bit more information on what specifically you are trying to accomplish? Perhaps I can whip up something quickly to get you started. For example, are you just not sure how to use the performance libraries, which functions to use for a certain task?

Thanks,

Dave

I'm making a sort of 3D molecular spectra plotting program. All of the OpenGL and GL Shading Language work is done, but the matrix diagonalizations that pick the energy levels are done using scalar "numerical recipes" style C algorithms. These diagonalize sparse matrixes around 60x60 elements in size. This all works fine, but I now need to deal with much larger systems that are also more dense. I could use the algorithms I already have, but I would like my application to be fast enough to be interactive. This all seems to point me into using Accelerate Frameworks.

My confusion is about what data types to use and how to make function calls. I'm unclear when I need to use LAPACK specific types (and how to define them / allocate memory for them) so that things aren't accidentally processed by scalar operations. I'm also unclear on what consequences come with calling Fortran functions from C. When do I pass the pointer vs. the variable itself.

Again, I don't think I'm going to be pushing the boundaries of computing with this project, but I find it to be a good excuse to learn how to do simple diagonalizations, matrix dot products and outer products using LAPACK.

Thanks for all your help. This site has already saved me loads of time.
Justin

I think this is something that would fit perfectly well into Accelerate. If you have specific details of what you'd like to see implemented, source code snippets or URLs/PDFs that describe in detail what you'd like, MacResearch can help file feature requests. If you'd like to work on something like this (in terms of getting a feature request in) you can post information here, or feel free to contact me via email: sdg0919 AT gmail dot com .

Regards,

Dave

Hello everyone I am new to the community where previously I used Windows as an operating system and LINUX as a programming environment. I use FORTRAN 77,90,95 to do my computations so I have lots of questions.

1. I have downloaded a free g77 and gfortran compiler for intel based MACS but the path is set to /usr/local/bin where my path is /usr/bin:sw/bin. I want to know is there a way to set the path permanently in the bash shell I have tried export $PATH:/usr/local/bin and the like but nothing seems to work. I have tried to change the etc/profile but its permissions are for root and it is only a read only file I have tried chown and chmod but my permissions are denied. I am able to set the path temporarily but I need permanent. Any suggestions. Also I am a bit of a novice at UNIX/LINUX commands I know just enough to stumble around in it.

2. I use LAPACK and BLAS extensively in my work. Is there support for the intel MAC OS X10.4. In the LAPACK makefile there isn't any support for 10.4 intel machines.

Your responses and patience is extremely appreciated.

ARW