Eclipse Community Forums: DSDP - Real-Time Software Components (RTSC)

Home » Archived » DSDP - Real-Time Software Components (RTSC) » xdc -j4(Increasing speed of RTSC builds)

Wed, 21 December 2011 12:10

Eclipse User

I feel like I just discovered gold... Here are two quick benchmarks building the same set of packages:

xdc clean -PR ./ti/sdo
xdc -PR ./ti/sdo
--> 100 seconds for the build

xdc clean -PR ./ti/sdo
xdc -j4 -PR ./ti/sdo
--> 41 seconds for the build

Is there any danger or downside to this? In other words, is there any reason why I wouldn't want to do this all the time? If not, I think we need to try to raise better awareness, particularly in people complaining about build times!

Re: xdc -j4 [message #769294 is a reply to message #769260]

Wed, 21 December 2011 13:43

Eclipse User

Brad,
we had a problem before, where we used to build packages for multiple targets for the "whole_program" profile, using the -j option. There were some temporary files that had the same name for different targets, and we couldn't change the names of these files. Since then, the "whole_program" profile was deprecated, and I guess that ti.sdo packages were never built with it.
So, that particular problem might not be relevant anymore, but there could be others. That said, I use the -j option whenever I can and when there are race conditions, the symptoms are easy to recognize. Some generated files are incomplete, and then tools (Java and C compilers) that consume such files would mark them as invalid.

As for people complaining about build times, I remember such complaints from users building single applications and such users wouldn't benefit from the -j option. If there are similar complaints from users who build multiple packages, we could tell them about -j. The natural place for that would be in the docs for the xdc command. Is there any other document you would suggest?

Re: xdc -j4 [message #777658 is a reply to message #769294]

Tue, 10 January 2012 16:49

Eclipse User

I assume that xdc is just passing the "-j4" option down to make, right? This is a tough one because on the one hand I'd like to just make it the default so that people get the performance lift. However, given that it can potentially cause some issues we clearly cannot do such a thing. I guess all we can do is better document the existence of the feature. For example, when I run "xdc -h" the corresponding output does not actually specify that a -j option exists. A quick wiki page on improving build times might also be reasonable.

Re: xdc -j4 [message #778414 is a reply to message #777658]

Thu, 12 January 2012 01:10

Eclipse User

On 1/10/2012 1:49 PM, Brad Griffis wrote:
> I assume that xdc is just passing the "-j4" option down to make, right?
> This is a tough one because on the one hand I'd like to just make it the
> default so that people get the performance lift. However, given that it
> can potentially cause some issues we clearly cannot do such a thing. I
> guess all we can do is better document the existence of the feature. For
> example, when I run "xdc -h" the corresponding output does not actually
> specify that a -j option exists. A quick wiki page on improving build
> times might also be reasonable.
Hummmm. The first paragraph of the "man" page for xdc
(http://rtsc.eclipse.org/docs-tip/Command_-_xdc) says:

The xdc command is used to build packages and executables that use
packages. In its current implementation, xdc is nothing more than a
command shell that invokes the GNU make utility with makefiles that
are either part of XDCtools or generated as part of processing a
package's build script (package.bld). As a result, any command line
option supported by GNU make is also supported by the xdc command
and integration of the xdc command into make based environments is
particularly straightforward.

When I run "xdc -h" I see:

usage: xdc [-h?|--help] [--help-make] [-k] [-n] [-r[a]] [def ...]
[goal ...] [@opt-file] [-P[rRD] package-dir ...]

-h, -?, --help - display this message and exit
--help-make - display GNU make command options

When I run"xdc --help-make" I get the list of GNU make options
(including -j and --jobs)

Re: xdc -j4 [message #778480 is a reply to message #778414]

Thu, 12 January 2012 14:35

Eclipse User

The info is all there, no doubt. I guess the main point of the thread is that many developers won't be able to connect the dots on all this stuff in order to get a blazing fast xdc build. I was thinking of something to speak to people at that level, i.e. an FAQ entry somewhere to the effect of, "Is there any way to make xdc build faster?" where the answer is something to the effect of, Yes, you often can utilize the --jobs option from make since xdc is just a wrapper to make. Therefore building your code using "xdc --jobs 4" on a quad-core computer would see a much faster build time.

If nothing else hopefully the search engines will find this page so that this thread itself helps a few people...

Re: xdc -j4 [message #779574 is a reply to message #778480]

Sun, 15 January 2012 23:24

Eclipse User

On 1/12/2012 11:35 AM, Brad Griffis wrote:
> The info is all there, no doubt. I guess the main point of the thread is
> that many developers won't be able to connect the dots on all this stuff
> in order to get a blazing fast xdc build.
Sorry, I guess I was implicitly asking where else to put the information.

> I was thinking of something to
> speak to people at that level, i.e. an FAQ entry somewhere to the effect
> of, "Is there any way to make xdc build faster?" where the answer is
> something to the effect of, Yes, you often can utilize the --jobs option
> from make since xdc is just a wrapper to make. Therefore building your
> code using "xdc --jobs 4" on a quad-core computer would see a much
> faster build time.

I'll add something the the Build FAQ in the RTSC-pedia. Where else
would you have looked?

Previous Topic:	How to add pre-built library to RTSC-ed one ?
Next Topic:	How to add user library (Linux)

Goto Forum:

-=] Back to Top [=-

Current Time: Thu May 15 15:34:25 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter