Intel Developer Zone Articles

IMPORTANT - READ BEFORE ACCESSING THIS SITE, OR COPYING, INSTALLING OR USING ANY MATERIALS. By accessing this site, you agree to follow these Intel Corporation ("Intel") rules and website terms & conditions, which Intel may revise from time to time. If you do not accept, you will not be granted access to this site. Your participation in this Intel® Xeon Phi™processor NDA web site is also subject to the terms of use for the Intel Developer Zone. If you do not have a Corporate Non-Disclosure Agreement ("Corporate NDA") in place with Intel, contact your account manager to put one in place, and do not attempt to access this site until you have a Corporate NDA. "You" and "your" refers to your company, institution or entity who indicate acceptance to these terms of use. Throughout these terms, "Participant(s)" will collectively refer to you, each of the other participating companies, institutions and entities, and Intel. Intel may change or amend these rules at any time, and will post any changes online. If you have any questions about these rules please contact your Intel account manager.

1. Participant's Responsibilities: The Intel Xeon Phi processor NDA site at http://software.intel.com/xeon-phi-nda (the "Forum") may include other Participant-created content which allow you and other Participants to post information, provide feedback, and interact in real-time. All materials posted to the Forum will be visible to all Participants in this NDA site. Your use of the Forum must be courteous and sensitive to your fellow Participants at all times. You agree to not:

Post or transmit any material or content that is unlawful, harmful, threatening, abusive, harassing, defamatory, vulgar, obscene, profane, hateful, racially, ethnically or otherwise offensive or objectionable, including, but not limited to, any material which encourages conduct that would constitute a criminal offense, violate the rights of others, or otherwise violate any applicable local, state, national or international law.
Harass or attack any individual or group in any manner that causes annoyance, inconvenience or distress.;
Act in any way which disrupts the dialogue or performance in any Forum area. This includes flooding, bombing or any other activity which jeopardizes or may jeopardize the efficient operation of the Forum service.
Impersonate any other person, group, company, organization or entity.
Transmit advertising or solicitation of any kind.
Send material covered by intellectual property laws without appropriate authority,
Send material that contains viruses, Trojan horses or any corrupted data.
Disparage any person, group, product, business, organization or government entity.
Indulge in any activity that in Intel's opinion may have an adverse effect on the atmosphere, performance or functionality of the Forum or any of its services.

Decisions on the behavior of Participants will be subject to Intel's judgment. Intel may, at its sole discretion: issue warnings to or suspend access to the Forum by any Participant; remove, revise or end any part of the Forum services, and/or edit, remove or refuse to post any Forum content at any time. Intel's decisions are final. You are not obligated to provide Intel with any comments or suggestions regarding any Intel confidential information or pre-release materials related to this Forum or received from Intel. However, should you provide Intel with comments or suggestions for the modification, correction, improvement or enhancement of any Intel confidential information, or Intel products, then you hereby grant to Intel a non-exclusive, irrevocable, worldwide, royalty-free license, including the right to sublicense Intel licensees and customers, under your intellectual property rights, the rights to use and disclose such comments and suggestions in any manner Intel chooses and to display, perform, copy, have copied, make, have made, use, sell, offer to sell, and otherwise dispose of Intel's and it's sublicensees' products embodying such comments or suggestions in any manner and via any media Intel chooses, but without reference to you being the source of such comments and/or suggestions. You will not submit any content unless you are able to grant this license right. You will comply with the terms of any agreement required by the owner or licensor of intellectual property rights in all software and content that you access via this Forum. You will be responsible for, and indemnify and hold harmless Intel and its representatives against, any claim arising from any material that you post or transmit on the Forum. Although Intel may monitor or review material on the Forum site, Intel is under no obligation to do so. You acknowledge that Intel does not control information available within the Forum and that any opinions, advice, statements, services, offers or other information or content within the Forum are those of their respective Participants who are solely liable for their content.

2. Intel's Responsibilities: Intel is not monitoring conduct, communications or content for violations of the above rules, nor can we ensure prompt editing or removal of actual or potentially violating content. However, Intel reserves the right to remove any material from the Forum at any time and for any reason. Intel does not endorse, oppose or edit any opinions expressed by a Participant. Intel is not responsible for the accuracy or truthfulness of advice, information or data provided to this Forum by Participants and is not responsible for the consequences of anyone acting on such information. Neither Intel nor any of its third party contractors is liable for material found in this Forum or over the Internet, or for the adverse treatment of any material which You place in this Forum or the Internet.

3. Confidentiality As part of this Forum, you may elect to participate in open sites, discussion groups and other discussions with Intel and/or other Participants. You may be exposed to pre-release, product or other sensitive or proprietary information of Intel and/or other Participants. For the purposes of this Forum only, Intel hereby grants you permission to post or transmit to the Forum your communications or other material that may contain Intel Confidential Information related to the Intel Xeon Phi processor, and that was disclosed under its Corporate NDA, solely for the purposes of disclosing, sharing and discussing such material with other Participants within the Forum. This permission is limited to the above Intel Confidential Information only; any content described or identified by Intel as its "Restricted Secret" or "Top Secret" Information is not permitted to be disclosed hereunder by any Participant. Otherwise, any content that has been identified to you as Intel's confidential information or pre-release material remains confidential to Intel and remains subject to the terms and conditions of the Intel Corporate NDA or other agreement under which it was provided to you by Intel. Except for the Intel confidential content described above, any communication or material you post or transmit to the Forum is, and will be treated as, non-confidential and non-proprietary. You assume full responsibility for anything you post or transmit, and you grant Intel the right to use, edit, copy, publish and distribute any information or content you post or transmit for any purpose. If you voluntarily disclose personal information (e.g. user name, email address) on a Forum bulletin board, webinar room or on any other user or member generated pages, that information may be collected and used by others and may result in unsolicited messages from other parties.

4. No Endorsement or Guarantee: Participation in the Forum is voluntary and in no way indicates any sponsorship, endorsement, guarantee or certification of this Forum or of any products by any Participant.

5. No Licenses Granted: Except for each Participant's license grant to Intel as described in Section 1 above, Participants grant no licenses of any kind to each other (by implication, estoppel or otherwise) as a result of this Agreement or participation in the Forum, unless expressly done so in writing.

6. Governing Law: The terms and conditions of this Agreement to participate in the Forum are governed by the laws of the State of Delaware, USA, without reference to its conflict of law principles. By accepting below, you acknowledge that you have read this Agreement, understand the terms and conditions necessary for participation in the Forum, and agree to adhere to them

Getting Started Home

Overview:

In this guide you’ll setup network access to your Intel® Edison Board and obtain an IP address.

Requirements:

Intel® Edison Board that has been setup with a serial terminal. For instructions on how to do this, refer to the following documentation:

Setup Wifi

1. To configure your WiFi without specifying username and password options, enter the command configure_edison --wifi. in the shell terminal. If you get an error saying “configure_edison: not found”, you need to update your firmware. Refer to the How-To section of the Edison Support Page for instructions on how to update firmware.

2. When asked if you want to set up the wifi, type “Y” and press Enter.

3. The Intel® Edison will scan for WiFi networks for 10 seconds. When it is finished, a list of available networks will be displayed. If you do not see any networks Enter 0 to rescan.

Figure 1- run “configure_edison --wifi" to scan for networks

4. Choose the network you would like to connect to and type the corresponding number from the list and press Enter. To confirm your entry, type "Y" and press Enter. In this example, to connect to “kafka” use the number “16”, like in Figure 2.

Figure 2- Enter the number of your network.

5. The network in this example requires a password. Your network might require other information. Enter the appropriate network credentials. Press Enter when finished.

Figure 3- Enter your network credentials

6. The Intel® Edison will attempt to make a connection to the network. When you see a “Done” message, you are connected to a Wifi network.

Figure 4- You are now connected. Take note of the IP Address.

7. Note the IP Address, like in Figure 4 above, or alternately, enter the command: ifconfig. Make note of your “wlan0” IP address, as shown in Figure 5 below. This is your IP Address.

Figure 5- Find IP Address after wlan0.

8. To verify connectivity, you may want to ping your Intel® Edison from another computer on the same network using the IP Address obtained above. Alternately, you can try accessing your board by typing in your IP Address into a browser of another computer on the same network.

Next Steps:

Return to Getting Started Home to explore further options.

Troubleshooting

If you are having problems connecting, try running the following commands in a terminal on your Intel® Edison Board:

ifconfig usb0 down
ifconfig wlan0 down
ifconfig wlan0 up

You may also want to try this Alternate method to setup Wifi
If you have any issues or questions, please feel free to go to Intel IoT Forum to post your questions and look for solutions.

Resources

Edison Arduino Expansion Board Hardware Guide
Edison Arduino Expansion Board Schematic
Edison Breakout Board Hardware Guide (For Edison pinout, see page 9.)
Introduction to Yocto Project

Getting Started Home

Overview

In this guide you’ll setup network access to your Intel® Galileo Board and obtain an IP address.

Requirements

Intel Galileo Gen 2 with power supply
Micro B to Type A USB cable
A 6 pin Serial to Type A USB cable (FTDI cable # TTL-232R-)
Ethernet cable and router connection

Setup Hardware

1. Power on your Galileo and plug in the Ethernet cable. The ethernet port should have a link light.

2. For Intel Galileo Gen 2 Connect the 6 pin Serial to Type A USB cable (FTDI cable # TTL-232R-)

Figure 1. FTDI 6 pin cable, black wire towards bottom of picture correlates to GND.

3. Open Arduino or alternatively, connect with a terminal program, to your Galileo board

4. Within Arduino click on Tools -> Serial Monitor

Figure 2. Serial monitor screen from within Arduino

5. At the bottom of the Serial Monitor set to Carriage return and 115200 baud rate

6. In the top entry area, place your cursor in so it is blinking and hit enter.

7. You should see a prompt. If the prompt begins with root, proceed to the next step, otherwise type in root and a password if necessary. By default there is no root password.

8. From the root prompt type in ‘ifconfig’ and hit enter.

9. The left column defines the connection type, eth0 is the ethernet connection (see Figure 2)

Figure 3. Look for your eth0 entry, if no inet addr showing use step 9.

10. If you do not see this entry, do the following command:

Enter ‘ifup eth0’

Figure 4. After issuing the ifup eth0 command you should see the network negotiate.

11. Enter in ifconfig again, if you see e look to see if an IP address is showing.

Figure 5. Look for the entry of inet addr: and take note of the IP address that follows.

12. To confirm the connection, you may want to take the IP address and open a web browser of a computer on the same network and enter the IP address into a web browser and hit enter. Alternately a ping test can be used.

Return to the Galileo Support page

Troubleshooting

Get help through the Galileo Communities Forum

Back to All Intel Fortran Compiler Diagnostics

DATS002 - Virtualizing the Network to Enable a Software Defined Infrastructure

Intel is heavily investing in products and technologies for network overlays, network function virtualization (NFV) and software defined networking (SDN) to help drive the network hardware architectural transformation to enable Software Defined Infrastructure (SDI). This session will discuss industry trends and evolving standards that impact the datacenter network, provide details on deployment of Network Virtualization Overlays (NVO), and use live demonstrations of various types of applications and workloads. Specific focus on network hardware capabilities to optimize traffic management and performance of network overlays using VXLAN, NVGRE and Geneve.

Topics include:

• Network virtualization using network overlays

• Networking equipment and server configuration requirements for LACP LAGs, tunnel end-points and gateways

• What Intel is doing to enable network overlay technology like NVGRE, VXLAN and Geneve

• Configuration and benchmark testing examples

View webcast and audio recordings.

DATS007 - Software Defined Infrastructure: Architectural Challenges and Solutions

This session will give an overview of Intel’s efforts toward providing platforms for a Software-Defined Infrastructure (SDI) that aims to improve the flexible provisioning of compute, networking and storage resources to lower overall TCO and enable new services. We will use an open-source reference architecture to provide an analysis of how application needs can be communicated to a scale-out, SDI-ready infrastructure, and study a variety of usage examples drawn from Software-defined Networking (SDN), Network Function Virtualization (NFV) and Service Function Chaining.

Topics include:

• Common technical challenges to pursuing SDI across these settings, including:

Application and infrastructure interaction

Efficient scaling of performance (e.g., for baseband and packet processing)

Ensuring security and isolation

Providing fault tolerance and resilience Implications to the Orchestration and Control layers of the system

• Specific Intel® platform hardware features that can help the software ecosystem and developers to address these challenges

View webcast and audio recordings.

DATS011 - Dynamic Service Chaining with the Intel® Open Network Platform and Wind River

Topics in this session include:

• Explain the Service Provider’s challenges

• Why service chaining using Network Functions Virtualization (NFV) helps solve the challenge

• What challenges exist to dynamically provision a network application

• The Intel® Open Network Platform (Intel® ONP) hardware and software

• Intel ONP in action – Wind River ON Server and service chaining

• Wind River ON Server dynamic service chaining demo using OpenStack* and Open Daylight* technologies

View webcast and audio recordings.

DATS012 - Intel® Data Plane Development Kit: Open Source Foundations and VMware* Usages

Topics in this session include:

• Overview of Intel® Data Plane Development Kit (Intel® DPDK) features that address Network Functions Virtualization (NFV) needs

• Introduce the upcoming Intel DPDK features that will take advantage of new Intel® Architecture based platform features

• Highlight the many community projects integrating Intel DPDK

• Short explanation of Network Functions Virtualization (NFV) and its benefits

• How to use VMware* vSphere* ESXi* 5.5 and Intel DPDK to create a virtual network function

• Description of specific features designed to support latency sensitive applications

• Best practices for performance tuning for higher packet throughput and lower latencies

View webcast and audio recordings.

Back to All Intel Fortran Compiler Diagnostics

For diagnostics not listed here, please ask in our User Forums.

Back to All Intel Fortran Compiler Diagnostics

Download for Windows Download for Linux Download Documentation

The Advanced Video Motion Estimation (VME) tutorial provides step-by-step guidelines on using the Intel’s motion estimation extensions for the OpenCL™ standard. The advanced motion estimation extension includes a set of host-callable functions for frame-based Video Motion Estimation.

The motion estimation extension depends on the OpenCL 1.2 notion of the built-in kernels, on basic cl_intel_motion_estimation extension, and on the Intel’s “accelerator” extension, which provides an abstraction for the specific hardware-accelerated capabilities.

Supported Devices: Intel® Processor Graphics
Supported OS: Windows* and Linux* OS
Complexity Level: Intermediate

Purpose

This article provides instructions for code access, build, and run directions for the miniGhost code, running on Intel® Xeon® processors and Intel® Xeon Phi™ Coprocessors.

Introduction

miniGhost is a Finite Difference mini-application which implements a difference stencil across a homogenous three dimensional domain.

The kernels that it contains are:
- computation of stencil options,
- inter-process boundary (halo, ghost) exchange.
- Global summation of grid values.

miniGhost was mainly designed to study the performance characteristics of the BSPMA configuration within the context of computations widely used across a variety of scientific algorithms.

BSPMA (Bulk synchronous parallel with message aggregation) model is where the face data is accumulated for each variable into user managed buffers. The buffers are then transmitted to (up to) six neighbor processes and computations of the selected stencil is applied to each variable. The other model is SVAF (single variable, aggregated face data), but this article is focused on BSMPA model only.

miniGhost serves as a proxy (or miniapp) for CTH (Shock Physics) code from Sandia.

Code Access

miniGhost is part of the Mantevo project. To get access to the code refer to: https://mantevo.org/packages/ or here

Please note that v0.9 of the code has been used for performance and optimizations in this article.

Build Directions

The reference version of miniGhost can be built for serial execution or parallel (MPI + OpenMP) execution:

Build

The following examples illustrate different commands for different Intel Xeon processors. Choose the command for the appropriate processor for your build.

NOTE: In the following code examples, extra paragraph spacing shows where very long command lines terminate. Single-spaced code examples are one command line.

Uncompress the source files.

tar -x MiniGhost<ver>.tar
cd source

Source the latest Intel® C and C++ Compilers and Intel® MPI Library. The following example is for the Intel® Compiler (15.0.1 20141023) and Intel® MPI Library (5.0.2.044), including which instructions to use for the type of processor and coprocessor support you need. (The parenthetical comments are not to be included with the code.)

source /opt/intel/composer_xe_2015.1.133/bin/compilervars.sh intel64

(for Intel® Xeon® processor):

source /opt/intel/impi/5.0.2.044/intel64/bin/mpivars.sh

(for Intel® Xeon Phi™ Coprocessor):

source /opt/intel/impi/5.0.2.044/mic/bin/mpivars.sh

To build for the Intel® Xeon® processor v2 family (formerly codenamed Ivy Bridge):

Make the following changes in makefile.mpi

				FC=mpiifort
				CC=mpiicc
				CFLAGS += -Df2c_ -O3 -openmp -g –xCORE-AVX-I
				FFLAGS += -D_MG_INT4 -D_MG_REAL8 -O3 -openmp -g –xCORE-AVX-I

				Build Command

				make –f makefile.mpi

To build for the Intel® Xeon® processor v3 family (formerly codenamed Haswell):

Make the following changes in makefile.mpi

				FC=mpiifort
				CC=mpiicc
				CFLAGS += -Df2c_ -O3 -openmp -g –xCORE-AVX2
				FFLAGS += -D_MG_INT4 -D_MG_REAL8 -O3 -openmp -g –xCORE-AVX2

				Build Command

				make –f makefile.mpi

To build for the Intel Xeon Phi Coprocessor (Knights Corner):

				FC=mpiifort
				CC=mpiicc
				CFLAGS += -Df2c_ -O3 -openmp -g –mmic
				FFLAGS += -D_MG_INT4 -D_MG_REAL8 -O3 -openmp -g –mmic

				Build Command

				make –f makefile.mpi

Compiler Flags Used

Compiler Flag	Effect
O3	Optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs
CORE-AVX-I	May generate Intel® Advanced Vector Extensions (Intel® AVX), including instructions in Intel® Core 2™ processors in process technologies smaller than 32nm, Intel® SSE4.2, SSE4.1, SSSE3, SSE3, SSE2, and SSE instructions for Intel® processors
CORE-AVX2	May generate Intel® Advanced Vector Extensions 2 (Intel® AVX2), Intel AVX, SSE4.2, SSE4.1, SSSE3, SSE3, SSE2, and SSE instructions for Intel processors
mmic	Build an application that runs natively on Intel® Multi-integrated Core Architecture (Intel® MIC Architecture)

Run Directions

Run Time input parameters can be listed using runtime input (--help )

./miniGhost.x --help

Check MG_OPTIONS.F for list of all parameterized options

In the following instructions, select the executing command appropriate for the processor you are using.

Move to the “run” directory:
```
		cd run
```
Be sure to run the appropriate binary for each architecture.
Source the Intel Compilers and Intel MPI Library as appropriate for the architecture.

For Intel Xeon processor v2 family (e.g. Intel® Xeon® processor E5-2697v2), execute the following:

		export OMP_NUM_THREADS=4
		export I_MPI_PIN_DOMAIN=omp
		export KMP_AFFINITY=compact, verbose

		mpirun -n 12 ../source/miniGhost.ivb --scaling 1 --nx 445 --ny 445 --nz 445 --num_vars 40 --num_spikes 1 --debug_grid 1 --report_diffusion 21 --percent_sum 100 --num_tsteps 20 --stencil 24 --comm_method 10 --report_perf 1 --npx 3 --npy 2 --npz 2 --error_tol 8

For Intel Xeon processor v3 family (e.g. Intel® Xeon® processor E5-2697 v3), execute the following:

		export OMP_NUM_THREADS=4
		export I_MPI_PIN_DOMAIN=omp
		export KMP_AFFINITY=compact, verbose

		mpirun -n 14 ../source/miniGhost.hsw --scaling 1 --nx 445 --ny 445 --nz 445 --num_vars 40 --num_spikes 1 --debug_grid 1 --report_diffusion 21 --percent_sum 100 --num_tsteps 20 --stencil 24 --comm_method 10 --report_perf 1 --npx 7 --npy 2 --npz 1 --error_tol 8

For both Intel Xeon processor v2 family (e.g. Intel® Xeon® processor E5-2697 v2) and Intel Xeon Phi Coprocessor 7120A (Symmetric Mode), first source the Intel Compilers and Intel MPI Library, then execute the following:

Create two files (executable) run.ivb and run.knc with the following commands:

run.ivb:

			../source/miniGhost.ivb --scaling 1 --nx 445 --ny 445 --nz 445 --num_vars 40 --num_spikes 1 --debug_grid 1 --report_diffusion 21 --percent_sum 100 --num_tsteps 20 --stencil 24 --comm_method 10 --report_perf 1 --npx 2 --npy 1 --npz 1 --error_tol 8

run.knc:

			../source/miniGhost.knc --scaling 1 --nx 445 --ny 445 --nz 445 --num_vars 40 --num_spikes 1 --debug_grid 1 --report_diffusion 21 --percent_sum 100 --num_tsteps 20 --stencil 24 --comm_method 10 --report_perf 1 --npx 2 --npy 1 --npz 1 --error_tol 8

			export I_MPI_MIC=enable

Use the appropriate MPI fabric using the following:

			export I_MPI_FABRICS=shm:dapl

			export I_MPI_DAPL_PROVIDER=ofa-v2-mlx4_0-1u

			mpiexec.hydra –host `hostname` –n 1 –env OMP_NUM_THREADS 48 –env KMP_AFFINITY compact,verbose –env I_MPI_PIN_DOMAIN omp ./run.ivb : -host `hostname`-mic0 –wdir `pwd` -n 1 –env OMP_NUM_THREADS 240 –env KMP_AFFINITY compact,verbose –env I_MPI_PIN_DOMAIN omp ./run.knc

For Intel Xeon processor v3 family (e.g. Intel® Xeon® processor E5-2697 v3) and the Intel Xeon Phi Coprocessor 7120A (Symmetric Mode), execute the following:

Create two files (executable) run.hsw and run.knc with the following commands:

run.hsw:

			../source/miniGhost.hsw --scaling 1 --nx 445 --ny 445 --nz 445 --num_vars 40 --num_spikes 1 --debug_grid 1 --report_diffusion 21 --percent_sum 100 --num_tsteps 20 --stencil 24 --comm_method 10 --report_perf 1 --npx 2 --npy 1 --npz 1 --error_tol 8

run.knc:

			../source/miniGhost.knc --scaling 1 --nx 445 --ny 445 --nz 445 --num_vars 40 --num_spikes 1 --debug_grid 1 --report_diffusion 21 --percent_sum 100 --num_tsteps 20 --stencil 24 --comm_method 10 --report_perf 1 --npx 2 --npy 1 --npz 1 --error_tol 8

			export I_MPI_MIC=enable

Use the appropriate MPI fabric using the following:

			export I_MPI_FABRICS=shm:dapl

			export I_MPI_DAPL_PROVIDER=ofa-v2-mlx4_0-1u

			mpiexec.hydra –host `hostname` –n 1 –env OMP_NUM_THREADS 56 –env KMP_AFFINITY compact,verbose –env I_MPI_PIN_DOMAIN omp ./run.hsw : -host `hostname`-mic0 –wdir `pwd` -n 1 –env OMP_NUM_THREADS 240 –env KMP_AFFINITY compact,verbose –env I_MPI_PIN_DOMAIN omp ./run.knc

Performance and Optimizations:

In the MG_FLUX_ACCUMULATE subroutine (MG_FLUX_ACCUMULATE.F) six loops were parallelized with $OMP PARALLEL DO/$OMP PARALLEL END DO pragmas to eliminate some serial sections.

Below is the performance speedup of miniGhost (v0.9) using Intel® Xeon® Processors and Intel® Xeon Phi™ Coprocessor. Here Intel® Xeon® processor E5-2697v2 is used as the baseline.

References and Resources

[1] Richard F. Barrett, Courtenay T. Vaughan, and Michael A. Heroux. MiniGhost: A Miniapp for Exploring Boundary Exchange Strategies Using Stencil Computations in Scientific Parallel Computing.
http://prod.sandia.gov/techlib/access-control.cgi/2012/122437.pdf

[2] MiniGhost details as part of the NERSC-8/Trinity Benchmarks
https://www.nersc.gov/users/computational-systems/cori/nersc-8-procurement/trinity-nersc-8-rfp/nersc-8-trinity-benchmarks/minighost/

I came in 2nd in the Al Zimmermann Programming Contest "Delacorte Numbers", using a quad-core machine and the Julia programming language. The attached PDF file is a personal report on using Julia for the contest and a detailed discussion of the program. If you have not used Julia before, you may find it to be a useful introduction to the language.

Also attached is a zip file with what you need to run the program:

delacorte.jl - the Julia program. It requires Julia 0.4, which is under development. You can get a nightly build of the current development version of 0.4 from here. The paper describes how to modify the program to run under Julia 0.3.5.
util.jl - some related utilities
results/ - directory where program puts best results. I include my result files therein because the program requires an existing result file.
trials/ - empty directory where the program puts all results from runs.

- Arch D. Robison

This webcast (from IDF 2014) covers technical details and best known methods (BKMs) for optimizing big data clusters and Hadoop* workloads on Intel® Xeon® processor E5 v3 based platforms.

Topics include:

• How to deploy, tune and configure the hardware and operating systems for your big data cluster

• How to run an Industry standard benchmark to measure the cluster performance and TCO calculation

• BKMs for optimizing the Hadoop framework configuration and workloads including NoSQL (HBase*, Cassandra) and in-memory analytics frameworks (Spark* / Shark)

Presentation PDF Download

View webcast and audio recording

Introduction

Intel® Xeon Phi™ coprocessor is a product based on the Intel® Many Integrated Core Architecture (Intel® MIC). Intel® offers a debug solution for this architecture that can debug applications running on an Intel® Xeon Phi™ coprocessor.

There are many reasons for the need of a debug solution for Intel^® MIC. Some of the most important ones are the following:

Developing native Intel^® MIC applications is as easy as for IA-32 or Intel^® 64 hosts. In most cases they just need to be cross-compiled (/Qmic).
Yet, Intel^® MIC Architecture is different to host architecture. Those differences could unveil existing issues. Also, incorrect tuning for Intel^® MIC could introduce new issues (e.g. alignment of data, can an application handle more than hundreds of threads?, efficient memory consumption?, etc.)
Developing offload enabled applications induces more complexity as host and coprocessor share workload.
General lower level analysis, tracing execution paths, learning the instruction set of Intel^® MIC Architecture, …

Debug Solution for Intel® MIC

For Windows* host, Intel offers a debug solution, the Intel® Debugger Extension for Intel® MIC Architecture Applications. It supports debugging offload enabled application as well as native Intel® MIC applications running on the Intel® Xeon Phi™ coprocessor.

How to get it?

To obtain Intel® Debugger Extension for Intel® MIC Architecture on Windows* host, you need the following:

Intel® Parallel Studio XE 2015 (for C/C++ or Fortran):
https://software.intel.com/en-us/intel-parallel-studio-xe
Only Intel® Composer XE contains the debug solution for Windows* host. However, Intel^® Manycore Platform Software Stack (Intel^® MPSS) is also required for this to work:
http://software.intel.com/en-us/articles/intel-manycore-platform-software-stack-mpss
(currently 3.4.2 for Windows*)

Debug Solution as Integration

Debug solution from Intel® based on GNU* GDB:

Full integration into Microsoft Visual Studio*, no command line version needed
Available with Intel® Composer XE 2013 SP1 and later
(Intel® Parallel Studio XE Composer Edition is the successor)

Note:
Pure native debugging on the coprocessor is also possible by using Intel’s version of GNU* GDB for the coprocessor. This is covered in the following article for Linux* host:
http://software.intel.com/en-us/articles/debugging-intel-xeon-phi-applications-on-linux-host

Why integration into Microsoft Visual Studio*?

Microsoft Visual Studio* is established IDE on Windows* host
Integration reuses existing usability and features
Fortran support added with Intel® Parallel Studio XE Composer Edition for Fortran (former Intel® Fortran Composer XE)

Components Required

The following components are required to develop and debug for Intel® MIC Architecture:

Intel® Xeon Phi™ coprocessor
Windows* Server 2008 RC2, Windows* 7 or later
Microsoft Visual Studio* 2012 or later
Support for Microsoft Visual Studio* 2013 was added with Intel® Composer XE 2013 SP1 Update 1.
Intel® MPSS 3.1 or later
C/C++ development:
Intel® C++ Composer XE 2013 SP1 for Windows* or later
Fortran development:
Intel® Fortran Composer XE 2013 SP1 for Windows* or later

Configure & Test

It is crucial to make sure that the coprocessor setup is correctly working. Otherwise the debugger might not be fully functional.

Setup Intel^® MPSS:

Follow Intel^® MPSS readme-windows.pdf for setup
Verify that the Intel^® Xeon Phi™ coprocessor is running

Before debugging applications with offload extensions:

Use official examples from:
C:\Program Files (x86)\Intel\Composer XE 2013 SP1\Samples\en_US
Verify that offloading code works

It is crucial to make sure that the coprocessor setup is correctly working. Otherwise the debugger might not be fully functional.

Prerequisite for Debugging

Debugger integration for Intel^® MIC Architecture only works when debug information is being available:

Compile in debug mode with at least the following option set:
/Zi (compiler) and /DEBUG (linker)
Optional: Unoptimized code (/Od) makes debugging easier
(due to removed/optimized away temporaries, etc.)

Applications can only be debugged in 64 bit

Set platform to x64
Verify that /MACHINE:x64 (linker) is set!

Debugging Applications with Offload Extension

Start Microsoft Visual Studio* IDE and open or create an Intel^® Xeon Phi™ project with offload extensions. Examples can be found in the Samples directory of Intel® Parallel Studio XE Composer Edition (former Intel® Composer XE), that is:

C:\Program Files (x86)\Intel\Composer XE 2013 SP1\Samples\en_US

C++\mic_samples.zip or
Fortran\mic_samples.zip

We’ll use intro_SampleC from the official C++ examples in the following.

Compile the project with Intel^® C++/Fortran Compiler.

Characteristics of Debugging

Set breakpoints in code (during or before debug session):
- In code mixed for host and coprocessor
- Debugger integration automatically dispatches between host/coprocessor
Run control is the same as for native applications:
- Run/Continue
- Stop/Interrupt
- etc.
Offloaded code stops execution (offloading thread) on host
Offloaded code is executed on coprocessor in another thread
IDE shows host/coprocessor information at the same time:
- Breakpoints
- Threads
- Processes/Modules
- etc.
Multiple coprocessors are supported:
- Data shown is mixed:
  Keep in mind the different processes and address spaces
- No further configuration needed:
  Debug as you go!

Setting Breakpoints

Note the mixed breakpoints here:
The ones set in the normal code (not offloaded) apply to the host. Breakpoints on offloaded code apply to the respective coprocessor(s) only.
The Breakpoints window shows all breakpoints (host & coprocessor(s)).

Start Debugging

Start debugging as usual via menu (shown) or <F5> key:

While debugging, continue till you reach a set breakpoint in offloaded code to debug the coprocessor code.

Thread Information

Information of host and coprocessor(s) is mixed. In the example above, the threads window shows two processes with their threads. One process comes from the host, which does the offload. The other one is the process hosting and executing the offloaded code, one for each coprocessor.

Additional Requirements

For debugging offload enabled applications additional environment variables need to be set:

Intel® MPSS 2.1:
COI_SEP_DISABLE=FALSE
MYO_WATCHDOG_MONITOR=-1
Intel® MPSS 3.*:
AMPLXE_COI_DEBUG_SUPPORT=TRUE
MYO_WATCHDOG_MONITOR=-1

Set those variables before starting Visual Studio* IDE!

Those are currently needed but might become obsolete in the future. Please be aware that the debugger cannot and should not be used in combination with Intel® VTune™ Amplifier XE. Hence disabling SEP (as part of Intel® VTune™ Amplifier XE) is valid. The watchdog monitor must be disabled because a debugger can stop execution for an unspecified amount of time. Hence the system watchdog might assume that a debugged application, if not reacting anymore, is dead and will terminate it. For debugging we do not want that.

Note:
Do not set those variables for a production system!

Debugging Native Coprocessor Applications

Pre-Requisites

Create a native Intel^® Xeon Phi™ coprocessor application and transfer & execute the application to the coprocessor target:

Use micnativeloadex.exe provided by Intel^® MPSS for an application C:\Temp\mic-examples\bin\myApp, e.g.:

> "C:\Program Files\Intel\MPSS\bin\micnativeloadex.exe""C:\Temp\mic-examples\bin\myApp" -d 0
Option –d 0 specifies the first device (zero based) in case there are multiple coprocessors per system
The application is executed directly after transfer

micnativeloadex.exe transfers the specified application to the specified coprocessor and directly executes it. The command itself will be blocked until the transferred application terminates.
Using micnativeloadex.exe also takes care about dependencies (i.e. libraries) and transfers them, too.

Other ways to transfer and execute native applications are also possible (but more complex):

SSH/SCP
NFS
FTP
etc.

Debugging native applications with Start Visual Studio* IDE is only possible via Attach to Process…:

micnativeloadex.exe has been used to transfer and execute the native application

Make sure the application waits till attached, e.g. by:


		static int lockit = 1;

		while(lockit) { sleep(1); }

After having attached, set lockit to 0 and continue.
No Visual Studio* solution/project is required.

Only one coprocessor at a time can be debugged this way.

Configuration

Open the options via TOOLS/Options… menu:

It tells the debugger extension where to find the binary and sources. This needs to be changed every time a different coprocessor native application is being debugged.

The entry solib-search-path directories works the same as for the analogous GNU* GDB command. It allows to map paths from the build system to the host system running the debugger.

The entry Host Cache Directory is used for caching symbol files. It can speed up lookup for big sized applications.

Attach

Open the options via TOOLS/Attach to Process… menu:

Specify the Intel(R) Debugger Extension for Intel(R) MIC Architecture. Set the IP and port the GDBServer should be executed with. The usual port for GDBServer is 2000 but we recommend to use a non-privileged port (e.g. 16000).
After a short delay the processes of the coprocessor card are listed. Select one to attach.

Note:
Checkbox Show processes from all users does not have a function for the coprocessor as user accounts cannot be mapped from host to target and vice versa (Linux* vs. Windows*).

Introduction

There are many reasons for the need of a debug solution for Intel^® MIC. Some of the most important ones are the following:

Developing native Intel^® MIC applications is as easy as for IA-32 or Intel^® 64 hosts. In most cases they just need to be cross-compiled (-mmic).
Yet, Intel^® MIC Architecture is different to host architecture. Those differences could unveil existing issues. Also, incorrect tuning for Intel^® MIC could introduce new issues (e.g. alignment of data, can an application handle more than hundreds of threads?, efficient memory consumption?, etc.)
Developing offload enabled applications induces more complexity as host and coprocessor share workload.
General lower level analysis, tracing execution paths, learning the instruction set of Intel^® MIC Architecture, …

Debug Solution for Intel® MIC

For Linux* host, Intel offers a debug solution for Intel® MIC which is based on GNU* GDB. It can be used on the command line for both host and coprocessor. There is also an Eclipse* IDE integration that eases debugging of applications with hundreds of threads thanks to its user interface. It also supports debugging offload enabled applications.

How to get it?

There are currently two ways to obtain Intel’s debug solution for Intel® MIC Architecture on Linux* host:

Intel® Parallel Studio XE 2015 (for C/C++ or Fortran):
https://software.intel.com/en-us/intel-parallel-studio-xe
Intel^® Manycore Platform Software Stack (MPSS):
http://software.intel.com/en-us/articles/intel-manycore-platform-software-stack-mpss
(currently MPSS 3.4.2 for Linux*)
First version became available with MPSS 2.1.

Both packages contain the same debug solutions for Intel® MIC Architecture!

Note:
Intel® Composer XE 2013 SP1 contains GNU* GDB 7.5. With Intel® Parallel Studio XE 2015 GNU* GDB 7.7, and with Intel® Parallel Studio XE 2015 Update 2 GNU* GDB 7.8 is available. MPSS versions have different versions of GNU* GDB – please check the Release Notes of the individual MPPS releases.
There has been a change in product naming: Intel® Parallel Studio XE Composer Edition is the successor of Intel® Composer XE, starting with 2015.

Why use GNU* GDB provided by Intel?

New features/improvements offered back to GNU* community
Latest GNU* GDB versions in future releases
Improved C/C++ & Fortran support thanks to Project Archer and contribution through Intel
Increased support for Intel^® architecture (esp. Intel^® MIC)
Additional debugging capabilities – more later

Latest Intel related HW support and features are provided in the debug solution from Intel!

Why is Intel providing a Command Line and Eclipse* IDE Integration?

The command line with GNU* GDB has the following advantages:

Well known syntax
Lightweight: no dependencies
Easy setup: no project needs to be created
Fast for debugging hundreds of threads
Can be automatized/scripted

Using the Eclipse* IDE provides more features:

Comfortable user interface
Most known IDE in the Linux* space
Use existing Eclipse* projects
Simple integration of the Intel enhanced GNU* GDB
Works also with Photran* plug-in to support Fortran
Supports debugging of offload enabled applications
(not supported by command line)

Deprecation Notice

Intel® Debugger is deprecated (incl. Intel® MIC Architecture support):

Intel® Debugger for Intel® MIC Architecture was only available in Composer XE 2013 & 2013 SP1
Intel® Debugger is not part of Intel® Parallel Studio XE 2015 anymore

Users are advised to use GNU* GDB that comes with Intel® Composer XE 2013 SP1 and later!

You can provide feedback via either your Intel® Premier account (http://premier.intel.com) or via the Debug Solutions User Forum (http://software.intel.com/en-us/forums/debug-solutions/).

Features

Intel’s GNU* GDB, starting with version 7.5, provides additional extensions that are available:

Support for Intel^® Many Integrated Core Architecture (Intel^® MIC Architecture):
Displays registers (zmmX & kX) and disassembles the instruction set
Support for Intel^® Transactional Synchronization Extensions (Intel^® TSX):
Helpers for Restricted Transactional Memory (RTM) model
(only for host)
Data Race Detection (pdbx):
Detect and locate data races for applications threaded using POSIX* thread (pthread) or OpenMP* models
Branch Trace Store (btrace):
Record branches taken in the execution flow to backtrack easily after events like crashes, signals, exceptions, etc.
(only for host)
Pointer Checker:
Assist in finding pointer issues if compiled with Intel^® C++ Compiler and having Pointer Checker feature enabled
(only for host)
Register support for Intel^® Memory Protection Extensions (Intel^® MPX) and Intel^® Advanced Vector Extensions 512 (Intel^® AVX-512):
Debugger is already prepared for future generations

The features for Intel® MIC Architecture highlighted above are described in the following.
Note that newer GNU* GDB versions are already available with more features but unrelated to the Intel® MIC Architecture.

Register and Instruction Set Support

Compared to Intel® architecture on host systems, Intel® MIC Architecture comes with a different instruction and register set. Intel’s GNU* GDB comes with transparently integrated support for those. Use is no different than with host systems, e.g.:

Disassembling of instructions:
```
		(gdb) disassemble $pc, +10

		Dump of assembler code from 0x11 to 0x24:

		0x0000000000000011 <foobar+17>: vpackstorelps %zmm0,-0x10(%rbp){%k1}

		0x0000000000000018 <foobar+24>: vbroadcastss -0x10(%rbp),%zmm0

		⁞

		
```
In the above example the first ten instructions are disassembled beginning at the instruction pointer ($pc). Only first two lines are shown for brevity. The first two instructions are Intel® MIC specific and their mnemonic is correctly shown.

Listing of mask (kX) and vector (zmmX) registers:


		(gdb) info registers zmm

		k0   0x0  0

		     ⁞

		zmm31 {v16_float = {0x0 <repeats 16 times>},

		      v8_double = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},

		      v64_int8 = {0x0 <repeats 64 times>},

		      v32_int16 = {0x0 <repeats 32 times>},

		      v16_int32 = {0x0 <repeats 16 times>},

		      v8_int64 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},

		      v4_uint128 = {0x0, 0x0, 0x0, 0x0}}

Also registers have been extended by kX (mask) and zmmX (vector) register sets that come with Intel® MIC.

If you use the Eclipse* IDE integration you’ll get the same information in dedicated windows:

Disassembling of instructions:
Listing of mask (kX) and vector (zmmX) registers:

Data Race Detection

A quick excursion about what data races are:

A data race happens…
If at least two threads/tasks access the same memory location w/o synchronization and at least one thread/task is writing.

Example:
Imaging the two functions thread1()& thread2() are executed concurrently by different threads.


		int a = 1;

		int b = 2;

		                                         | t

		int thread1() {      int thread2() {     | i

		  return a + b;        b = 42;           | m

		}                    }                   | e

		                                         v

Return value of thread1() depends on timing: 3 vs. 43!
This is one (trivial) example of a data race.

What are typical symptoms of data races?

Data race symptoms:
- Corrupted results
- Run-to-run variations
- Corrupted data ending in a crash
- Non-deterministic behavior
Solution is to synchronize concurrent accesses, e.g.:
- Thread-level ordering (global synchronization)
- Instruction level ordering/visibility (atomics)
  Note:
  Race free but still not necessarily run-to-run reproducible results!
- No synchronization: data races might be acceptable

GDB data race detection points out unsynchronized data accesses. Not all of them might incur data races. It is the responsibility of the user to decide which ones are not expected and filter them (see next).
Due to technical limitations not all unsynchronized data accesses can be found, e.g.: 3rd party libraries or any object code not compiled with –debug parallel (see next).

How to detect data races?

Prepare to detect data races:
- Only supported with Intel^® C++/Fortran Compiler:
  Compile with -debug parallel (icc, icpc or ifort)
  Only objects compiled with-debug parallel are analyzed!
- Optionally, add debug information via –g

Enable data race detection (PDBX) in debugger:


		(gdb) pdbx enable

		(gdb) c

		data race detected

		1: write shared, 4 bytes from foo.c:36

		3: read shared, 4 bytes from foo.c:40

		Breakpoint -11, 0x401515 in L_test_..._21 () at foo.c:36

		*var = 42; /* bp.write */

Data race detection requires an additional library libpdbx.so.5:

Keeps track of the synchronizations
Part of Intel® C++ & Fortran Compiler
Copy to coprocessor if missing
(found at <composer_xe_root>/compiler/lib/mic/libpdbx.so)

Supported parallel programming models:

OpenMP*
POSIX* threads

Data race detection can be enabled/disabled at any time

Only memory access are analyzed within a certain period
Keeps memory footprint and run-time overhead minimal

There is finer grained control for minimizing overhead and selecting code sections to analyze by using filter sets.

More control about what to analyze with filters:

Add filter to selected filter set, e.g.:
```
		(gdb) pdbx filter line foo.c:36

		(gdb) pdbx filter code 0x40518..0x40524

		(gdb) pdbx filter var shared

		(gdb) pdbx filter data 0x60f48..0x60f50

		(gdb) pdbx filter reads # read accesses

		
```
Those define various filter on either instructions by specifying source file and line or the addresses (range), or variables using symbol names or addresses (range) respectively. There is also a filter to only report accesses that use (read) data in case of a data race.
There are two basic configurations, that are exclusive:
- Ignore events specified by filters (default behavior)
```
				(gdb) pdbx fset suppress

				
```
- Ignore events not specified by filters
```
				(gdb) pdbx fset focus

				
```
  The first one defines a white list, whilst the latter one blacklists code or data sections that should not be analyzed.
Get debug command help
```
		(gdb) help pdbx

		
```
This command will provide additional help on the commands.

Use cases for filters:

Focused debugging, e.g. debug a single source file or only focus on one specific memory location.
Limit overhead and control false positives. Detection involves some runtime and memory overhead at runtime. The more filters narrow down the scope of analysis, the more the overhead will be reduced. This can also be used to exclude false positives. Those can occur if real data races are detected, but without any impact on application’s correctness by design (e.g. results of multiple threads don’t need to be globally stored in strict order).
Exclude 3rd party code for analysis

Some additional hints using PDBX:

Optimized code (symptom):


		(gdb) run

		data race detected

		1: write question, 4 bytes from foo.c:36

		3: read question, 4 bytes from foo.c:40

		Breakpoint -11, 0x401515 in foo () at foo.c:36

		*answer = 42;

		(gdb)

Incident has to be analyzed further:
- Remember: data races are reported on memory objects
- If symbol name cannot be resolved: only address is printed
Recommendation:
Unoptimized code (-O0) makes it easier to understand due to removed/optimized away temporaries, etc.
Reported data races appear to be false positives:
- Not all data races are bad… user intended?
- OpenMP*: Distinct parallel sections using the same variable (same stack frame) can result in false positives

Note:
PDBX is not available for Eclipse* IDE and will only work for remote debugging of native coprocessor applications. See section Debugging Remotely with PDBX for more information on how to use it.

Debugging on Command Line

There are multiple versions available:

Debug natively on Intel^® Xeon Phi™ coprocessor
Execute GNU* GDB on host and debug remotely

Debug natively on Intel® Xeon Phi™ coprocessor
This version of Intel’s GNU* GDB runs natively on the coprocessor. It is included in Intel® MPSS only and needs to be made available on the coprocessor first in order to run it. Depending on the MPSS version it can be found at the provided location:

MPSS 2.1: /usr/linux-k1om-4.7/linux-k1om/usr/bin/gdb
MPSS 3.*: included in gdb-7.*+mpss3.*.k1om.rpm as part of package mpss-3.*-k1om.tar
(for MPSS 3.1.2, please see Errata, for MPSS 3.1.4 use mpss-3.1.4-k1om-gdb.tar)

For MPSS 3.* the coprocessor native GNU* GDB requires debug information from some system libraries for proper operation. Please see Errata for more information.

Execute GNU* GDB on host and debug remotely
There are two ways to start GNU* GDB on the host and debug remotely using GDBServer on the coprocessor:

Intel^® MPSS:
- MPSS 2.1: /usr/linux-k1om-4.7/bin/x86_64-k1om-linux-gdb
- MPSS 3.*: <mpss_root>/sysroots/x86_64-mpsssdk-linux/usr/bin/k1om-mpss-linux/k1om-mpss-linux-gdb
- GDBServer:
  /usr/linux-k1om-4.7/linux-k1om/usr/bin/gdbserver
  (same path for MPSS 2.1 & 3.*)
Intel® Parallel Studio XE Composer Edition:
- Source environment to start GNU* GDB:
```
				$ source debuggervars.[sh|csh]

				$ gdb-mic

				
```
- GDBServer:
  <composer_xe_root>/debugger/gdb/target/mic/bin/gdbserver

The sourcing of the debugger environment is only needed once. If you already sourced the according compilervars.[sh|csh] script you can omit this step and gdb-mic should already be in your default search paths.

Attention: Do not mix GNU* GDB & GDBServer from different packages! Always use both from either Intel® MPSS or Intel® Parallel Studio XE Composer Edition!

Debugging Natively

Make sure GNU* GDB is already on the target by:

Copy manually, e.g.:


		$ scp /usr/linux-k1om-4.7/linux-k1om/usr/bin/gdb mic0:/tmp

Add to the coprocessor image (see Intel® MPSS documentation)

Run GNU* GDB on the Intel® Xeon Phi™ coprocessor, e.g.:
```
		$ ssh –t mic0 /tmp/gdb

		
```
Initiate debug session, e.g.:

Attach:
```
		(gdb) attach <pid>
```
<pid> is PID on the coprocessor
Load & execute:
```
		(gdb) file <path_to_application>
```
<path_to_application> is path on coprocessor

Some additional hints:

If native application needs additional libraries:
Set $LD_LIBRARY_PATH, e.g. via:
```
		(gdb) set env LD_LIBRARY_PATH=/tmp/

		
```
…or set the variable before starting GDB
If source code is relocated, help the debugger to find it:
```
		(gdb) set substitute-path <from> <to>
```
Change paths from <from> to<to>. You can relocate a whole source (sub-)tree with that.

Debugging is no different than on host thanks to a real Linux* environment on the coprocessor!

Debugging Remotely

Copy GDBServer to coprocessor, e.g.:
```
		$ scp <composer_xe_root>/debugger/gdb/target/mic/bin/gdbserver mic0:/tmp
```
During development you can also add GDBServer to your coprocessor image!
Start GDB on host, e.g.:
```
		$ source debuggervars.[sh|csh]

		$ gdb-mic

		
```
Note:
There is also a version named gdb-ia which is for IA-32/Intel® 64 only!

Connect:


		(gdb) target extended-remote | ssh -T mic0 /tmp/gdbserver --multi –

Set sysroot from MPSS installation, e.g.:
```
		(gdb) set sysroot /opt/mpss/3.1.4/sysroots/k1om-mpss-linux/

		
```
If you do not specify this you won't get debugger support for system libraries.
Debug:

Attach:
```
		(gdb) file <path_to_application>

		(gdb) attach <pid>
```
<path_to_application> is path on host, <pid> is PID on the coprocessor
Load & execute:
```
		(gdb) file <path_to_application>

		(gdb) set remote exec-file <remote_path_to_application>
```
<path_to_application> is path on host, <remote_path_to_application> is path on the coprocessor

Some additional hints:

If remote application needs additional libraries:
Set $LD_LIBRARY_PATH, e.g. via:


		(gdb) target extended-remote | ssh mic0 LD_LIBRARY_PATH=/tmp/ /tmp/gdbserver --multi -

If source code is relocated, help the debugger to find it:
```
		(gdb) set substitute-path <from> <to>
```
Change paths from <from> to <to>. You can relocate a whole source (sub-)tree with that.
If libraries have different paths on host & target, help the debugger to find them:
```
		(gdb) set solib-search-path <lib_paths>
```
<lib_paths> is a colon separated list of paths to look for libraries on the host

Debugging is no different than on host thanks to a real Linux* environment on the coprocessor!

Debugging Remotely with PDBX

PDBX has some pre-requisites that must be fulfilled for proper operation. Use pdbx check command to see whether PDBX is working:

First step:
```
		(gdb) pdbx check

		checking inferior...failed.

		
```
Solution:
Start a remote application (inferior) and hit some breakpoint (e.g. b main& run)
Second step:
```
		(gdb) pdbx check

		checking inferior...passed.

		checking libpdbx...failed.

		
```
Solution:
Use set solib-search-path <lib_paths> to provide the path of libpdbx.so.5 on the host.
Third step:
```
		(gdb) pdbx check

		checking inferior...passed.

		checking libpdbx...passed.

		checking environment...failed.

		
```
Solution:
Set additional environment variables on the target for OpenMP*. Those need to be set with starting GDBServer (similar to setting $LD_LIBRARY_PATH).

$INTEL_LIBITTNOTIFY32=""
$INTEL_LIBITTNOTIFY64=""
$INTEL_ITTNOTIFY_GROUPS=sync

Debugging with Eclipse* IDE

Intel offers an Eclipse* IDE debugger plug-in for Intel® MIC that has the following features:

Seamless debugging of host and coprocessor
Simultaneous view of host and coprocessor threads
Supports multiple coprocessor cards
Supports both C/C++ and Fortran
Support of offload extensions (auto-attach to offloaded code)
Support for Intel^® Many Integrated Core Architecture (Intel^® MIC Architecture): Registers & Disassembly

The plug-in is part of both Intel® MPSS and Intel® Parallel Studio XE Composer Edition.

Pre-requisites

In order to use the provided plug-in the following pre-requisites have to be met:

Supported Eclipse* IDE version:
- 4.4 with Eclipse C/C++ Development Tools (CDT) 8.3 or later
- 4.3 with Eclipse C/C++ Development Tools (CDT) 8.1 or later
- 4.2 with Eclipse C/C++ Development Tools (CDT) 8.1 or later
- 3.8 with Eclipse C/C++ Development Tools (CDT) 8.1 or later

We recommend: Eclipse* IDE for C/C++ Developers (4.4)

Java* Runtime Environment (JRE) 6.0 or later (7.0 for Eclipse* 4.4)
For Fortran optionally Photran* plug-in
Remote System Explorer (aka. Target Management) to debug native coprocessor applications
Only for plug-in from Intel® Parallel Studio XE Composer Edition, source debuggervars.[sh|csh] for Eclipse* IDE environment!

Install Intel® C++ Compiler plug-in (optional):
Add plug-in via “Install New Software…”:

This Plug-in is part of Intel® Parallel Studio XE Composer Edition (<composer_xe_root>/eclipse_support/cdt8.0/). It adds Intel® C++ Compiler support which is not mandatory for debugging. For Fortran the counterpart is the Photran* plug-in. These plug-ins are recommended for the best experience.

Note:
Uncheck “Group items by category”, as the list will be empty otherwise!
In addition, it is recommended to disable checking for latest versions. If not done, installation could take unnecessarily long and newer components might be installed that did not come with the vanilla Eclipse package. Those could cause problems.

Install Plug-in for Offload Debugging

Add plug-in via “Install New Software…”:

Plug-in is part of:

Intel^® MPSS:
- MPSS 2.1: <mpss_root>/eclipse_support/
- MPSS 3.*: /usr/share/eclipse/mic_plugin/
Intel® Parallel Studio XE Composer Edition:<composer_xe_root>/debugger/cdt/

Configure Offload Debugging

Create a new debug configuration for “C/C++ Application”
Click on “Select other…” and select MPM (DSF) Create Process Launcher:
The “MPM (DSF) Create Process Launcher” needs to be used for our plug-in. Please note that this instruction is for both C/C++ and Fortran applications! Even though Photran* is installed and a “Fortran Local Application” entry is visible (not in the screenshot above!) don’t use it. It is not capable of using MPM.
In “Debugger” tab specify MPM script of Intel’s GNU* GDB:
- Intel^® MPSS:
  - MPSS 2.1: <mpss_root>/mpm/bin/start_mpm.sh
  - MPSS 3.*: /usr/bin/start_mpm.sh
    (for MPSS 3.1.1, 3.1.2 or 3.1.4, please see Errata)
- Intel® Parallel Studio XE Composer Edition:
  <composer_xe_root>/debugger/mpm/bin/start_mpm.sh
  
  Here, you finally add Intel’s GNU* GDB for offload debugging (using MPM (DSF)). It is a script that takes care of setting up the full environment needed. No further configuration is required (e.g. which coprocessor cards, GDBServer & ports, IP addresses, etc.); it works fully automatic and transparent.

Start Offload Debugging

Debugging offload enabled applications is not much different than applications native for the host:

Create & build an executable with offload extensions (C/C++ or Fortran)
- Use offload pragmas/directives or OpenMP* 4.0
- Use MYO (_Cilk_shared, _Cilk_spawn, …)
  
  For getting started examples, please see:
  - <composer_xe_root>/Samples/en_US/[C++|Fortran]/mic_samples
  - http://software.intel.com/en-us/articles/offload-programming-fortran-and-c-code-examples
  - Or search via Intel® Developer Zone’s Content Library:
    http://software.intel.com/en-us/search/site
Don’t forget to add debug information (-g) and reduce optimization level if possible (-O0)
Start debug session:
- Host & target debugger will work together seamlessly
- All threads from host & target are shown and described
- Debugging is same as used from Eclipse* IDE

This is an example (Fortran) of what offload debugging looks like. On the left side we see host & mic0 threads running. One thread (11) from the coprocessor has hit the breakpoint we set inside the loop of the offloaded code. Run control (stepping, continuing, etc.), setting breakpoints, evaluating variables/memory, … work as they used to.

Additional Requirements for Offload Debugging

For debugging offload enabled applications additional environment variables need to be set:

Intel® MPSS 2.1:
COI_SEP_DISABLE=FALSE
MYO_WATCHDOG_MONITOR=-1
Intel® MPSS 3.*:
AMPLXE_COI_DEBUG_SUPPORT=TRUE
MYO_WATCHDOG_MONITOR=-1

Set those variables before starting Eclipse* IDE!

Note:
Do not set those variables for a production system!

For Intel® MPSS 3.2 and later:
MYO debug libraries are no longer installed with Intel MPSS 3.2 by default. This is a change from earlier Intel MPSS versions. Users must install the MYO debug libraries manually in order to debug MYO enabled applications using the Eclipse plug-in for offload debugging. For Intel MPSS 3.2 (and later) the MYO debug libraries can be found in the package mpss-myo-dbg-* which is included in the mpss-*.tar file.

MPSS 3.2 and 3.2.1 do not support offload debugging with Intel® Composer XE 2013 SP1, please see Errata for more information!

Configure Native Debugging

Configure Remote System Explorer
To debug native coprocessor applications we need to configure the Remote System Explorer (RSE).

Note:
Before you continue, make sure SSH works (e.g. via command line). You can also specify different credentials (user account) via RSE and save the password.

The basic steps are quite simple:

Show the Remote System window:
Menu Window->Show View->Other…
Select: Remote Systems->Remote Systems
Add a new system node for each coprocessor:

Context menu in window Remote Systems: New Connection…

Select Linux, press Next>
Specify hostname of the coprocessor (e.g. mic0), press Next>
In the following dialogs select:
- ssh.files
- processes.shell.linux
- ssh.shells
- ssh.terminals

Repeat this step for each coprocessor!

Transfer GDBServer
Transfer of the GDBServer to the coprocessor is required for remote debugging. We choose /tmp/gdberver as target on the coprocessor here (important for the following sections).

Transfer the GDBServer to the coprocessor target, e.g.:


	$ scp <composer_xe_root>/debugger/gdb/target/mic/bin/gdbserver mic0:/tmp

During development you can also add GDBServer to your coprocessor image!

Note:
See section Debugging on Command Line above for the correct path of GDBServer, depending on the chosen package (Intel^® MPSS or Intel® Parallel Studio XE Composer Edition)!

Debug Configuration

To create a new debug configuration for a native coprocessor application (here: native_c++) create a new one for C/C++ Remote Application.

Set Connection to the coprocessor target configured with RSE before (here: mic0).

Specify the remote path of the application, wherever it was copied to (here: /tmp/native_c++). We’ll address how to manually transfer files later.

Set the flag for “Skip download to target path.” if you don’t want the debugger to upload the executable to the specified path. This can be meaningful if you have complex projects with external dependencies (e.g. libraries) and don’t want to manually transfer the binaries.
(for MPSS 3.1.2 or 3.1.4, please see Errata)

Note that we use C/C++ Remote Application here. This is also true for Fortran applications because there’s no remote debug configuration section provided by the Photran* plug-in!

In Debugger tab, specify the provided Intel GNU* GDB for Intel® MIC (here: gdb-mic).

In the above example, set sysroot from MPSS installation in .gdbinit, e.g.:


	set sysroot /opt/mpss/3.1.4/sysroots/k1om-mpss-linux/

You can use .gdbinit or any other command file that should be loaded before starting the debugging session. If you do not specify this you won't get debugger support for system libraries.

Note:
See section Debugging on Command Line above for the correct path of GDBServer, depending on the chosen package (Intel^® MPSS or Intel® Parallel Studio XE Composer Edition)!

In Debugger/Gdbserver Settings tab, specify the uploaded GDBServer (here: /tmp/gdbserver).

Build Native Application for the Coprocessor

Configuration depends on the installed plug-ins. For C/C++ applications we recommend to install the Intel® C++ Compiler XE plug-in that comes with Intel® Parallel Studio XE Composer Edition. For Fortran, install Photran* (3^rd party) and select the Intel® Fortran Compiler manually.

Make sure to use the debug configuration and provide options as if debugging on the host (-g). Optionally, disabling optimizations by –O0 can make the instruction flow comprehendible when debugging.

The only difference compared to host builds is that you need to cross-compile for the coprocessor: Use the –mmic option, e.g.:

After configuration, clean your build. This is needed because Eclipse* IDE might not notice all dependencies. And finally, build.

Note:
That the configuration dialog shown only exists for the Intel® C++ Compiler plug-in. For Fortran, users need to install the Photran* plug-in and switch the compiler/linker to ifort by hand plus adding -mmic manually. This has to be done for both the compiler & linker!

Start Native Debugging

Transfer the executable to the coprocessor, e.g.:

Copy manually (e.g. via script on the terminal)
Use the Remote Systems window (RSE) to copy files from host and paste to coprocessor target (e.g. mic0):

Select the files from the tree (Local Files) and paste them to where you want them on the target to be (e.g. mic0)
Use NFS to mirror builds to coprocessor (no need for update)
Use debugger to transfer (see earlier)

Note:
It is crucial that the executable can be executed on the coprocessor. In some cases the execution bits might not be set after copying.

Start debugging using the C/C++ Remote Application created in the earlier steps. It should connect to the coprocessor target and launch the specified application via the GDBServer. Debugging is the same as for local/host applications.

Note:
This works for coprocessor native Fortran applications the exact same way!

Documentation

More information can be found in the official documentation:

Intel^® MPSS:
- MPSS 2.1:
  <mpss_root>/docs/gdb/gdb.pdf
  <mpss_root>/eclipse_support/README-INTEL
- MPSS 3.*:
  not available yet (please see Errata)
Intel® Parallel Studio XE Composer Edition:
<composer_xe_root>/Documentation/[en_US|ja_JP]/debugger/gdb/gdb.pdf
<composer_xe_root>/Documentation/[en_US|ja_JP]/debugger/gdb/eclmigdb_config_guide.pdf

The PDF gdb.pdf is the original GNU* GDB manual for the base version Intel ships, extended by all features added. So, this is the place to get help for new commands, behavior, etc.
README-INTEL from Intel® MPSS contains a short guide how to install and configure the Eclipse* IDE plug-in.
PDF eclmigdb_config_guide.pdf provides an overall step-by-step guide how to debug with the command line and with Eclipse* IDE.

Using Intel^® C++ Compiler with the Eclipse* IDE on Linux*:
http://software.intel.com/en-us/articles/intel-c-compiler-for-linux-using-intel-compilers-with-the-eclipse-ide-pdf/
The knowledgebase article (Using Intel® C++ Compiler with the Eclipse* IDE on Linux*) is a step-by step guide how to install, configure and use the Intel® C++ Compiler with Eclipse* IDE.

Errata

With the recent switch from MPSS 2.1 to 3.1 some packages might be incomplete or missing. Future updates will add improvements. Currently, documentation for GNU* GDB is missing.
For MPSS 3.1.2 and 3.1.4 the respective package mpss-3.1.[2|4]-k1om.tar is missing. It contains binaries for the coprocessor, like the native GNU* GDB for the coprocessor. It also contains /usr/libexec/sftp-server which is needed if you want to debug native applications on the coprocessor and require Eclipse* IDE to transfer the binary automatically. As this is missing you need to transfer the files manually (select “Skip download to target path.” in this case).
As a workaround, you can use mpss-3.1.1-k1om.tar from MPSS 3.1.1 and install the binaries from there. If you use MPSS 3.1.4, the native GNU* GDB is available separately via mpss-3.1.4-k1om-gdb.tar.
With MPSS 3.1.1, 3.1.2 or 3.1.4 the script <mpss_root>/mpm/bin/start_mpm.sh uses an incorrect path to the MPSS root directory. Hence offload debugging is not working. You can fix this by creating a symlink for your MPSS root, e.g. for MPSS 3.1.2:

$ ln -s /opt/mpss/3.1.2 /opt/mpss/3.1

Newer versions of MPSS correct this. This workaround is not required if you use the start_mpm.sh script from the Intel® Parallel Studio XE Composer Edition package.
For MPSS 3.* the coprocessor native GNU* GDB requires debug information from some system libraries for proper opteration.
Beginning with MPSS 3.1, debug information for system libraries is not installed on the coprocessor anymore. If the coprocessor native GNU* GDB is executed, it will fail when loading/continuing with a signal (SIGTRAP).
Current workaround is to copy the .debug folders for the system libraries to the coprocessor, e.g.:

$ scp -r /opt/mpss/3.1.2/sysroots/k1om-mpss-linux/lib64/.debug root@mic0:/lib64/
MPSS 3.2 and 3.2.1 do not support offload debugging with Intel® Composer XE 2013 SP1.
Offload debugging with the Eclipse plug-in from Intel® Composer XE 2013 SP1 does not work with Intel MPSS 3.2 and 3.2.1. A configuration file which is required for operation by the Intel Composer XE 2013 SP1 package has been removed with Intel MPSS 3.2 and 3.2.1. Previous Intel MPSS versions are not affected. Intel MPSS 3.2.3 fixes this problem (there is no version of Intel MPSS 3.2.2!).

Abstract

This case study shows how Volumental used Intel® RealSense™ technology with its cutting-edge 3D modeling and virtualization software to scan a customer’s feet in real time so consumers could select an appropriately sized pair of shoes. With Volumental's software and the Intel® RealSense^TM F200 camera and SDK, capturing three angles in 3D is sufficient to size feet within 2mm (1/12^th of an inch). Now that the Intel Real Sense camera(s) will be available in Ultrabook™, 2 in 1, and all-in-one systems, Volumental sees a world with custom fitting shoes, clothes and even medical devices will be within reach of the mass market.

Introduction

If you’ve ever shopped for children’s shoes, you know that buying the right-sized pair of shoes is challenging. Not only is your child growing fast, but you have to get your child to sit still to try on shoes. Then you have to wonder about the accuracy of his or her response about the fit of the shoes, given the shoes are associated with a favorite cartoon character.

What if your child’s feet could be quickly and accurately measured before trying on any shoes so that you could limit the selection to shoes in that size?

Volumental and Intel® RealSense™ Technology

Volumental (https://www.volumental.com/) has a plan to realize that concept using Intel RealSense technology. And 3D scanning for accurate measurement of the body won’t just be for measuring feet and buying shoes. Caroline Walerud, CEO says: “At Volumental we believe that everything you wear should be made to fit you, not the other way around.” Volumental believes that 3D scanning, most notably of the body and body parts, will open up the field of product customization, not just better fitting clothes and shoes but medical devices as well. And now with Intel RealSense technology, this reality will be within the reach of the mass market.

Volumental is a 3D body scanning startup, a spinoff from a doctoral research project in Computer Vision at the Royal Institute of Technology in Stockholm. When Intel announced Intel® RealSense^TM hardware and software, Volumental took notice and immediately saw the technology as a vehicle for their cutting-edge 3D modeling and visualization software. But moving from a broad concept to an actual project took some innovation.

Intel led with the user-facing Intel® RealSense^TM F200 camera, integrated into Ultrabook™, 2 in 1, and all-in-one systems, while Volumental wrote the code to measure and create 3D models of feet, first for children (the more difficult) and then adults.

Volumental did user testing to see how consumers
would “naturally” try to measure their feet using a laptop or tablet.;
Intuitively, users thought they would move a device
around their foot to perform a scan (Figure 1),
rather than place a device on the floor.

But once shown a visual with the device on the floor, users agreed that made more sense. It became obvious that a 2 in 1 PC in tent mode (or stand mode) provided the the best experience (Figure 2). It was important that users should be able to scan bare or socked feet, in the interest of creating a product that wouldn’t feel awkward to use, and that was easy and intuitive. By adding user instructions for the position for each of the 3 poses, it’s possible to get good results in a home setting.

For retail stores, where shoe departments want to allow self-service but not risk customers walking off with the scanning device, a foot scanning kiosk, like the one shown in Figure 3, was the right solution. Diagrams on the bottom pad show the user how and where to stand.

Using the Intel RealSense depth and color cameras, Volumental has created an application that takes 3D images of the feet, either bare or in socks. The application scans the feet using three views, detecting each foot and the direction it is facing (Figure 4).

The Intel RealSense 3D camera provides both a color image and corresponding depth information for each pixel.

The Volumental software analyzes the data from the three snapshots and provides the length, width, and girth around the instep, creating a useful 3D model of the customer’s feet. The resulting model captures thousands of measurements and can be used for both size recommendation and the making of bespoke shoes.

Figure 5 shows an example of a customer’s 3D model, and shoe stores can provide a catalog of footwear available in that size.

How it works

Using pre-beta release hardware and the Intel RealSense SDK 2014, Volumental, Intel, and PLAE, a San Francisco-based children’s shoe manufacturer, showed a demo of the possibilities of measuring children’s feet at the Intel Developer Forum in San Francisco in 2014. And early in 2015, Volumental and Intel showed off their latest version—a freestanding kiosk computer with the Intel RealSense F200 camera at foot level, which will be placed in some retail shoe departments in 2015.

The ShoeSizer software combines computer vision and machine learning to create accurate 3D models of feet in a few seconds. It’s ok if the feet are moving (slightly) as Volumental uses algorithms that keep track of the 3D trajectory and make sure the result is accurate.

The software’s algorithms are based on machine learning, and the algorithms are trained on large databases of feet to ensure the creation of accurate models even when there is image noise or missing data. While the algorithms and actual processing are Volumental’s intellectual property, Intel was able to help improve performance by focusing on multithreading using OpenMP*. The resulting models contain more information related to the foot’s size than just a conversion to shoe size.

Other Challenges

Touchscreen systems requiring the use of the hands aren’t helpful in this usage that focuses on feet. However, the additional capabilities of Intel RealSense technology including the capability to use voice commands quickly became valuable. The kiosk accepts user’s voice commands to activate the scanning process.

But one has to consider that there’s a vast variety of socks, all with different imaging factors. It took extensive testing to find out that white cotton works the best but other colors, patterns and textures can be worn – although black, heavy texture was originally a challenge. Volumental’s code had to adjust to accept a wide range. And, believe it or not, the floor color and texture are also important since the plane of the floor is a factor in measurement. This is another benefit of measuring at a kiosk with a base for the foot scan.

Beyond the shoe

Volumental CEO Caroline Walerud comments “This is only the beginning for Volumental, we are looking at productifying and commercializing this proof of concept…and are very excited about the opportunity to bring our first solutions to the market. We see easy foot data capture as a step towards an entirely new way of manufacturing shoes in a more localized and customized manner. In the future manufacturing will change dramatically; it will involve individual customers to a much greater extent than today.”

While inviting for retail shoe shopping, there is also value to the orthotics and medical device industries and to forward-thinking footwear companies to offer product customization. Volumental is currently working on a number of customer projects with partners in orthotics and bespoke shoemaking in addition to major shoe retailers. With new cameras coming from Intel you’ll soon be seeing 3D scanning for consumers wherever you shop.

About the Author

Colleen Culbertson is a Platform Application Engineer with the Developer Relations Division, who authors articles and a regular blog on the Intel® Developer Zone.

Notices

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.

Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.htm

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark* and MobileMark*, are measured using specific computer systems, components, software, operations, and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products.

Any software source code reprinted in this document is furnished under a software license and may only be used or copied in accordance with the terms of that license.

Intel, the Intel logo, and Intel RealSense Ultrabook are trademarks of Intel Corporation in the U.S. and/or other countries.

Copyright © 2015 Intel Corporation. All rights reserved.

*Other names and brands may be claimed as the property of others.

Purpose

Introduction

Code Access

Build Directions

Build

Compiler Flags Used

Run Directions

Use the appropriate MPI fabric using the following:

Use the appropriate MPI fabric using the following:

Performance and Optimizations:

References and Resources

Contents

Contents