Multi-core Compiling

[Manzolli]

Even though ibberger touched the concept in the idea , I do think that most o people uses LabVIEW under Windows environment. Compiling a FPGA VI happens all in the PC under Windows. I noticed that during this process the compiler uses only one core. Since I'm using a machine with a 4 core processor, the CPU use rarely goes above 25%.

My idea is to update the compiler allowing it to be multicore. The user should have the option to limit the maximum number of cores available to the compiler. This is necessary because the user may want to continue working, while the compiling process is being done in background.

[Manzolli]

PS.: The missing link to the ibberger's idea is: dedicated FPGA compile server

[ibberger]

improving the FPGA-Compiler performance is allways a good idea :). My proposal did not mean, that you have to have a dedicated FPGA compile server, but you could create one if you have a machine that could be used as a dedicated FPGA-Compile server. If you don't want one, just use the compile server on your working PC.

ATM you can allready use a separate machine as compile server and save resources on your working machine, but this machine is still a Windows PC. My idea was to allow e.g. LV-RT Desktop PCs to run the FPGA-compile-server too, because there is not much overhead from the OS, Virus Scanners and other software, which should give the compiling process some extra resources ...

[gsussman]

I believe the issue with the single CPU core being used is more of a function of the Xilinx FPGA compiler as opposed to anything that NI is doing. I believe that when Xilinx supports multi CPU processors, you will see LV FPGA upgraded shortly after.

[Manzolli]

I think the same as you, gsussman. But we buy LabVIEW from NI. There are lots of outsourcing in it, not only Xilinx. Many times NI buy a company to have more control over their products, avoiding outsourcing. But they can't always do it. For the final user what's matter is the performance of what you get.

The idea here is: we put some pressure on NI. I hope NI will do the same on Xilinx. Then Xilinx will do make their developers life hell (just kidding). Just more guys in the chain!

By the way, we already have 6 core processor for the "masses" (at least I found one store with the new Intel's 980X, with 6 cores and 3.3 GHz, in stock). Imagine if you can reduce the compiling time to 1/4 (not 1/6, just to be conservative). I my machine (Quad Core Q6600, 2,4 GHz) a simple program takes about 12 minutes to be compiled in a 980X based machine with multicore technology should be less than 3 minutes!!!

[Manzolli]

The old version of the program, which gets data from 4 channels in a NI 9234, that took 12 minutes, to compile was replaced for a new version that is getting data from 3 NI 9234 (12 channels @ 51200 s/s each). This new version takes about 30 minutes. Later, to finish my project, I should add code for more 4 or 5 I/O cartridges, imagine how long will take each compile process...

[gsussman]

I feel your pain, I have an application that requires 1.5 hours to compile, however until Xilinx releases their multi core CPU FPGA compiler, I think we are stuck.

While NI has lots of FPGA customers I don't think that leaning on Xilinx will get them to implement this any quicker. Xilinx has a gigantic user base and everyone is well aware of what an improvement multi core compiling would be, however the compiler is not a trivial piece of code. With the applications that Xilinx chips go into, they need to make 100% sure things are right before releasing it.

[Terry_ALE]

CPUs are not getting faster, they are getting more parallel so we need to get with the program.

[AristosQueue (NI)]

Is compilation for FPGA a process that even *can* be made parallel? I know only small amounts about the compile sequence, but the parts that I know are whole program operations that cannot proceed in parallel. For example, when we compile a LV class on FPGA, we traverse from the first control and/or constant of the class type through the entire VI hierarchy, modifying each VI in the chain to take a cluster of that type and cloning the entire VI if it has already been changed to a cluster of another type. The whole hierarchy can only have one such traversal running at any given time. Most of the other steps of building an FPGA program that I know of are similar "whole program" issues.

To me, this is like C++ compilation -- the parsing and building of object files can be parallel, but the linking and optimizing operations are gigantic serial processes that often dwarfs the other operations. With LV on FPGA, parsing and object files are eliminated, and all that is left is the very expensive process of figuring out which gates on the FPGA need to be wired together to make this particular program.

Parallelization of cores is only going to help if the underlying problem has work that can be done in parallel. Optimization problems generally cannot be handled that way. I'd be very surprised if this situation is improvable to any significant degree.

[Manzolli]

Aristos, you may be right at this moment. The processors clock speed is not increasing any as fast as used to be. They didn't reach a technical limit. They reached a economical and practical limit. AMD and Intel are working in two main lines: architecture (optimization and new ones) and cores (increase the number in a chip and increase the number of threads in a core). FPGA is parallel by nature and LabVIEW is by conception. The future is parallel. We write code in LabVIEW and execute in FPGA. If C++ is the bottleneck, a new way to transform G code in FPGA should be used.

[GregSands]

---

Aristos wrote:

Is compilation for FPGA a process that even *can* be made parallel?

---

This post seems to suggest that at least some of the compilation can be parallelized.  Any speedup would be more than welcome!