OpenCL is a quite a lot of abstraction and is meant to be used on lots different products. A rewrite of existing code into openCL would be a massive undertaking (probably better for the long run though).
This seems to be an intel only, lets make existing code run fast on the Phi and other cpus, with minimal changes to code or existing concepts.
I don't think the changes to the existing code are that much more minimal than using OpenCL, and the algorithmic changes that need to be made are identical. Based on the example, it looks like OpenCL is a more verbose about allocating memory for the input and output (due to supporting devices with separate address spaces), and OpenCL requires the entire input and problem size to be specified by the code enqueuing a kernel, where this shows one of the dimensions (in OpenCL parlance, the number of workgroups) being defined implicitly.
Other than the vector primitives and address space qualifiers, OpenCL's kernel language adds very little to C, but this adds constructs like foreach, launch, and sync for things that OpenCL uses library functions to provide.
One thing that seems very telling is that it mentions support for SSE2 and SSE4, but omits SSE3 and SSSE3. Those extension sets were mostly about horizontal operations (between different components of the same vector). The way ispc is designed, it doesn't seem like it would be anywhere near as good for things like reduce operations.
The coherent control statements seem like a really good idea given the architecture targeted, and I wonder why I haven't heard of any similar hints for OpenCL.
