I am wondering if there are any plans to introduce a Swift-based Metal Shading Language in the future to replace (or be available along) the current c++-based language.
It would be great to use Swift for GPU-accelerated data-parallel tasks (e.g. ML).
Any thoughts?
-g.
I would very much like to see this. Perhaps not Metal per se, but the ability to compile code to a heterogenous architecture.
I’ve been mulling two sets of ideas that might be steps in that direction:
— making the simd.h types (double4, float2, etc) first class types in Swift
— introducing the concept of purely functional (or some other suitably constrained) closures that could be easily complied to parallel/vectorized architectures
I’d love to get to a point where GCD could handle GPU/SIMD/CPU execution without needing a whole separate language— even if only for a subset of applications. It seems like Swift has been laying a lot of the ground work to move in that direction.
On Jul 9, 2016, at 09:59 , Georgios Moschovitis via swift-evolution <swift-evolution@swift.org> wrote:
I am wondering if there are any plans to introduce a Swift-based Metal Shading Language in the future to replace (or be available along) the current c++-based language.
It would be great to use Swift for GPU-accelerated data-parallel tasks (e.g. ML).
Any thoughts?
-g.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I *think* it'd be better to add C++ interoperability to Swift. A post from a long long time ago (http://article.gmane.org/gmane.comp.lang.swift.evolution/2899\) suggests this would likely be possible (but I'd assume not in time for Swift 3).
This isn't an area I know much about, though.
- Dave Sweeris
Sent from my iPhone
On Jul 9, 2016, at 11:59, Georgios Moschovitis via swift-evolution <swift-evolution@swift.org> wrote:
I am wondering if there are any plans to introduce a Swift-based Metal Shading Language in the future to replace (or be available along) the current c++-based language.
It would be great to use Swift for GPU-accelerated data-parallel tasks (e.g. ML).
Any thoughts?
-g.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I *think* it'd be better to add C++ interoperability to Swift.
Wouldn’t it be better to have unified syntax across the board? e.g.,
int x; -vs- x: Int, etc?
Using the same language/syntax would eliminate the taxing mental context-switch.
Perhaps not Metal per se, but the ability to compile code to a heterogenous architecture.
+1
It seems like Swift has been laying a lot of the ground work to move in that direction.
I have the same *feeling* but I am wondering if there is any substance in this or it’s just wishful thinking.
I disagree. While it sounds nice to have a unified syntax working on C++ compatibility/interaction is still quite key because of the mountains of legacy and new code still written everyday in it. Also, I think that the right language for the right domain and being able to glue them together is quite key in the modern computing world and using a single language in every computing domain is a chimera that can bring more pain than good.
Still, if we work out how to import C++ code well, you are probably going to get something very close to that you are wishing anyways :).
Sent from my iPhone
On 10 Jul 2016, at 07:17, Georgios Moschovitis via swift-evolution <swift-evolution@swift.org> wrote:
I *think* it'd be better to add C++ interoperability to Swift.
Wouldn’t it be better to have unified syntax across the board? e.g.,
int x; -vs- x: Int, etc?
Using the same language/syntax would eliminate the taxing mental context-switch.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I don't understand. That's the point of C++ interop... You call the C++ APIs from your Swift code.
On Jul 10, 2016, at 01:17, Georgios Moschovitis <george.moschovitis@icloud.com> wrote:
I *think* it'd be better to add C++ interoperability to Swift.
Wouldn’t it be better to have unified syntax across the board? e.g.,
int x; -vs- x: Int, etc?
Using the same language/syntax would eliminate the taxing mental context-switch.
working on C++ compatibility/interaction is still quite key because of the mountains of legacy and new code still written everyday in it.
Totally agree, but C++ interoperability is orthogonal to my original request. Would love to have both!
Also, I think that the right language for the right domain and being able to glue them together is quite key in the modern computing world and using a single language in every computing domain is a chimera that can bring more pain than good.
I disagree. IMO, the ‘babel’ of programming languages is one of the most annoying problems in our industry. Besides, I don’t see how C++ is any more suitable than Swift for GPU/heterogenous stuff (without peculiar extensions like CUDA). Swift is starting from a clean-slate, and could definitely become a ‘right’ language for this domain.
I feel like there are two totally different discussions happening here. One is whether Swift needs better interoperability with C++, which it does. Let’s just assume that that will happen.
The other discussion, which I think was the intended topic of this thread, is whether the benefits of parallel computing can be brought closer to Swift, which I believe they can.
In most applications, if we can get 80% of the benefit of new hardware with minimal code rewrites, most developers would take that in a heartbeat and focus the specialized talent and careful efforts necessary to craft, profile and maintain truly optimized code on only the most critical kernels. Maybe that critical code will be written in C++, or some other language better suited to the task.
Is there a good reason why Swift can’t be made as suitable— or more suitable— than C++ for the 80% kinds of tasks? It seems to me that Swift would be well suited for it.
On Jul 10, 2016, at 01:41 , Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPhone
On 10 Jul 2016, at 08:50, Georgios Moschovitis <george.moschovitis@icloud.com> wrote:
working on C++ compatibility/interaction is still quite key because of the mountains of legacy and new code still written everyday in it.
Totally agree, but C++ interoperability is orthogonal to my original request. Would love to have both!
Also, I think that the right language for the right domain and being able to glue them together is quite key in the modern computing world and using a single language in every computing domain is a chimera that can bring more pain than good.
I disagree. IMO, the ‘babel’ of programming languages is one of the most annoying problems in our industry. Besides, I don’t see how C++ is any more suitable than Swift for GPU/heterogenous stuff (without peculiar extensions like CUDA). Swift is starting from a clean-slate, and could definitely become a ‘right’ language for this domain.
Also, call me when we get a port of either OpenCL or CUDA bindings in Swift. Hint: it is more likely for Swift to have working C++ integration first than to wait for those to happen.
We can talk about Swift, Rust, Kotlin, Eiffel, Scala, etc... but they are still relatively niche and before any of those gets anywhere near the strong worldwide cross platform following that JavaScript (with the explosion of Node.JS too), Ruby, C/C++, Java, and C#/.NET still have, we will need to keep nurturing and strengthening this language and tools for a while longer.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
working on C++ compatibility/interaction is still quite key because of the mountains of legacy and new code still written everyday in it.
Totally agree, but C++ interoperability is orthogonal to my original request. Would love to have both!
Also, I think that the right language for the right domain and being able to glue them together is quite key in the modern computing world and using a single language in every computing domain is a chimera that can bring more pain than good.
I disagree. IMO, the ‘babel’ of programming languages is one of the most annoying problems in our industry. Besides, I don’t see how C++ is any more suitable than Swift for GPU/heterogenous stuff (without peculiar extensions like CUDA). Swift is starting from a clean-slate, and could definitely become a ‘right’ language for this domain.
DSL's sometimes emerge to esse programming challenges, but often arise out of need to dominate the complexity of a domain by catering exclusively to it instead of a jack of all trades - master of none approach. In some cases, the ability to easily approach problems in a deterministic low level way, as well as the wealth of existing code dealing with those problems, is how C and C++ are still very very relevant. The rest is increasingly dominated by JavaScript and Node where performance at a very low power is not critical.
C++ gives you rope to hang yourself with, but in capable hands it gives you all the knobs and levers you need to extract high performance with a very high degree of determinism.
Garbage collection, automatic reference counting, pass by copy value types with or without copy on write semantics, etc... there are several areas where other languages keep you abstracted from the hardware in a way that does not make performance predictable.
Memory fragmentation, control of allocations of stack and heap memory (preferably away from hot game loops), no extra performance hit when passing memory reference around or iterate on collections (yes people can destroy performance in not very obvious ways too).
Sent from my iPhone
On 10 Jul 2016, at 08:50, Georgios Moschovitis <george.moschovitis@icloud.com> wrote:
working on C++ compatibility/interaction is still quite key because of the mountains of legacy and new code still written everyday in it.
Totally agree, but C++ interoperability is orthogonal to my original request. Would love to have both!
Also, I think that the right language for the right domain and being able to glue them together is quite key in the modern computing world and using a single language in every computing domain is a chimera that can bring more pain than good.
I disagree. IMO, the ‘babel’ of programming languages is one of the most annoying problems in our industry. Besides, I don’t see how C++ is any more suitable than Swift for GPU/heterogenous stuff (without peculiar extensions like CUDA). Swift is starting from a clean-slate, and could definitely become a ‘right’ language for this domain.
Also, call me when we get a port of either OpenCL or CUDA bindings in Swift. Hint: it is more likely for Swift to have working C++ integration first than to wait for those to happen.
We can talk about Swift, Rust, Kotlin, Eiffel, Scala, etc... but they are still relatively niche and before any of those gets anywhere near the strong worldwide cross platform following that JavaScript (with the explosion of Node.JS too), Ruby, C/C++, Java, and C#/.NET still have, we will need to keep nurturing and strengthening this language and tools for a while longer.
Sent from my iPhone
On 10 Jul 2016, at 08:50, Georgios Moschovitis <george.moschovitis@icloud.com> wrote:
I disagree. IMO, the ‘babel’ of programming languages is one of the most annoying problems in our industry. Besides, I don’t see how C++ is any more suitable than Swift for GPU/heterogenous stuff (without peculiar extensions like CUDA). Swift is starting from a clean-slate, and could definitely become a ‘right’ language for this domain.
It is more suitable because it is not pure C++. Don't forget that the Metal Shading Language is "only" based on C++11 and modified to be able to express GPU compute attributes.
For more info: https://developer.apple.com/library/ios/documentation/Metal/Reference/MetalShadingLanguageGuide/cplusplus/cplusplus.html#//apple_ref/doc/uid/TP40014364-CH8-SW1
Regards
(From mobile)
I feel like there are two totally different discussions happening here. One is whether Swift needs better interoperability with C++, which it does. Let’s just assume that that will happen.
One of the side effects of a good swift/c++ interop would eliminate the core objections to rewritting swiftc in swift, which IMH would propel forward some of the gaps that exist in the language to be able to do that cleanly. As long as swift remains an app language, completing the generics system or dealing with the question of module/submodule/namespace can be lower priorities with more time to complete.
On Jul 10, 2016, at 11:25 AM, G B via swift-evolution <swift-evolution@swift.org> wrote:
The other discussion, which I think was the intended topic of this thread, is whether the benefits of parallel computing can be brought closer to Swift, which I believe they can.
In most applications, if we can get 80% of the benefit of new hardware with minimal code rewrites, most developers would take that in a heartbeat and focus the specialized talent and careful efforts necessary to craft, profile and maintain truly optimized code on only the most critical kernels. Maybe that critical code will be written in C++, or some other language better suited to the task.
Is there a good reason why Swift can’t be made as suitable— or more suitable— than C++ for the 80% kinds of tasks? It seems to me that Swift would be well suited for it.
On Jul 10, 2016, at 01:41 , Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPhone
On 10 Jul 2016, at 08:50, Georgios Moschovitis <george.moschovitis@icloud.com> wrote:
working on C++ compatibility/interaction is still quite key because of the mountains of legacy and new code still written everyday in it.
Totally agree, but C++ interoperability is orthogonal to my original request. Would love to have both!
Also, I think that the right language for the right domain and being able to glue them together is quite key in the modern computing world and using a single language in every computing domain is a chimera that can bring more pain than good.
I disagree. IMO, the ‘babel’ of programming languages is one of the most annoying problems in our industry. Besides, I don’t see how C++ is any more suitable than Swift for GPU/heterogenous stuff (without peculiar extensions like CUDA). Swift is starting from a clean-slate, and could definitely become a ‘right’ language for this domain.
Also, call me when we get a port of either OpenCL or CUDA bindings in Swift. Hint: it is more likely for Swift to have working C++ integration first than to wait for those to happen.
We can talk about Swift, Rust, Kotlin, Eiffel, Scala, etc... but they are still relatively niche and before any of those gets anywhere near the strong worldwide cross platform following that JavaScript (with the explosion of Node.JS too), Ruby, C/C++, Java, and C#/.NET still have, we will need to keep nurturing and strengthening this language and tools for a while longer.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
> Using the same language/syntax would eliminate the taxing mental context-switch.
I don't understand. That's the point of C++ interop... You call the C++ APIs from your Swift code.
The topic of this discussion is not calling *existing* C++ APIs. It’s about the possibility of writing *new* data-parallel code or graphics shaders using Swift.