Eric Bron (eric.bron.delete@this.zvisuel.privatefortest.com) on August 2, 2018 6:57 am wrote:
> > Eric who was involved in that debate 15 years ago, might be able to shed some light on how much Intel have
> > or have not, been able to respond to needs of engineers working on the software side of it,
>
> I still use the Intel C++ comppiler for production so I'll be maybe able to give you
> some insight, just tell me more about which specific need(s) you are refering to ?

My question relates to the need for generic tools at time in engineering, and the advantages of that approach, versus the other one of making proprietary ones - which makes the size of the potential community smaller yes - but also makes it possible to support something in the 'early stages' a lot easier. There must be thousands and thousands of examples of this conflict in computer science in general.

The work at Intel and maintenance of it's generic C++ compiler technology that stretches all the ways back now to when Vincent and yourself were having that conversation. And that was one of 'the' viable options to use, to support development of Artificial Intelligence, back in the day. Vincent remember at the time was trying to leverage the value of the Intel compiler for chess, even though many of his clients worked with AMD hardware back in those days to build their chess systems. Vincent and yourself were discussing AI, hardware and compilers about 15 years before all of the cool kids got their hands on it, and it becomes the tech-bubble that it is now. Did Intel try to steer it's developer community around Xeon Phi, towards it's own decades old generic C/C++ compiler technology for that hardware? Mark here outlines the compelling case, to remain with generic tools in compiler technology, as much as you can. Speaking in general to do with anything in design, anything with engineering, I come down always on the side of using generic tools that many people have access to.

https://www.realworldtech.com/forum/?threadid=138897&curpostid=178935

Yeah, Mark is talking about putting constraints on how much of the total C language that one is intending to use. And that, I can relate to as well. Using generic tools that many people have access to, but putting constraints on the use of the generic framework, always tends to produce good results.

But then.

There is also the CUDA approach that nVidia took. I.e. As Mark put it, the need to 'commit yourself' to the proprietary tool. I presume, Intel didn't go down the root of having a proprietary tool for Xeon Phi, anything specifically tailored to it, because it wanted it's developer community to remain as broad a church as possible? Like nVidia has instinctively gone in this direction in a lot of it's engineering. Just off the top of my head, something I learned the inner workings of lately - was something called G-Sync (versus Free Sync, for these high refresh rate flat panel LCD screens). nVidia explained that many Free Sync panels just hadn't gone through the same level of quality control. But any of the nVidia quality approached G-Sync panels have been fully tested in labs by their own engineers. Sure, not every panel in the world, is G-sync certified, but customers can have the comfort of having some vendors products available that they know will be compatible with nVidia's cards and drivers.

So in a lot of cases, this approach of 'using our tool' is a good engineering approach to take, and it can be defended logically by nVidia's engineers who've been involved in all of this research and development over time. I tend to veer towards the approach, as I described, Mark Ruolo explained in his post. Keep the tools as open and generic as possible. But what this one instance, where Intel would have been better releasing a tool, that was designed expressly to work with the Xeon Phi range? That's my question, and it's a question just in broad design terms. I'm aware too that within data centers, there's always a certain amount of competition over which technology is used to support the processing needed for Artificial Intelligence. In a way, that whole competition, that whole conversation goes right back to the one that you and Vincent had in 2003, when the only different hardware out there - was Intel Cpu's or AMD Cpu's. It goes back to that.

I noticed the kind of Asrock systems that came on the market very recently (when we started to get NVMe hard drives at affordable prices, and MXM acceleration cards started to go mainstream), and much of it is aimed at the datacenter market.

https://www.asrock.com/ipc/overview.asp?Model=MXM%20IPC-H110

Yeah, there's still an Intel part on that system. But one wonders for how long that x86 chip will continue to play as prominent a role in the datacenter environment as it does now. And if indeed, this approach of making proprietary hardware and proprietary developer tools for that hardware, could become the way of the future? I would hate if it did, but there seems to be trend lines veering in that direction. More than anything else, in broad industry terms, we've seen about ten years or more of engineers and staff who've worked inside datacenters with the likes of Google, Amazon or whomever. I.e. They know what is involved in the management of these facilities, and all of the challenges in terms of power efficiency and so on. They've built stuff from the beginning using x86, and it's served a purpose. But for how long more? The question is, how long more are the generic tools and technology likely to satisfy those people, and are the folk who produce the generic x86 technology really as in touch with that environment and it's requirements as they need to be?