Quote:
Originally Posted by cpapplefamily
I've posted the code before here on CD. Here it is again https://github.com/GraniteCiyGearhea...ntsABot_Summer admitted its an overburden to read. With some of this feed back we are building a fresh program slowly adding in the functions we really used and focusing on the CPU usage as we go to see if there is a point it get out of control. This is also to get a better understating to what might be happening.
Thanks for all the feed back and confirming 50% is the starting point. |
(As much as I'd love to read through your code and give advice, I'm not a strong Java programmer, and am too busy to really dig in and do it justice)
Admittedly, this is a very C++ targeted answer, but you can use strace to help understand which calls are triggering a RPC, and which calls are accessing the memory mapped IO of the FPGA. As you can probably imagine, the RPC is expensive, and the memory access is cheap. You can likely use strace with Java, but there could be more noise from other calls that Java makes.
I always struggle to get good benchmarking numbers, but the limited numbers that I got were from gperftools' sample based profiler. They showed that most of our execution time was associated with the RPC calls, and a good 60% of the time in the RPC calls was in the kernel.