From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Mon, 24 Jan 2011 21:07:29 +0100 Subject: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux In-Reply-To: <4D3DD1EC.7010506@arcor.de> References: <1295884607-9044-1-git-send-email-weisserm@arcor.de> <20110124161338.B0345D42A89@gemini.denx.de> <4D3DD1EC.7010506@arcor.de> Message-ID: <20110124200729.2134CB187@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=, In message <4D3DD1EC.7010506@arcor.de> you wrote: > > >> C version: > >> text data bss dec hex filename > >> 202862 18912 266456 488230 77326 u-boot > >> > >> ASM version: > >> text data bss dec hex filename > >> 203798 18912 266288 488998 77626 u-boot > > > > How exactly did you measure the speed improvement? > > I inserted a printf before and after calls to these functions with sizes > of 1MB or more each. I then measured the times between these printfs > using grabserial (http://elinux.org/Grabserial). In both cases caches > where enabled. > > To be precise: As memset test case I used the memset(.., 0, ..) of the > malloc pool (which was 4MB in my case) and a memcpy from flash to RAM > which I inserted in cmd_bootm.c of about 2.2MB (see RFC patch > http://patchwork.ozlabs.org/patch/79480/ for exact location of the memcpy). OK - so which results do you see in reallife use, say when loading and booting an OS? How much boot time can be saved? > Do you think a factor of 2 is not possible against the C version? Maybe > I have done something wrong while measuring theses times. From my point > of view it should be possible to get such improvements as the code takes > cache alignment into account and also uses the PLD instruction. I don;t doubt your measurements. But this being an optimization approach, it seems appropriate to check wether we are really optimizing a hot spot, and if the measured results can be generalized. I guess the speed improvemnt you see for a few large copy operations is just one side - probably there will be slower excution (due to the effort to set up the operations) for the (many more frequent) small operations. In addition, there is an increase of the memory footprint of nearly 1 kB. I think additional measuremnts need to be done - for example, we should check how the execution times change for typical operations like TFTP download, reading from NAND flash and MMC/SDcard, booting a Linux kernel etc. Also, it should be possible to enable this feature consditionally, so users can decide wether speed or size is more important in their configurations. > I can do some additional measurements tomorrow on two systems (jadecpu > with a 32Bit at 166MHz DDR2 memory and a imx25 based on with 16Bit at 133MHz > LPDDR) and come up with some exact numbers. Maybe you can give some more > hints what and how the improvements of this patch can be measured. See above. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Egotist: A person of low taste, more interested in himself than in me. - Ambrose Bierce