The attached document describes some common issues and questions that have been reported and how they might be addressed.
Larry Meadows from Intel Corporation has developed two simple tools for the Intel® Xeon® processor line as well as the Intel® Xeon Phi™ coprocessor that allow a user to determine how well their application is using the machine.
Are you having problems with your hardware (Cannot see your Intel(R) Xeon Phi(tm) coprocessor? Sporadic accessibility?) or with the Intel(R) Manycore Platform Software Stack (Intel(R) MPSS) running reliably?
Attached to this post is a PDF "flowchart" that explains how you can troubleshoot the problem (note: this applies if you are running the Linux* operating system on your host), and shows what information you will want to collect if you need to escalate your issue to your OEM provider or Intel.
Do you have questions that you are not finding the answers for in our documentation? Need more training, source code examples, on what specifically? Help us understand what's missing so that we can make sure we develop documentation you care about (what is important, and what is nice to have)! Thank you
In the period prior to the launch of Intel® Xeon Phi™ coprocessor, Intel collected questions from developers who had been involved in pilot testing. This document contains some of the most common questions asked. Additional information and Best-Known-Methods for the Intel Xeon Phi coprocessor can be found here.
The Intel® Compiler reference guides can be found at:
Оптимизация? Конечно, каждый сталкивался с данной задачей при разработке своих, сколь-нибудь значительных, требующих определённых вычислений, приложений. При этом способов оптимизировать код существует огромное множество, и, как следствие, различных путей сделать это в автоматическом режиме с помощью опций компилятора. Вот здесь и возникает проблема – как выбрать то, что нужно нам и не запутаться?
micctrl crashes if I change OSimage in micX.conf on MPSS 3.2. I traced it and found a problem. I checked the MPSS-3.2.1 source code and looks this problem still there. See below for a fix.
I have a question about Hardware and Software Transactional Memory.
Given the types of versioning (eager and lazy) and conflict detection (optimistic and pessimistic) and let's say that 2 or more threads are performing a transaction that write/read the same memory location.
The scheduling of the threads could affect the ability of detect a conflict? Which combination of versioning and conflict detection would be better to always catch the conflicts?
Hope my question is clear.
I am using the following flags to track SIMD vectorisation
Is there a flag that will demangle the output from the Vectorizer report. Example output below.
icc (ICC) 14.0.2 20140120
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.