Build/run as startup time

[jojoguy10]

Hey,

Just wondering. How long does it take for you to build and then run as startup?

It seems to take a long time for us, and I just wanted to make sure it wasn't just us. It could take a good 7 minutes to build and then run as startup.

Maybe it's our hardware?

[billbo911]

Originally Posted by jojoguy10

Hey,

Just wondering. How long does it take for you to build and then run as startup?

It seems to take a long time for us, and I just wanted to make sure it wasn't just us. It could take a good 7 minutes to build and then run as startup.

Maybe it's our hardware?

I remember this came up last year as well, but honestly, I don't recall if there was a solution or suggestion to address it posted. I know we struggled with this all season as well.
I also don't recall the same amount of time being needed prior to 2013.

[Joe Ross]

Are you using the classmate, or another computer? Really long build times are normal on the classmate, even before the 2013 compiler bug that caused long build times for everyone.

[bvisness]

Our build times were always somewhat long, although I don't think they ever took more than a few minutes. I never timed it. Run as startup never took more than 10 seconds.

[jojoguy10]

Interesting. When I joined the team last year, all the programmers were wondering why it took longer than last year (2012) as well :-/

We are NOT using the classmate. We have tried an HP with an i5 and 6GB RAM and also a small Lenovo with maybe 1GB RAM and a Pentium I believe.

So, I guess it's not just me. The Run as startup takes about 2 minutes for us as well. Interesting.

[criogod]

Don't worry too much about this. The reason it takes a while is because the computer first compiles the code, connects to the crio on the network, ftp's the file, and then runs the code.

[criogod]

Originally Posted by Joe Ross

Are you using the classmate, or another computer? Really long build times are normal on the classmate, even before the 2013 compiler bug that caused long build times for everyone.

I didn't know about that bug, 2013 was our rookie year so we just assumed that was how long compiles normally took.

[Mark McLeod]

I took some timings:

E12 Classmate (32-bit, 2GB memory, Atom N2600 1.6GHz)

• Arcade HW only
  • 3:40 - 1st build
  • 1:39 - 2nd build no changes
  • 2:12 - subsequent builds with 2 vis changed
  • 0:25 - Run as startup
• Arcade HW & Sim
  • 4:30 - 1st build
  • 1:38 - 2nd build no changes
• 3:53 - Formatting cRIO to v52

HP Pavilion (64-bit, 3GB memory, AMD E-350-1.6GHz)

• Arcade HW only
  • 2:06 - 1st build
  • 2:02 - 2nd build no changes
  • 2:46 - subsequent builds with 2 vis changed
  • 0:21 - Run as startup
• Arcade HW & Sim
  • 2:39 - 1st build
  • 2:02 - 2nd build no changes
• 4:05 - Formatting cRIO to v52

[jojoguy10]

Originally Posted by Mark McLeod

I took some timings:

E12 Classmate (32-bit, 2GB memory, Atom N2600 1.6GHz)

• Arcade HW only
  • 3:40 - 1st build
  • 1:39 - 2nd build no changes
  • 2:12 - subsequent builds with 2 vis changed
  • 0:25 - Run as startup
• Arcade HW & Sim
  • 4:30 - 1st build
  • 1:38 - 2nd build no changes
• 3:53 - Formatting cRIO to v52

HP Pavilion (64-bit, 3GB memory, AMD E-350-1.6GHz)

• Arcade HW only
  • 2:06 - 1st build
  • 2:02 - 2nd build no changes
  • 2:46 - subsequent builds with 2 vis changed
  • 0:21 - Run as startup
• Arcade HW & Sim
  • 2:39 - 1st build
  • 2:02 - 2nd build no changes
• 4:05 - Formatting cRIO to v52

Wow - Very interesting! So, I wonder how fast it would build on, say, a dual Xeon 64 GB RAM powerhouse computer. :-P

Thanks for the numbers!

[Invictus3593]

Originally Posted by jojoguy10

So, I wonder how fast it would build on, say, a dual Xeon 64 GB RAM powerhouse computer. :-P

It's not dual, but our team actually has a Xeon 3.5gHz and 16gb of ram with dual gtx550s and we use LabVIEW. The RAM is plenty for the operations with about 10gb to spare, but I think there's still room for improvement on the processor side.

All-in-all, with the biggest project we've done, took >30 seconds on the first build, ~20 on no changes, ~27 with changes to 4 or 5 vis. Run as startup is mostly dependent on your crio processor and your connection to the device; our run as startup takes anywhere from 5-9 seconds. I have yet to test our crio image time

Too bad we can't use GPU compiling

[Nirvash]

Originally Posted by jojoguy10

Wow - Very interesting! So, I wonder how fast it would build on, say, a dual Xeon 64 GB RAM powerhouse computer. :-P

Thanks for the numbers!

For Labview, a dual Xeon wouldn't help much, as it is very single threaded. Ended up being 1:05 on that machine for first build with an Arcade HW only. (Dual Xeons at 2.13 GHz)

On my run of the mill i7 920, the same build was 0:43, as it is clocked higher then the Xeon's at 3.99 GHz

[Greg McKaskle]

You are correct that the compile and build portion of LV is limited to being single threaded. What you may want to experiment with is whether you keep your VIs open when you build, or whether you close them first and then build.

My computer is in a weird state at the moment with other projects, so I wouldn't trust my numbers anyway.

The build loads all of your VIs and the libraries into a build context. If the VIs are in memory, it transfers those from the intel context to the PPC context, compiling and loading alternate libraries as needed from disk.

If the VIs are kicked out of memory, the VIs will all be loaded from disk into the new context. From what I saw last year, both routes performed compiles they didn't need to, but the bugs were reported and some of the biggest ones were fixed. My suspicion is that the disk route will be faster, but it would be helpful to do both and please post your results.

Greg McKaskle

[Nirvash]

Originally Posted by Greg McKaskle

You are correct that the compile and build portion of LV is limited to being single threaded. What you may want to experiment with is whether you keep your VIs open when you build, or whether you close them first and then build.

My computer is in a weird state at the moment with other projects, so I wouldn't trust my numbers anyway.

The build loads all of your VIs and the libraries into a build context. If the VIs are in memory, it transfers those from the intel context to the PPC context, compiling and loading alternate libraries as needed from disk.

If the VIs are kicked out of memory, the VIs will all be loaded from disk into the new context. From what I saw last year, both routes performed compiles they didn't need to, but the bugs were reported and some of the biggest ones were fixed. My suspicion is that the disk route will be faster, but it would be helpful to do both and please post your results.

Greg McKaskle

I ran a few tests on my Xeon machine, it averaged about 58 seconds with the VIs open and 59 with them closed.
That machine is probably more disk limited then it is memory which could explain the results. I will test some more latter tonight/tomorrow on a slower machine and see if the difference between them increases.