I don't have any experience with either Swift or Metal, but I already had a quick look at Swift as a programming language. My first impression is that Swift will be fast enough for scientific computing. In the keynote presentation they already showed that in some cases it can be faster than Objective-C. That is due to new language features that are more high-level, but because of this allow for better compiler optimizations. The underlying Objective-C runtime is already highly optimized and very fast. The only disadvantage I see is the lack of compatible scientific libraries written directly for Swift. It is possible to interface with C and C++, but programming can only be efficient in Swift if you have an interface optimized for the language. That means that you need to write your own wrapper classes for existing libraries.

I also had a quick look at the link you provided on Metal compute shaders. It looks all straight forward. Since Apple conceived OpenCL I guess they know what they are doing here. Though Apple has the best OpenCL wrappers around. It seems that similar wrappers are still missing for Metal. What I don't like about the compute shader kernels is that their syntax is closer to graphics shader programming than to regular function calls like in CUDA or OpenCL. If you already know OpenGL and GLSL this approach is easy to understand, but for the regular scientific programmer this concept is harder to grasp. You need to know a little bit about graphics hardware to understand the concepts. I don't expect Metal to be faster than OpenCL. Therefore, I suggest trying to use Swift with OpenCL in the hope that Apple's OpenCL wrappers can also be used with Swift.

I cannot say if developing with Swift and Metal will perform nicely since I've never worked with any of the above. My first hunch however is that you won't get the kind of performance you're expecting. Swift is mostly an app language and MeTaL is php based. Not the best starting point for high performance.

The first languages you've spoke of firstly (C,Fortran) are, typically, languages considered to be good for high performance since they work closer to the machine and only work compiled (Java is a bit different). Yes, it's true that you can cut quite a bit of development time with high-level languages but I wouldn't expect the same performance for programs with some complexity.

There was another recent topic where these points were being debated (https://www.researchgate.net/post/How_can_I_choose_the_right_programming_language_for_a_computational_physics_project). I believe most people that avoided using low-level languages (C, Fortran, C++, although it's debatable what low-level is nowadays) coded in Python, Ruby (free), Mathematica and Matlab (commerical).

I would also like to contribute with an opinion about using swift for teaching purposes. Is it not a bit biased to use a language made specifically for apple equipment? I mean, what if a student prefers windows or any of the Linux o.systems? Personally I would go with something a bit more cross-platform.

Sorry for not giving you information based on swift+metal experience but I hope it can help.

Pedro - Thanks

re. teaching - I am of the view that once you can programme in one language then almost all of them become available so I do not see this as platform limitation. I would like to see playground type IDE's for other languages as my preference is for the IDE not the language here.

re. Metal - sorry - perhaps I should have been more clear - I mean apples new GPU API here not the metaL language. Please see this link for clarification:

https://developer.apple.com/library/prerelease/ios/documentation/Miscellaneous/Conceptual/MTLProgGuide/Introduction/Introduction.html

Hi Mark,

Thanks for introducing the subject, I didn't know about either technology at all. I liked the presentation of swift, and the good news for me is that it is backed up by LLVM, which is a "platform?" which enables both bytecode/interpreted execution or natively compiled execution. In my opinion, there are no hindrances in sight performance-wise, except for the language itself, of which I can give no opinion.

Following your link to Metal, and after quick skimming, I got the impression that it is too much graphics centered. On a first look I have only seen: textures, blit, stencil... but have found no reference to general-purpose programming.

Cheers,

Fernando

Fernando:

Thank you very much for your point about LLVM.

In terms of Metal there seem to exist matrix routines already built into the standard libraries. There also seems to be a data parallel compute facility https://developer.apple.com/library/prerelease/ios/documentation/Miscellaneous/Conceptual/MTLProgGuide/Compute-Ctx/Compute-Ctx.html#//apple_ref/doc/uid/TP40014221-CH6-SW1

As with cuda the main focus is graphics and games programming but as many games need physics engines so I am hopeful that there would also be capability for real physics simulations.

Ops. Sorry, I thought you meant inter-language integration. Until now I've never of the Metal API so can't really contribute on the subject. Nevertheless best of luck.

I don't have any experience with either Swift or Metal, but I already had a quick look at Swift as a programming language. My first impression is that Swift will be fast enough for scientific computing. In the keynote presentation they already showed that in some cases it can be faster than Objective-C. That is due to new language features that are more high-level, but because of this allow for better compiler optimizations. The underlying Objective-C runtime is already highly optimized and very fast. The only disadvantage I see is the lack of compatible scientific libraries written directly for Swift. It is possible to interface with C and C++, but programming can only be efficient in Swift if you have an interface optimized for the language. That means that you need to write your own wrapper classes for existing libraries.

I also had a quick look at the link you provided on Metal compute shaders. It looks all straight forward. Since Apple conceived OpenCL I guess they know what they are doing here. Though Apple has the best OpenCL wrappers around. It seems that similar wrappers are still missing for Metal. What I don't like about the compute shader kernels is that their syntax is closer to graphics shader programming than to regular function calls like in CUDA or OpenCL. If you already know OpenGL and GLSL this approach is easy to understand, but for the regular scientific programmer this concept is harder to grasp. You need to know a little bit about graphics hardware to understand the concepts. I don't expect Metal to be faster than OpenCL. Therefore, I suggest trying to use Swift with OpenCL in the hope that Apple's OpenCL wrappers can also be used with Swift.

Dear Simon,

Concerning your point about native scientific libraries and a potentially reduced performance when interfacing C/C++ libraries, I think LLVM can provide a very good solution here. LLVM based compilers, such as Clang (http://clang.org/) and Swift itself, can compile to a very expressive IR (intermediate representation) code, which still allows for heavy transformations. It is kind of an assembler with a powerful type system. At this point, I believe that different languages can be mixed and optimized together. So maybe compiling C/C++ libraries with Clang to IR could provide an intermediate solution with very good performance.

Cheers,

Fernando

Fernando, let me clarify that. I didn't mean that the compiled code will not be efficient. I meant that you will loose the efficiency while you are programming. The advantage of Swift over Objective-C, and possibly also C++, is that it is higher-level than the other two and behaves more like a scripting language. Usually, it is more efficient to write code in a scripting language than in traditional compiled languages (which doesn't mean that the code is more efficient). Having to interface with other languages either reduces your efficiency in programming or you'll need good wrappers. Due to the lack of good wrappers you will have to write them on your own which will take up some time. I think the only reason to switch to Swift is because it can take less time to write your software. But, this is not true yet for scientific software because there are no suitable libraries or wrappers available.

Hello Dr Mark

I would like to point out that CUDA Fortran is available on MAC with a free license through PGI. I have used PGI's CUDA Fortran with several accelerating online libraries for a solving linear systems of equations (dense and sparse) and in some cases where there were huge clusters of data, the solution time dramatically dropped from 3 hours to a mere 10 seconds on a cheap NVIDIA GPU. It is also possible through PGI to simultaneously use C and Fortran for different parts of a larger program through the known ISO_C_Binding technique in the case you would like to call on Fortran. I suggest you give it a try. 

I have tried making a couple of device (GPU) codes that compute certain coefficients in my scope of computational mechanics ... and I must say that altering a nested loops to parallel process is a hefty process but extremely beneficial in GFLOPs intensity once you have reached a satisfactory code meanwhile producing the exact same results you would have attained from a serial CPU code.

http://www.pgroup.com/products/freepgi/

OK - we have messed around with this for a while - Swift is great but Metal is a bit difficult for this - beginning to come to the view that what would be best might be a numerical analogue of Scene Kit (like a swift version of the Accelerate Framework used to do for objective c).

There is an interesting "Introduction to the Accelerate Framework in Swift" here https://www.appcoda.com/accelerate-framework/