Re: [Openocd-development] [PATCH] interface decrease calling overhead
On 02/11/2011 07:29 AM, Øyvind Harboe wrote: I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? I am not too fond of this since it exposes internals that should stay internals (variables that were static are now globally visible). This might be OK if there really is a noticeable speed gain. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
On Fri, Feb 11, 2011 at 8:41 AM, Michael Schwingen rincew...@discworld.dascon.de wrote: On 02/11/2011 07:29 AM, Øyvind Harboe wrote: I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? I am not too fond of this since it exposes internals that should stay internals (variables that were static are now globally visible). This might be OK if there really is a noticeable speed gain. I'm also interested to see if there is a design flaw that results in this sort of change having a big impact. That said, with some numbers to back up this particular optimization and no other patch in sight, I'm happy to commit this one. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, i think this patch make sense because the functions are called very often (column calls in the profile data) and do a little bit more then nothing. Am 11.02.2011 07:29, schrieb Øyvind Harboe: I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? If you start optimizing the code with the result of a performance improvement you are looking for functions that called very often and/or use a couple of the application runtime. Not all functions you find can be optimized and its always a compromise between maintainability/clearness, performance and a stable api. I mean the tap stuff inside the interface.c file is part of the heard of openocd and can be made more efficiency. In one part of the file fast tms sequence tables are used and mixed with case statements to determine the tms path and in another part of the file the tap state transistion is determined by a big case statement, why no faster tables there ? Is there any profiling data that backs up this particular optimization as particularly effective? Thats the profile stuff of my session. I read 1 words of the memory and because the nature of the once interface (dsp563xx) there are many tap state changes. With other targets this may not happen because a better/other jtag interface design. Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 31.82 0.07 0.07 131877 0.00 0.00 clock_tms 18.18 0.11 0.04 385430 0.00 0.00 tap_state_transition 13.64 0.14 0.037 0.00 0.00 buf_set_buf 9.09 0.16 0.02 800438 0.00 0.00 tap_get_state *** 9.09 0.18 0.02 607648 0.00 0.00 tap_move_ndx 4.55 0.19 0.01 385430 0.00 0.00 tap_set_state_impl *** 4.55 0.20 0.01 182295 0.00 0.00 tap_get_tms_path_len 4.55 0.21 0.0160767 0.00 0.00 tap_is_state_stable 4.55 0.22 0.0160765 0.00 0.00 ft2232_execute_scan 0.00 0.22 0.00 243066 0.00 0.00 cmd_queue_alloc 0.00 0.22 0.00 232715 0.00 0.00 tap_get_end_state *** 0.00 0.22 0.00 121530 0.00 0.00 jtag_scan_type 0.00 0.22 0.00 121529 0.00 0.00 tap_get_tms_path 0.00 0.22 0.007 0.00 0.00 buf_cpy 0.00 0.22 0.0071110 0.00 0.00 move_to_state 0.00 0.22 0.0060768 0.00 0.00 jtag_queue_command 0.00 0.22 0.0060767 0.00 0.00 ft2232_end_state 0.00 0.22 0.0060767 0.00 0.00 jtag_checks 0.00 0.22 0.0060767 0.00 0.00 jtag_prelude 0.00 0.22 0.0060767 0.00 0.00 tap_set_end_state *** ... snip ... In sum there are 4308134 function calls in this session and the marked 4 functions are called 1479350 times (34%) in sum without any real algorithm inside the function body. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
What kind of CPU are you running OpenOCD on? It's great that you are basing your optimizations on profiling information. That always makes for a convincing case. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, Am 11.02.2011 10:01, schrieb Øyvind Harboe: What kind of CPU are you running OpenOCD on? It's a Intel T7200. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
How about rewriting clock_tms then? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, Am 11.02.2011 10:17, schrieb Øyvind Harboe: How about rewriting clock_tms then? Because the used time? This session was to short (some seconds) to get a meaningful time statistic. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? Is there any profiling data that backs up this particular optimization as particularly effective? It is very surprising that this would make an impact, but that's what good profiling data result in, small changes that are surprisingly effective. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
