*From:*Ryan Tennill [mailto:[email protected]]
*Sent:* vrijdag 23 augustus 2013 16:35
*To:* [email protected]
*Subject:* Re: performance of different versions of libftdi
On 8/23/2013 8:42 AM, Vanheesbeke Stefaan wrote:
Someone can comment on this? How can I boost performance of the
libftdi 1.0 to come closer to the 0.20 release?
Some benchmarks on the target (1GHZ single core AMD-processor,
running windows XP)
The test is just looping a read call, latency set to 1, so
theoretically, 1000 loops / second should be performed. No data is
transferred.
Written in c and compiled with gcc.
TimerMsec t;
t.Start();
while (1)
{
ret = ftdi_read_data(ftdi2, temp, 1024);
if (ret < 0)
printf("Error reading\n");
loops++;
if (t.Peek() > 1000)
{
t.Start();
printf("%d loops\n", loops);
loops = 0;
}
}
- libftdi 1.0 + WinUSB driver --> ~920 loops/second and > 25% cpu-load
- libftdi 0.20 + libusb-win32 driver --> ~900 loops/second and 6
to 8% cpu-load.
Same test on my desktop pc does not reveal these differences (multi
core, more cache, modern operating system, ...)
The first thing I would do is recompile with profiling enabled. When
you run the profiled version it will generate a set of data that
should give you some insight to where CPU time is being consumed. You
probably have the profiler already but I've not done this on Windows
before.
You need to add the -pg option when compiling to enable the profiler
which will then generate a gmon.out the next time you run the
application. Run gprof as shown below to analyze the profile data and
dump it into a readable text file.
gprof <your app> gmon.out > prof_info.txt
There is a lot more info at:
http://www.thegeekstuff.com/2012/08/gprof-tutorial/
<http://www.thegeekstuff.com/2012/08/gprof-tutorial/>
I am very interested in your results seeing as my current project will
be managing upwards of 50 FTDI devices on a single system!
Ryan
On 8/26/2013 2:52 AM, Vanheesbeke Stefaan wrote:
>
> I don't know what you will learn with profiling the loop I showed.
This basically runs only the call to the ftdi library around 1000
times/second.
CPU load means something is consuming execution cycles. Profiling should
give you a cycle count for a chain of function calls including those in
libftdi provided you make the debug symbol available. It won't tell you
exactly what's wrong but it will give you a hint at where things are
taking more / less time to run in your test cases. You might be able to
pull in the libusb debug symbols as well and see if there's something of
interest there.
Ryan
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [email protected]
