On 22/11/2019 17:37, Martin wrote:
> I read several mails in the past that pointed out how fast fpc would
> compile itself, if one uses "make --jobs=10" or similar.
>
> If that is true, then first question: Does it work on Windows?
Yes, but afaik not in the way that fpcmake-generated files uses
I read several mails in the past that pointed out how fast fpc would
compile itself, if one uses "make --jobs=10" or similar.
If that is true, then first question: Does it work on Windows?
Using make from
https://svn.freepascal.org/svn/fpcbuild/trunk
folder install\binw64
Having checked from
> Does that mean in some situations, if you have a small, tight loop, it
> might be better to optimise over speed in some very rare cases? For
> example, turning MOV EAX, $ into OR EAX, $FF to squeeze out a
> few extra bytes, even though the instruction introduces a false dependency.
On 22/11/2019 17:54, Jonas Maebe wrote:
You can enable that by specifying FPMAKEOPT="-T 10" or similar.
Thanks. That is already quite an improvement.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 21/11/2019 22:56, Sven Barth via fpc-devel wrote:
In the meantime I've managed to fix the dynamic package support that
had experienced a bit of bit rot in the last years. Though I've
currently only tested Win32 and Win64 (x86_64-linux as well as
*-darwin *should* work as well). And as
Am 22.11.19 um 17:54 schrieb Jonas Maebe:
On 22/11/2019 17:37, Martin wrote:
I read several mails in the past that pointed out how fast fpc would
compile itself, if one uses "make --jobs=10" or similar.
If that is true, then first question: Does it work on Windows?
Yes, but afaik not in the
Martin schrieb am Fr., 22. Nov. 2019, 19:29:
> On 21/11/2019 22:56, Sven Barth via fpc-devel wrote:
> > In the meantime I've managed to fix the dynamic package support that
> > had experienced a bit of bit rot in the last years. Though I've
> > currently only tested Win32 and Win64 (x86_64-linux
> Op 10/11/2019 om 11:17 schreef Marģers . via fpc-devel
> > Most processors have a fairly large uop cache (up to 2048 for the newest
> >> generations iirc), so this would only be for the first iteration? Do you
> >> have a reference (agner fog page or so) or more explanation for this
> >> that
To optimise SIZE over speed, sorry. Missed a word out.
On 22/11/2019 09:04, J. Gareth Moreton wrote:
Does that mean in some situations, if you have a small, tight loop, it
might be better to optimise over speed in some very rare cases? For
example, turning MOV EAX, $ into OR EAX, $FF
Does that mean in some situations, if you have a small, tight loop, it
might be better to optimise over speed in some very rare cases? For
example, turning MOV EAX, $ into OR EAX, $FF to squeeze out a
few extra bytes, even though the instruction introduces a false dependency.
Gareth
10 matches
Mail list logo
