Hello, world! As a 19-year software engineer and software architect at Intel in performance and parallelization tools and AI system platforms, I am very lucky and excited to share some of my experiences with you and get your thoughts about software, technology, and Intel. My first focus is trying to tackle the dilemmas of the modern software developer.
Why tackle this first? For as long as I can remember, I have always loved programming and solving problems. I started programming using BASIC when I was in first grade in 1985, when it was still slightly less common. I’ve been fortunate enough (or unfortunate enough?) to have learned a few dozen programming languages, programmed in several IDEs and developed software in both Windows* and Linux* environments. I’ve also had to develop in rapidly evolving areas like web/UI frameworks, cloud development, deep learning, etc.
One constant over this time is that engineers are always fighting their tools to be more productive. As a developer, I want to be efficient as possible to get more work done or to free up my time to do something else in my life. So, this means a lot to me personally.
Narrowing the Scope
Unfortunately for us, there is no one modern software developer. When I write Go* code for microservices or Kubernetes*, I use a quite different toolchain than I do when I’m writing React/Angular/Vue/Javascript* code. There are also a lot of times I need cross-platform support between Windows/Linux/Mac*.
Fortunately, there have been lots of advancements in cross platform IDEs and support. I am a long-time Vi user (no offense, Emacs users; I know Emacs is more powerful), but I like modern IDEs. As an engineer, I love normalizing my workflow across platforms because it makes me more efficient. Luckily for me, the languages I typically use (C/C++/Python*/Javascript/Go) all work reasonably well within Microsoft’s Visual Studio Code* (VSCode*), and recent updates to Microsoft’s Window Subsystem for Linux* (WSL) also work well for cross-platform development.
Given that backdrop, I thought I’d try to see how well I can get some cross platform oneAPI samples running on my Intel® Core™ i9 processor-based Alienware* R13 system (not purchased by Intel).
Setting up WSL and VSCode*
Setting up WSL was painless, I simply opened a Windows command prompt and ran:
> wsl --install
This installed the Ubuntu* 20.04 distro for WSL after a quick, required reboot.
For me the process was painless, but some of my colleagues mentioned that if you do run into issues, Microsoft has provided a handy troubleshooting guide that will guide you through the prerequisite steps to make your system WSL ready.
The next step was setting up my VSCode. I initially tried to setup my VSCode in WSL using a Linux installation workflow, but it turns out that wasn’t the proper way to do it. Following the instructions from Microsoft, I simply had to enable the Remote WSL extension in VSCode following the instructions.
After enabling the extension, it was as easy as asking for a new WSL Window (Figure 1), which popped up as a VSCode WSL-connected Window.
Figure 1. Opening a new WSL window.
Installing the Intel® oneAPI Toolkits
Because I wanted to see if I could run both Linux and Windows oneAPI-based code on my system, I went to the Intel® oneAPI Toolkits release page (Figure 2), selected the toolkits that I wanted, and followed the instructions to install them on my system (Figure 3). I used an apt installation in a WSL terminal and the online installer for Windows.
Figure 2. Selecting the desired Intel® oneAPI toolkits.
Figure 3. Installing the Intel® oneAPI toolkits.
Running Some Code
Now that I theoretically had a working development environment, I cloned the oneAPI-samples repository from GitHub.
This code is designed to be both Windows and Linux compatible, so I loaded up the Libraries > oneMKL > matrix_mul_mkl directory in my WSL VSCode window and opened a bash terminal. I set up the oneAPI environment and built the sample code:
> source /opt/intel/oneapi/setvars.sh
> make
This successfully built and ran the matrix multiplication example (Figure 4).
Figure 4. Building and running the example code
Creating and running the sample using a Windows binary ended up being a little more work, as this was a new system. I had to install the Microsoft Visual Studio* 2022 Community Edition and GNU Make. After that, it again was as simple as loading up VSCode and running:
> C:\Program Files (x86)\Intel\oneAPI\setvars.bat
> make
But Wait, There’s More!
I’m sure many of you know this, but this next thing was an amazing discovery for me: I was playing with VSCode (Windows, not WSL-based) and saw I could select a WSL prompt for my split terminal(Figure 5)! Doing that allowed me to build and run the sample for both Windows and Linux in the same VSCode instance. Cross-platform development on a single system in a single IDE! I cannot express the endorphin high from the magic of this having spent years dealing with pain of cross-platform development.
Figure 5. Running Windows* and Linux* in the same VSCode* instance
The End (For Now)
The nice thing about all of this is I was able to set all of this up on a new system in just a couple of hours. I’ll be writing more on how well this flow works for Intel® Arc™ GPUs, discussing other developer workflows (like Jupyter Notebooks*), diving into software topics like cloud computing and AI system platform development, and sharing my experiences as a software engineer in the technology industry. Thanks for reading!
See Related Content
Related Articles
Related On-Demand Videos
- oneAPI: The Path to Streamlined Cross-Architecture Development
- Tips to Improve Heterogeneous Application Performance
Get the Software
Get started with this core set of tools and libraries for developing high-performance, data-centric applications across diverse architectures.