Am 12.12.2018 um 04:51 schrieb Ryan Joseph:
> I’ve spent some time in the compiler sources now and I’m curious just where
> people think the bottle necks for performance actually are. It’s such a
> complicated system for anyone one person to have a good understanding of so
> it’s not clear where
> On Dec 12, 2018, at 7:20 PM, Martok wrote:
>
> Checking out the memory manager(s) could be useful as well - there are a lot
> of
> small allocations, that generally tends to put much stress on it.
> And any improvement there would also directly benefit user applications.
I was going to say
Op 12/12/2018 om 1:49 PM schreef Ryan Joseph:
This is especially a good idea because the compiler is a one pass
program so leaks over the long term aren’t a problem.
(well, unless it is integrated in the textmode IDE "fp" of course)
___
fpc-devel mai
> On Dec 12, 2018, at 7:20 PM, Martok wrote:
>
> Checking out the memory manager(s) could be useful as well - there are a lot
> of
> small allocations, that generally tends to put much stress on it.
> And any improvement there would also directly benefit user applications.
I noticed today whe
- Reply to message -
Subject: Re: [fpc-devel] x86_64 Optimizer Overhaul
Date: 2018. gada 6. decembris 18:57:29
From: J. Gareth Moreton
To: FPC developers' list
> I believed I've fixed the bug. Thanks for your
help.
Now it's way better. -O3 and -O4 works fine.
Speed test for my prog
Currently, compiled programs shouldn't show any measurable difference in
running speed because the overhaul just attempts to make compilation faster
overall.
Nice spot with the "incq" command there. It wasn't intentional for that
to be split into 3 commands, but is likely just a side-effect of
> Nice spot with the "incq" command there. It
wasn't intentional for that to be split into 3
commands, but is likely just a side-effect of pass
1 not being run twice now... granted, since one of
my criteria was that the code should not be less
optimal, I'll see if I can watch out for that one.
> On Dec 12, 2018, at 7:59 PM, Ryan Joseph wrote:
>
> For example every time you it parses “1 + 1” a large code block is entered
Correction, 1+1 doesn’t enter a large code block unless there’s an overload
present. Once you add overloads however that’s when a caching solution would
start help
By the way, what generates that set of
operations? I'm curious because I want to
see what's going on in the compiler. You
see, "incq" and that "mov, add, mov" set
aren't equivalent; anything over
$1 gets truncated with the set,
but not with "incq", although it's not a
concern if only
- Reply to message -
Subject: Re: [fpc-devel] x86_64 Optimizer Overhaul
Date: 2018. gada 12. decembris 17:02:02
From: J. Gareth Moreton
To: FPC developers' list
> By the way, what generates that set of
> operations? I'm curious because I want to
> see what's going on in the compiler.
10 matches
Mail list logo
