[swift-evolution] For-loop revisited
panajev at gmail.com
Wed Mar 9 09:46:45 CST 2016
No, just that there may be things puny humans might do in terms of compiler hints that the compiler may have no knowledge of. Less and less of them perhaps.
Sent from my iPhone
> On 9 Mar 2016, at 14:00, Ted F.A. van Gaalen <tedvgiosdev at gmail.com> wrote:
> Hi Goffredo,
> sorry, I don’t understand you msg very well,
> i now assume you state that compilers cannot be improved beyond practical limits?
>> On 09.03.2016, at 14:25, Goffredo Marocchi <panajev at gmail.com> wrote:
>> Sometimes programmers directives and runtime knowledge are essential though and the compilers should be optimised but not held to a practically impossible standards. Beside not letting their best people having the best manufacturing process (as well as a nice dose of politics), there is a reason why architectures like IA-64 (which still intrigue me :)) had competitive problems against archs which trusted runtime decisions a lot more.
>> Sent from my iPhone
>>> On 9 Mar 2016, at 12:21, Taras Zakharko via swift-evolution <swift-evolution at swift.org> wrote:
>>>> On 09 Mar 2016, at 00:01, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:
>>>> However, in the real world, especially when working with technical
>>>> and scientific data and for instance in time critical applications
>>>> like 3D presentations fast iterations become a necessity.
>>> There is no reason why collection-based iteration can’t be as fast as a classical C for loop. The compiler should be able to optimise all the overhead away. , even unroll shorter loops. Maybe it doesn’t do it yet. I’d rather see resources invested into improving the compiler to inline/unroll code better where appropriate rather then introducing additional syntax to support a marginal use case.
>>> — Taras
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
More information about the swift-evolution