[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Benchmarking
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 7 Sep 2010 07:01:59 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uDNhSIuckvcPJDQB8RqEH8zYQeaQzKUha/rc42RFUSY=; b=wO4EvGUqiYLkSv12otwITK5dgtvpih4Dkp4ZUqEnpdk1VjwjAJ0CEZMarm6vnDLGrm zL+dU6YdGSUlckeLgnFKjuLlkWDUdqD8/+HjKBUu5oNO0ptmPxk2twMgK1JpEwU1nGp8 4KSnKYBylse1lhDeEnP3V/JzjkmiyWGgjJCX0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=xDfcCxfgDIw7elDdAU4+p5tLdEOIi0jnqtKzFm9g2fnMeemoYFo4lEMVQqhdNRs+/f 3cLv4Kk0glAscbLul6cAc66G1yvTslZjMRTt/oh86QSSNQclt4gUv6Oj69G+Zw3xg5mu l0z/kymoZdSzcLhXp0nZOf5EAEbhNa13AnDMQ=
2010/9/7 Daniel Stonier <d.stonier@xxxxxxxxx>:
> Hi lads,
>
> I've been trying to benchmark eigen2 and eigen3's geometry modules
> recently just to get an idea of the speed we can run various
> structures at, but I'm having a hard time getting consistent results
> and thought you might be able to lend some advice.
>
> Typically, I do things in the following order on a linux platform with
> rt timers (ie clock_gettime(CLOCK_MONOTONIC,...))
Use clock_gettime(CLOCK_PROCESS_CPUTIME_ID) instead. But we have a
timer class doing that for you, in eigen/bench/BenchTimer.h
Let me know if you still have inconsistent results.
Benoit
>
> ###########################################
> set the process as a real time priority posix process
> select transform type
> begin_loop
> - fill transform with random data
> - timestamp
> - do a transform product
> - timestamp again
> - push time diff onto a queue
> repeat
> do some statistics
> ###########################################
>
> The times I have coming out are extremely inconsistent though:
>
> - if repeating only 100 times, the product might come out with times
> of ~840-846ns one run, then sometimes 300-310ns on another run.
> - if repeating 10000 times, it will run at ~840ns for a long time,
> then jump down and run at 300-310ns for the remainder.
> - running other tests in the loop as well (taking separate timestamps
> and using multiple queues) can cause the calculation time to be very
> different.
> - e.g. this test alone produces results of ~600ns, mingled with
> other tests it is usually ~840ns.
>
> Some troubleshooting:
>
> - it is not effects from multi-core as the same problems happen when
> using taskset to lock it onto a single core.
> - it shouldn't be from the scheduler either because it is an elevated
> posix real time process.
>
> I'm baffled. Would really love to know more about how my computer
> processes in such a humanly erratic fashion and what's a good way of
> testing that.
>
> Cheers,
> Daniel Stonier.
>
> --
> Phone : +82-10-5400-3296 (010-5400-3296)
> Home: http://snorriheim.dnsdojo.com/
> Yujin Robot: http://www.yujinrobot.com/
> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>
>
>