schrieb Albert Cahalan on 2013-01-28 04:40:
> On Sun, Jan 27, 2013 at 9:22 PM, Patrick Strasser
> <[email protected]> wrote:
>> 2) use --host= or --enable-static etc. or
>> 3) or run CFLAGS="<value>" ./configure ; this should work too:
>> ./configure CFLAGS="<value>" ; CFLAGS will propagate to CPPFLAGS AFAIK.
>
> Passing CFLAGS to configure doesn't stick when I check in.
> It won't help anybody else.
Right. Some may like it, like compiling on a 64 bit machine for a 32 bit
machine. I have a strong, AMD64 bit desktop machine and an old eeePC
701, where I do not want to compile. It easily cross-builds, both
running Debian testing...
>> Just of curiosity, what flags do you want to pass, what do you need it for?
>
> There are a few categories: things that should be used always, things
> that are temporary for me (passing CFLAGS to configure should work),
> and things that need autoconfiguration because they only fit particular
> compiler/hardware choices.
Autoconf can do some checks on architecture and OS.
> Via the configure script I have enabled:
> CFLAGS="-Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing"
I guess these are good anyway.
> In kiss_fft.c and pack.c I have enabled:
> #pragma GCC target("sse3,mmx,arch=prescott,fpmath=sse,no-ieee-fp,recip")
> #pragma GCC
> optimize("fast-math,omit-frame-pointer,unsafe-loop-optimizations,single-precision-constant")
You're doing some very special optimizations. If I understand right,
functions compiled with these pragmas probably won't run on other systems.
Please keep in mind that people already run Codec2/FreeDV on various
architectures, like ia32, amd64 and different arm, more to come.
You can check the architecture in configure AC_CANONICAL_HOST, which
gives you information about architecture, vendor and OS. I'm not sure
how much the code would benefit from special commands, if the code has
not suitable structure, like SIMD instructions in FFT. I found some
config tests in liboil that check for features at build time.
> I may want to compile for profiling; right now I'm going on guesses.
I once tried oprofile. Is that still the preferred tool? I just read
about perf.
> An interesting question related to this: Suppose that 50% of the platforms can
> handle the codec in real-time. Changing code generation increases that to 70%,
> but makes the remaining 30% unable to run the codec at all. Is that good or
> bad?
What do you mean with "unable"? Just won't run, lacking some features it
is compiled for, or running unbearable slow? For distribution, it's not
that difficult to run your own optimized build on Linux and friends, and
for Windows you could ship different optimized binaries or check
processor features at runtime and switch functions accordingly. Maybe
something like ORC [ http://code.entropywave.com/orc/] or VOLK
(Vector-Optimized Library of Kernels) from GNU Radio [
http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk ] (or both)
> It depends on how you value a non-real-time codec.
Non-real time could be still interesting, but not as main target.
Anyway, the codec and the modem need some computing power, and this
requirement won't probably fullfilled by an arbitrary "old" processor.
Is far as I understand the current code is simply what works. There may
be potential for performance optimizations. Some people think it can run
properly on some embedded architectures without floating point support,
but then again this needs porting to fixed point and some expertize in
this field.
> There is also the question
> of how much CPU power must be left for other things in order to be practical,
> and the question of half-duplex vs. full-duplex.
Full duplex is not common in amateur radio. First because only one
frequency is used and TDM is not feasible, second because most
transceivers do not support full duplex. It's kind of a problem to hear
anything when you are sending with 100s of Watts, without proper duplex
spacing.
For other scenarios, like VoIP, duplex is probably reasonable, but I'm
not sure if you are strongly limited in computational power in such
situations.
Anyway, it should run on may platforms, with lots of different hardware
and environments. Running as FreeDV on Linux/Mac OS X/Windows is just
one use case.
Regards
Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser <patrick at wirklich priv at>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
