Hans-Peter Diettrich schrieb:
>
> I think that it's time to put aside old experience, and replace it by
> up-to-date performance considerations. And since FPC seems to be
> optimized and tested very well, even if it doesn't look so at the first
> glance, I better concentrate on other tasks.
>
On
Op Thu, 15 Jul 2010, schreef Graeme Geldenhuys:
maintainability is more important to the core team that speed.
No. That is doesn't do justice to all the effort that is put into
performance optimization. It's not about maintainability being more
important.
It is about making the right trad
On 15 July 2010 17:31, Tomas Hajny wrote:
> requested to output no messages at all? Even if this (probably extremely
> rare!) case happens, the difference must be completely negligible unless
> you perform very many compilations of simple and short source files
Our one project alone has over 250 u
Sergei Gorelkin schrieb:
The issue was that, whenever compiler needs to output a message, it:
- loads a messagefile (once in a session)
- looks up the message by number
- performs the parameter substitution (this involves AnsiStrings, so is
somewhat heavy)
- only then checks if it should reall
Sergei Gorelkin schrieb:
Not necessarily. When all currently used files reside in memory, every
(recorded) token can contain an pointer (or offset) into the file
buffer. This may reduce the number of required string copies (not yet
fully researched).
You normally shouldn't ever need to proc
Tomas Hajny schrieb:
This cannot be done because people should have the chance to use custom
error files to override message verbosities.
Couldn't this be delegated to an custom message handler?
Not sure if I understand here. Do you mean that instead of changing few
letters in the message fil
> Such initialized memory may reside in the wrong cache, on multi-core systems.
I don't know about that. I think I recall reading that multi-core
systems share L2 cache memory.
http://en.wikipedia.org/wiki/Multi-core_processor
I know Delphi used to initialize my data structures when I created
t
Hans-Peter Diettrich schrieb:
> Florian Klaempfl schrieb:
>
>>> Unless you are doing a cold compile, the main bottlenecks in the
>>> compiler are the memory manager (mostly the allocation of memory,
>>> freeing is faster), zero-filling new class instances (and partially
>>> resetting the register
Adem schrieb:
>> The FastMM4 uses a LOCKed asm instruction for every memory allocation
> or dis-allocation. This LOCK ensure that a memory is modified by only a
> thread at a time. This is the same LOCKed asm function which is used
> internally by Windows with its Critical Sections. Windows itself
Hans-Peter Diettrich schrieb:
> Florian Klaempfl schrieb:
>
> IMO compiler messages slow down compilation a lot.
How do you know this, did you benchmark or is it just your opinion?
>>> Common knowledge, proved by experience.
>>
>> Please profile the compiler first, people did this already
Tomas Hajny пишет:
On Thu, July 15, 2010 14:06, Graeme Geldenhuys wrote:
Op 2010-07-15 06:26, Sergei Gorelkin het geskryf:
Message processing indeed includes some overhead, but this is not #1
bottleneck to worry about.
Maybe #10 or so.
Well, any optimization is better than none. Irrespective o
Hans-Peter Diettrich wrote:
Not necessarily. When all currently used files reside in memory, every
(recorded) token can contain an pointer (or offset) into the file
buffer. This may reduce the number of required string copies (not yet
fully researched).
You normally shouldn't ever need to
Hans-Peter Diettrich wrote:
But the patches have been rejected? For what reason?
They have been applied in revision 9297.
Regards,
Sergei
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-dev
On Thu, July 15, 2010 15:57, Hans-Peter Diettrich wrote:
> Florian Klaempfl schrieb:
.
.
>>> The message ID has to be re-encoded in a way, that allows to determine
>>> e.g. the message level immediately. All this currently is done only
>>> after text substitution, by inspection of the returned st
On Thu, July 15, 2010 14:06, Graeme Geldenhuys wrote:
> Op 2010-07-15 06:26, Sergei Gorelkin het geskryf:
>>
>> Message processing indeed includes some overhead, but this is not #1
>> bottleneck to worry about.
>> Maybe #10 or so.
>
> Well, any optimization is better than none. Irrespective of wher
On 2010-07-15 17:46, Michael Schnell wrote:
On 07/15/2010 03:36 PM, Sergei Gorelkin wrote:
- FastMM is somewhat slower than FPC's memory manager, but the
difference is small.
Good to know !
- Given the amount of source code in FPC and FastMM, FPC is clearly a
winner :)
Yep. FastMM uses a
Op Thu, 15 Jul 2010, schreef Hans-Peter Diettrich:
This is what I'm going to do now.
Does there exist some profiling code already, or do I have to reinvent the
wheel?
No, simply use the -pg compiler option, the use gprof.
Daniël___
fpc-devel mai
Michael Schnell schrieb:
With small blocks there is no concurrency (as in case of conflict, the
second thread will use medium.
Just an idea: When the lists contain many entries, they could be split
into buckets. Then the currently searched bucket(s) could be locked
against use by other thre
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
zero it again, so where is the gain in that ?
While it's in the freelist, the helper task
... thread ...
zeros it so when it is
allocated again, it needs no zeroing again.
But that then zeroes every deallocation.
Florian Klaempfl schrieb:
Hans-Peter Diettrich schrieb:
I see the biggest benefit in many possible optimization in the scanner
and parser, which can be implemented *only if* an entire file resides in
memory.
Include files, macro expansion and generics make such optimizations hard.
Not neces
Sergei Gorelkin schrieb:
I had benchmarked that, and submitted some patching some (already long)
time ago. Those patches inserted calls to CheckVerbosity before blocks
of messages of rarely used verbosity, like V_Tried.
But the patches have been rejected? For what reason?
This way it was pos
Florian Klaempfl schrieb:
Unless you are doing a cold compile, the main bottlenecks in the
compiler are the memory manager (mostly the allocation of memory,
freeing is faster), zero-filling new class instances (and partially
resetting the register allocator) and tobject.initinstance.
I wonder
Florian Klaempfl schrieb:
IMO compiler messages slow down compilation a lot.
How do you know this, did you benchmark or is it just your opinion?
Common knowledge, proved by experience.
Please profile the compiler first, people did this already.
This is what I'm going to do now.
Does there
On 07/15/2010 03:36 PM, Sergei Gorelkin wrote:
- FastMM is somewhat slower than FPC's memory manager, but the
difference is small.
Good to know !
- Given the amount of source code in FPC and FastMM, FPC is clearly a
winner :)
Yep. FastMM uses a lot ASM, so a plus for FPC RTL.
-Michael
On 07/15/2010 01:28 PM, Marco van de Voort wrote:
How is this conflict detected? If this is a kind of lock, (that needs to be
SMP safe I guess) the FPC manager can probably skip that in most small
allocations, and only has to do this if it really touches global structures?
This is quite a lot
On 07/15/2010 01:14 PM, Florian Klaempfl wrote:
And the third and fourth thread?
Should not make much difference. The time span that is eligible for a
conflict is very short and thus more than two threads at the same time
that can't do the critical action in a normal way is extremely unlikely.
Michael Schnell wrote:
I did not take a look at FPC's memory manager. Maybe someone might want
to do some profiling
I did the extensive profiling when working on fcl-xml package. For a single-threaded application,
the following is true:
- FastMM is somewhat slower than FPC's memory man
Jonas Maebe schrieb:
> Graeme Geldenhuys wrote on Thu, 15 Jul 2010:
>
>> Well, any optimization is better than none.
And before doing a lot of guess work: it is already known that e.g.
fillchar is a bottleneck (probably not only for the compiler). So better
mail the fastcode coders if we get perm
On Thu, 15 Jul 2010, Michael Van Canneyt wrote:
On Thu, 15 Jul 2010, Graeme Geldenhuys wrote:
Op 2010-07-14 17:17, Daniël Mantione het geskryf:
IMO compiler messages slow down compilation a lot.
How do you know this, did you benchmark or is it just your opinion?
A few weeks ago, I ben
On Thu, 15 Jul 2010, Graeme Geldenhuys wrote:
Op 2010-07-14 17:17, Daniël Mantione het geskryf:
IMO compiler messages slow down compilation a lot.
How do you know this, did you benchmark or is it just your opinion?
A few weeks ago, I benchmarked that too (well similar). I did a comparison
Op 2010-07-15 14:18, Jonas Maebe het geskryf:
> That's only true if it does not impact clarity or maintainability.
> Otherwise there is a tradeoff to be made in favour of one or the other.
True, but I don't think we are talking about optimization like changing
Object Pascal code to ASM. The orig
Graeme Geldenhuys wrote on Thu, 15 Jul 2010:
Well, any optimization is better than none.
That's only true if it does not impact clarity or maintainability.
Otherwise there is a tradeoff to be made in favour of one or the other.
Jonas
--
Op 2010-07-15 06:26, Sergei Gorelkin het geskryf:
>
> Message processing indeed includes some overhead, but this is not #1
> bottleneck to worry about.
> Maybe #10 or so.
Well, any optimization is better than none. Irrespective of where you rank
it, one has to start somewhere.
Regards,
- G
Op 2010-07-14 17:17, Daniël Mantione het geskryf:
>> IMO compiler messages slow down compilation a lot.
>
> How do you know this, did you benchmark or is it just your opinion?
A few weeks ago, I benchmarked that too (well similar). I did a comparison
between Kylix 3 and FPC 2.4.x. When I disabled
In our previous episode, Michael Schnell said:
>
> With small blocks there is no concurrency (as in case of conflict, the
> second thread will use medium.
I'm no memory manager expert, but reading this raises some question:
How is this conflict detected? If this is a kind of lock, (that needs
Michael Schnell schrieb:
> On 07/15/2010 12:05 PM, Jonas Maebe wrote:
>> And you will get overhead in the FASTMM scheme if you have two threads
>> that are concurrently allocating and/or freeing a lot of small or
>> medium blocks.
> Only in extremely rare cases (which of course will be handled but
On 07/15/2010 12:05 PM, Jonas Maebe wrote:
And you will get overhead in the FASTMM scheme if you have two threads
that are concurrently allocating and/or freeing a lot of small or
medium blocks.
Only in extremely rare cases (which of course will be handled but seem
not to be relevant regarding
But why should they sue an open source MS-DOS clone
[snip]
Please take that discussion to the fpc-other list.
Jonas
FPC mailing lists admin
This message was sent using IMP, the Internet Messaging Program.
__
Hi!
Am 15.07.2010 09:49, schrieb Michael Schnell:
On 07/14/2010 09:40 PM, Sven Barth wrote:
(Can someone comment on FreeDOS regarding this?)
If it's file system provides ;MS-DOS-style long filenames, users of same
might be sued by M$ (like TomTom).
But why should they sue an open source MS-D
Michael Schnell wrote on Thu, 15 Jul 2010:
On 07/15/2010 11:43 AM, Florian Klaempfl wrote:
No, because the worker thread looks into the global structure when it
runs out of "local" space.
This kind of garbage control might add some overhead at unforeseen times.
And you will get overhead in
Michael Schnell schrieb:
> On 07/15/2010 11:43 AM, Florian Klaempfl wrote:
>> No, because the worker thread looks into the global structure when it
>> runs out of "local" space.
> This kind of garbage control might add some overhead at unforeseen times.
You don't turn off caches in SMP systems ei
Sorry: BLX.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
... And of course when using a memory cell to store a procedure
address, BX is used to call the procedure.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 07/15/2010 11:43 AM, Florian Klaempfl wrote:
No, because the worker thread looks into the global structure when it
runs out of "local" space.
This kind of garbage control might add some overhead at unforeseen times.
I seem to like the FASTMM paradigm better.
-Michael
__
On 07/15/2010 11:33 AM, Jeppe Johansen wrote:
I think it is on Thumb2 devices. To my understanding, they did so on
purpose so you no longer have to use interwork intermidiate functions
to switch between arm and thumb mode
That seems to be not BL but BX:
http://infocenter.arm.com/help/topic/
Mattias Gärtner schrieb:
> Zitat von Jonas Maebe :
>
>> Michael Schnell wrote on Thu, 15 Jul 2010:
>>
>>> Did somebody take a look at FastMM for Delphi ? (
>>> http://sourceforge.net/projects/fastmm/ )
>>>
>>> Same seems to use a nice paradigm doing the Memory management for
>>> threaded applicati
Zitat von Jonas Maebe :
Michael Schnell wrote on Thu, 15 Jul 2010:
Did somebody take a look at FastMM for Delphi ? (
http://sourceforge.net/projects/fastmm/ )
Same seems to use a nice paradigm doing the Memory management for
threaded applications.
Then please explain that paradigm, sinc
I think it is on Thumb2 devices. To my understanding, they did so on
purpose so you no longer have to use interwork intermidiate functions to
switch between arm and thumb mode
Michael Schnell skrev:
On 07/15/2010 11:12 AM, Geoffrey Barton wrote:
A normal procedural call seems to assemble as
On 07/15/2010 11:12 AM, Geoffrey Barton wrote:
A normal procedural call seems to assemble as a 'BL' to an even address?
I doubt that it's possible to call thumb code from "ARM" code with a "BL".
-Michael
___
fpc-devel maillist - fpc-devel@lists.fre
On 07/15/2010 11:14 AM, Jonas Maebe wrote:
Then please explain that paradigm, since apparently you already looked
at it.
AFAIU, they use three areas for small midrange and large chunks
Small chunks are allocated in several lists, each of which hosts equally
sized chunks, thus finding the chun
Geoffrey Barton wrote on Thu, 15 Jul 2010:
On 14 Jul 2010, at 17:35, Jonas Maebe wrote:
To identify the code as Thumb code.
I was aware of the requirement to add one to the address of an ISR,
but not to other calls.
The address of the symbol is set to an odd value so that the linker
c
Michael Schnell wrote on Thu, 15 Jul 2010:
Did somebody take a look at FastMM for Delphi ? (
http://sourceforge.net/projects/fastmm/ )
Same seems to use a nice paradigm doing the Memory management for
threaded applications.
Then please explain that paradigm, since apparently you already l
On 14 Jul 2010, at 17:35, Jonas Maebe wrote:
Geoffrey Barton wrote on Wed, 14 Jul 2010:
the resulting constant disassembles as:-
1bc:01a5.word 0x01a5
which seems to be one greater than the address of the procedure.
Is this right?
Yes.
If so, why?
To identify the
On 07/14/2010 05:21 PM, Jonas Maebe wrote:
a) the memory management overhead primarily comes from allocating and
freeing machine instruction (and to a lesser extent node tree) instances
Did somebody take a look at FastMM for Delphi ? (
http://sourceforge.net/projects/fastmm/ )
Same seems to
Hans-Peter Diettrich wrote on Thu, 15 Jul 2010:
Jonas Maebe schrieb:
[snip]
When the file resides in the OS file cache, no page faults will
occur unless the file was removed from the cache. If not, every
access request has to do disk I/O, resulting in process switching
etc., so that the p
Marco van de Voort wrote on Thu, 15 Jul 2010:
But that then zeroes every deallocation.
You would only do this for class instances that are kept in a pool
managed by overriding newinstance/freeinstance.
Jonas
This message wa
Florian Klaempfl wrote on Thu, 15 Jul 2010:
I wonder if zeroing memory blocks (so when allocating them we know
already that they contain zeros) and preparing new register allocators
in a helper thread could improve this.
Possibly, yes. At least most OSes also zero pages in a background
threa
On 07/14/2010 11:35 PM, Stefan Kisdaroczi wrote:
Or make a symlink:
Happily even Windows NTFS does support symlinks, even though hardly
anybody uses this. ;)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.
On 07/14/2010 09:40 PM, Sven Barth wrote:
(Can someone comment on FreeDOS regarding this?)
If it's file system provides ;MS-DOS-style long filenames, users of
same might be sued by M$ (like TomTom).
-Michael
___
fpc-devel maillist - fpc-devel@li
In our previous episode, Florian Klaempfl said:
> >> zero it again, so where is the gain in that ?
> >
> > While it's in the freelist, the helper task
>
> ... thread ...
>
> > zeros it so when it is
> > allocated again, it needs no zeroing again.
But that then zeroes every deallocation.
_
Florian Klaempfl schrieb:
> Michael Van Canneyt schrieb:
>>
>> On Thu, 15 Jul 2010, Florian Klaempfl wrote:
>>
>>> Jonas Maebe schrieb:
Unless you are doing a cold compile, the main bottlenecks in the
compiler are the memory manager (mostly the allocation of memory,
freeing is faster
Michael Van Canneyt schrieb:
>
>
> On Thu, 15 Jul 2010, Florian Klaempfl wrote:
>
>> Jonas Maebe schrieb:
>>> Unless you are doing a cold compile, the main bottlenecks in the
>>> compiler are the memory manager (mostly the allocation of memory,
>>> freeing is faster), zero-filling new class inst
On Thu, 15 Jul 2010, Florian Klaempfl wrote:
Jonas Maebe schrieb:
Unless you are doing a cold compile, the main bottlenecks in the
compiler are the memory manager (mostly the allocation of memory,
freeing is faster), zero-filling new class instances (and partially
resetting the register alloc
Hans-Peter Diettrich schrieb:
> Marco van de Voort schrieb:
>
>> I don't think we ever going to give an up front carte blanche for a
>> massive
>> rewrite to go into trunk. That is simply not sane.
>
> ACK. I'm more concerned about work that is blacklisted for some reason.
Rewriting the compiler
Hans-Peter Diettrich schrieb:
> I see the biggest benefit in many possible optimization in the scanner
> and parser, which can be implemented *only if* an entire file resides in
> memory.
Include files, macro expansion and generics make such optimizations hard.
___
Jonas Maebe schrieb:
> Unless you are doing a cold compile, the main bottlenecks in the
> compiler are the memory manager (mostly the allocation of memory,
> freeing is faster), zero-filling new class instances (and partially
> resetting the register allocator) and tobject.initinstance.
I wonder i
66 matches
Mail list logo
