I’ve just checked code into the trunk that speeds up compilation of
the swig generated code, as well as reducing the number of
dependencies for each piece.
-r4255 refactors gnuradio_swig_python.{cc,py} into 5 separate .so’s
These correspond to the runtime, general, filter and io directories,
and also includes a new directory, gengen. gengen contains that part
of general that was machine generated. This split is arbitrary, but
was useful for getting size of the swig generated glue code for
general down to about 2MB.
In addition, the swig glue is now compiled with -g1 -O1 instead of
-g -O2. With this change all the swig code now compiles in about 60%
of the time that it used to take.
Packagers, please note that there are now 5 SWIG generated .so’s and
.py’s in gnuradio-core that replace the previous 1
(gnuradio_swig_python.{so,py})
I’ve just checked code into the trunk that speeds up compilation of
the swig generated code, as well as reducing the number of
dependencies for each piece.
I did a make clean, updated, and then rebuilt (autogen, configure,
make) on NetBSD/i386 4.99.1. It built without errors, and the “stabs”
warnings I reported earlier are gone, probably because the number of
labels is down below 16 bits or something like that.
I noticed 330 MB working set on one of the cc1plus processes, but I
remember that I had to up a build machine from 512 to 768 to avoid
pain.
make check also succeeded (after I deleted the pkgsrc packages;
apparently that version of the libs was getting picked up by the
gr-usrp tests).
In addition, the swig glue is now compiled with -g1 -O1 instead of
-g -O2. With this change all the swig code now compiles in about 60%
of the time that it used to take.
Packagers, please note that there are now 5 SWIG generated .so’s and
.py’s in gnuradio-core that replace the previous 1
(gnuradio_swig_python.{so,py})
What are the issues with the compile time? This topic came up previously
in
discussions which determined that documentation will nolonger be
generated by
default due to build time.
I can’t see the point for doing so. I don’t care if its takes me 15
minutes or
30 minutes to compile all GNU Radio.
Compilation time saved will now be spend waiting for the download?
the swig generated code, as well as reducing the number of
-g -O2. With this change all the swig code now compiles in about 60%
discussions which determined that documentation will nolonger be generated
by
default due to build time.
I can’t see the point for doing so. I don’t care if its takes me 15
minutes or
30 minutes to compile all GNU Radio.
I care quire a lot. I really hate sitting around waiting for a compile
to
finish for testing new ideas and code.
Thanks, Eric! This is really great.
Compilation time saved will now be spend waiting for the download?
On Sat, 2007-01-13 at 16:12 +1030, Berndt Josef W. wrote:
I can’t see the point for doing so. I don’t care if its takes me 15 minutes or
30 minutes to compile all GNU Radio.
The biggest improvement isn’t the compile time, it’s the fact that the
memory working set for g++ when compiling the previous
gnuradio_swig_python.cc file was 650 MB. This would cause massive swap
thrashing on machines with say, 512 MB of RAM, or less, and drive the
compilation time up to potentially hours.
I just tested the working set size and it comes up to 370 MB now.
In addition, the break up reduces the coupling of the different parts of
GR, so changes in (many) header files no longer trigger a complete
recompile. For developers, we’re doing this all day long, so its a
major time saver.
Compilation time saved will now be spend waiting for the download?
On Mon, Jan 15, 2007 at 10:19:19AM +0100, Trond D. wrote:
thrashing on machines with say, 512 MB of RAM, or less, and drive the
compilation time up to potentially hours.
This is great! I have a fairly new machine with 1G ram and a dual core
AMD cpu, and compiling GNU Radio used to bring the computer to its
knees :), so this is a great improvement.
Glad to hear that it’s working for you!
It is also good news as I intend to run GNU Radio on my EKIFA single
board computer, which only has 128MB of RAM.
Trond D.
Running in 128 MB should be find. I think that compiling in 128MB may
still be a challenge. You may want to consider a cross-development
setup.
was useful for getting size of the swig generated glue code for
What are the issues with the compile time? This topic came up previously in
discussions which determined that documentation will nolonger be generated by
default due to build time.
I can’t see the point for doing so. I don’t care if its takes me 15 minutes or
30 minutes to compile all GNU Radio.
I do care if it takes me 3 hours or 1 hour to compile gnuradio
(apperently you never compiled gnuradio on windows and you have lots of
RAM)
This is great! I have a fairly new machine with 1G ram and a dual core
AMD cpu, and compiling GNU Radio used to bring the computer to its
knees :), so this is a great improvement. It is also good news as I
intend to run GNU Radio on my EKIFA single board computer, which only
has 128MB of RAM.
I just got the USRP running with an EFIKA board and OSSIE SCA. I’m
using the usrp-0.12 tarball. I had to use a USB2.0 controller in the
PCI slot to work around the usrp USB full speed problems I am having.
I took a quick look at using openembedded to build gnu radio. Thet
already support most of the required dependencies, but I noticed fftw
is missing. When I am bored (heh) I’ll see about adding fftw and
seeing if I can get gnu radio to build in cross environment.
On Mon, Jan 15, 2007 at 11:08:08AM -0500, Philip B. wrote:
I just got the USRP running with an EFIKA board and OSSIE SCA. I’m
using the usrp-0.12 tarball. I had to use a USB2.0 controller in the
PCI slot to work around the usrp USB full speed problems I am having.
I took a quick look at using openembedded to build gnu radio. Thet
already support most of the required dependencies, but I noticed fftw
is missing. When I am bored (heh) I’ll see about adding fftw and
seeing if I can get gnu radio to build in cross environment.
