From mint-bounce@lists.fishpool.fi Fri Jan 15 11:46:58 2010 Message-ID: <4B509B4F.2020209@gandon.org> Date: Fri, 15 Jan 2010 17:43:59 +0100 From: Benjamin Gandon User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= CC: MiNT Mailing List Subject: Re: [MiNT] gcc 68000 vs 68020-60 vs 68060 comparison References: <4B508C6E.9040507@freesbee.fr> In-Reply-To: <4B508C6E.9040507@freesbee.fr> 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: benjamin.mint@gandon.org 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 o0FGkvpn021965 Vincent Rivière a écrit : > As we discussed long ago, another big source of speed is... alignment > of longs on 32-bit boundaries. We have seen that such aligned longs > are faster than unaligned in the FastRAM. In order to respect the > existing TOS APIs, our GCC never tries to align longs on 32-bit. So > they are randomly slow or fast. Enabling alignment would provide more > speed. But the OS public structures should be protected to keep > unaligned and compatible. This will be a full project. > I made a quick hack in EmuTOS for ColdFire to align the RAM returned > by Malloc() on a 32-bit boundary, the performance was significantly > better. Actually, this is even true for STram on the Falcon030. 4-byte aligned STram access is 10%-20% faster. In Animator, I finally enforced 4-byte alignment for all allocated blocks, but the key performance boost was aligning output of uncompressed video frames into screen memory.