From mint-bounce@lists.fishpool.fi Wed Feb 27 20:38:53 2008 Message-ID: <47C5D05F.4080601@freesbee.fr> Date: Wed, 27 Feb 2008 22:04:31 +0100 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] Some mintlib patches References: <47BC986B.7050704@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id m1S1crZP011985 Hello. > I agree with you on this after all, maybe there's really m68020-60 vs > m68060 difference out of question. However, I have one experience where > at least 68000 vs m680[20-]60 had not some but DRASTIC effect -- and > that was gcc. First of all, I know only the ST hardware... I know nearly nothing about Falcon, 68030 and FPU... So don't blame me too much. I don't know if GCC makes a big difference between -m68020-60 and -m68060. In order to know it, we have to make a realistic benchmark with a C program which runs slow, without any hand-written assembly code. Archivers usually use only integers, and are slow with big files (even on a ramdisk). Good candidates may be gzip, bzip2, infozip... For the FPU, it may be harder to compare, because it relies on the quality of the libm, and its respect of the different CPU options. Some math intensive program, like POV-Ray, could be a good benchmark. Another very important parameter is alignment. As discussed here not long ago, aligning the longs on multiples of 4 does matter in the FastRAM, and I believe it could make a big difference. Because the current GCC doesn't try to align the longs, their alignment is just random ! So any benchmark with randomly aligned longs will produce random results. So before benchmarking, we must align the longs. It may not be so difficult. The kernel could stay unaligned, because it stays in memory, so its speed will remain the same between all tests. Care must be taken to keep unchanged the structures shared by the kernel and the MiNTLib to not break the kernel binary compatibility. Any other structure can be realigned, as long as every library using it is recompiled, too. We have to ensure the stack is always long aligned, as well as malloc(), and that's all After that, another interesting test would be to do the benchmark with different PRG flags (using FastRAM or not). Anyway, some benchmarking may be interesting even without alignment... -- Vincent Rivière