On 06.03.2013 14:36, Sven Barth wrote:
Am 06.03.2013 14:29, schrieb Michael Schnell:
On 03/06/2013 01:43 PM, Sven Barth wrote:
And how does one the current TThread?
Since a few weeks: TThread.CurrentThread ;)
This does in fact use a threadvar:
threadvar
{ the instance of the current
Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3
lines for the actual message. Keep up the good work.
Netiquette?
G.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 08.03.2013 00:43 schrieb Graeme Geldenhuys gra...@geldenhuys.co.uk:
Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3
lines for the actual message. Keep up the good work.
Netiquette?
This should have been shortened indeed...
To my defense: I wanted to get this mail
2013/3/8 Graeme Geldenhuys gra...@geldenhuys.co.uk:
Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3
lines for the actual message. Keep up the good work.
Good quoting, it just read that message and got a comprehensive story,
especially because my autofilter deletes mails
Op Tue, 5 Mar 2013, schreef Henry Vermaak:
Damn. My custom config kernel compiles stable kernels in 3-5 minutes on
a quad core Xeon, which isn't bad. Did you build with the standard
config?
What is the standard config? As the operating system is Scientific Linux
6, I'm using the config
On 03/04/2013 12:47 PM, Michael Schnell wrote:
In all fpc enabled patforms I examined (X86 Windows, X86 Linux, X64-64
Windows, X86-64 Linux, ARM Linux (32 Bits) the platform provides as
well library calls as dedicated threadvar pointer registers. In
windows the registers seem to be
Am 06.03.2013 11:12, schrieb Michael Schnell:
So (as with all x86 variants) no library
or system call is necessary.
Wrong. This is not true in the general case, please read the appropriate
api documents.
With Cortex, this has changed to the use of the CP15 Register (freeing
A9 to allow
On 03/06/2013 11:45 AM, Florian Klaempfl wrote:
So (as with all x86 variants) no library
or system call is necessary.
Wrong. This is not true in the general case, please read the
appropriate api documents.
I do know that on Windows it's documented like this by Microsoft. But I
also know that
On Wed, Mar 06, 2013 at 10:50:10AM +0100, Daniël Mantione wrote:
Op Tue, 5 Mar 2013, schreef Henry Vermaak:
Damn. My custom config kernel compiles stable kernels in 3-5 minutes on
a quad core Xeon, which isn't bad. Did you build with the standard
config?
What is the standard config?
Am 06.03.2013 11:45, schrieb Florian Klaempfl:
Conclusion:
With FPC, the optimization of threadvar access is not necessary. Instead
it is highly recommended to always use thread specific instances of the
classes that do the threaded work. TThread of course provides this out
of the box.
And
On 03/06/2013 01:43 PM, Sven Barth wrote:
And how does one the current TThread?
Since a few weeks: TThread.CurrentThread ;)
This does in fact use a threadvar:
threadvar
{ the instance of the current thread; in case of an external thread
this is
Nil until TThread.GetCurrentThread
Am 06.03.2013 14:29, schrieb Michael Schnell:
On 03/06/2013 01:43 PM, Sven Barth wrote:
And how does one the current TThread?
Since a few weeks: TThread.CurrentThread ;)
This does in fact use a threadvar:
threadvar
{ the instance of the current thread; in case of an external thread
make -j has a dramatic effect on an SMP system, particularly if it can
find groups of jobs without too much interdependence.
=
The benchamark was surprising. Diring it, me observed 80..95% load of
each CPU still having high I/O load on the RAID1. How can it be ?!
time make -j 64
==
It might not build modules - which present a lot of files thsu I/O.
make -j .. deb-pkg builds packs both image modules (the
benchmark has selected for build approx 75% of all available modules )
___
fpc-devel
Marco van de Voort wrote:
But even when in theory (which I btw don't even want to consider), you are
equivalent to C in this way, it basically means disabling the unit system,
and users must start to manual maintain dependencies, and learn to
interpretate cryptic errormessages if an incremental
Sven Barth wrote:
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
Marco van de Voort wrote:
But even when in theory (which I btw don't even want to consider),
you are
equivalent to C in this way, it basically means disabling the unit
system,
and users must start to manual maintain
Am 05.03.2013 10:41, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
Marco van de Voort wrote:
But even when in theory (which I btw don't even want to consider),
you are
equivalent to C in this way, it basically means disabling the unit
system,
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
But on the other hand, if an application programmer could
disable FPC's unit handling and use make -j instead, choosing
to pay the price of difficult
Am 05.03.2013 10:58, schrieb Henry Vermaak:
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
But on the other hand, if an application programmer could
disable FPC's unit handling and use make -j instead,
Henry Vermaak wrote:
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
But on the other hand, if an application programmer could
disable FPC's unit handling and use make -j instead, choosing
to pay the price
On Tue, 5 Mar 2013, Sven Barth wrote:
Am 05.03.2013 10:58, schrieb Henry Vermaak:
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
But on the other hand, if an application programmer could
disable FPC's
On Tue, Mar 05, 2013 at 11:05:22AM +0100, Sven Barth wrote:
Am 05.03.2013 10:58, schrieb Henry Vermaak:
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
But on the other hand, if an application programmer
Michael Van Canneyt mich...@freepascal.org hat am 5. März 2013 um 11:09
geschrieben:
On Tue, 5 Mar 2013, Sven Barth wrote:
Am 05.03.2013 10:58, schrieb Henry Vermaak:
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Am 05.03.2013 10:14, schrieb Mark
On Tue, Mar 05, 2013 at 11:09:39AM +0100, Michael Van Canneyt wrote:
There is a new tool pas2fpm.pp which can easily be adapted to do this.
It already calculates the dependencies, but outputs them in fpmake form.
Ah, I remember that fpmake can build with multiple threads, so perhaps
this is a
On Tue, 5 Mar 2013, Mattias Gaertner wrote:
Michael Van Canneyt mich...@freepascal.org hat am 5. März 2013 um 11:09
geschrieben:
On Tue, 5 Mar 2013, Sven Barth wrote:
Am 05.03.2013 10:58, schrieb Henry Vermaak:
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
Sven
In our previous episode, Henry Vermaak said:
IMHO a threading clusterfsck is preferable to a forking clusterfck :-)
My gut feeling would be that the complexity and potential bugs/races
don't make up for the speed, but maybe a threaded compiler gains a lot
more than I imagine. Are there any
In our previous episode, Henry Vermaak said:
But on the other hand, if an application programmer could
disable FPC's unit handling and use make -j instead, choosing
to pay the price of difficult maintenance, it might defuse the
criticism coming from certain quarters.
Make can not
On 2013-03-05 10:31, Henry Vermaak wrote:
Ah, I remember that fpmake can build with multiple threads, so perhaps
this is a better solution than to do it with make. I'll investigate.
I've got that option enabled by default for building FPC 2.7.1 and it
does shave off a few seconds.
I'm also
On Tue, Mar 05, 2013 at 11:44:37AM +0100, Marco van de Voort wrote:
In our previous episode, Henry Vermaak said:
But on the other hand, if an application programmer could
disable FPC's unit handling and use make -j instead, choosing
to pay the price of difficult maintenance, it might
Henry Vermaak schrieb:
I'm trying to ascertain if this is even possible (the c-style,
file-at-a-time compilation, using make to handle multiple processes).
Do you think it's possible, then?
Yes and no. It would mean to create kind of header files for the Pascal
units, usable to compile the
On 3/5/2013 05:50, Graeme Geldenhuys wrote:
I'm also trying to use fpmake for other hourly build server tasks,
where I need to do clean compiles of various independent packages first,
then build the test suite that pulls everything together. eg: building
Synapse, FBLib, tiOPF, EpikTimer, fpGUI
so that compilation could start while the disk is stressed by loading
all other PPU files, required for the compilation of units with more
dependencies.
==
Disk I/O is a huge low-down to avoid on any price (like databases do
with their indexing). Today me tested building LINUX kernel
Ivanko B wrote:
so that compilation could start while the disk is stressed by loading
all other PPU files, required for the compilation of units with more
dependencies.
==
Disk I/O is a huge low-down to avoid on any price (like databases do
with their indexing). Today me tested
Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd:
I've not had an opportunity to try this, but my understanding is that on a
Sun E10K with something like 256 400MHz processors the Linux kernel built in
around 20 seconds. I've had it build in about 3 minutes on a system with 16x
80MHz
On 2013-03-05 17:09, waldo kitty wrote:
on another system i work with, we use disk-based breadcrumb semaphore files
for
the different stages and parts of those stages...
Thanks for you input. It sounds similar to what I was planning. Simply
create an empty file in /tmp when each
On 05.03.2013 20:58, Graeme Geldenhuys wrote:
On 2013-03-05 17:09, waldo kitty wrote:
on another system i work with, we use disk-based breadcrumb semaphore files for
the different stages and parts of those stages...
Thanks for you input. It sounds similar to what I was planning. Simply
On Tue, Mar 05, 2013 at 07:26:19PM +0100, Daniël Mantione wrote:
Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd:
I've not had an opportunity to try this, but my understanding is
that on a Sun E10K with something like 256 400MHz processors the
Linux kernel built in around 20 seconds. I've
Henry Vermaak wrote:
On Tue, Mar 05, 2013 at 07:26:19PM +0100, Daniël Mantione wrote:
Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd:
I've not had an opportunity to try this, but my understanding is
that on a Sun E10K with something like 256 400MHz processors the
Linux kernel built in around
On 03/02/2013 04:02 PM, Florian Klaempfl wrote:
In theory yes but I still fear that the threadvars and synchronization
eats much of the advantage in this case.
I suppose the (high level) synchronization will be rather complex and
eat performance.
The low level threadvar implementation is
On Mon, 4 Mar 2013, Michael Schnell wrote:
On 03/02/2013 04:02 PM, Florian Klaempfl wrote:
In theory yes but I still fear that the threadvars and synchronization eats
much of the advantage in this case.
I suppose the (high level) synchronization will be rather complex and eat
On 03/04/2013 09:49 AM, Michael Van Canneyt wrote:
The solution must work on ALL platforms...
Of course.
I don't remember ever having seen a system (Windows, Linux, x86, ARM,
NIOS (similar top MIPS) ) where the C compiler does a library call when
accessing a threadvar. Usually a register
On Mon, 4 Mar 2013, Michael Schnell wrote:
On 03/04/2013 09:49 AM, Michael Van Canneyt wrote:
The solution must work on ALL platforms...
Of course.
I don't remember ever having seen a system (Windows, Linux, x86, ARM, NIOS
(similar top MIPS) ) where the C compiler does a library call
On 03/04/2013 10:07 AM, Michael Van Canneyt wrote:
We use pthreads on non-windows, and GetTLS/SetTLS on Windows.
Thus the situation is as it was when we discussed this some years ago: a
library call with each access to a threadvar, making fpc a lot slower
that the C compiler (Microsoft and
On Sat, Mar 02, 2013 at 05:26:02PM +0100, Marco van de Voort wrote:
In our previous episode, Henry Vermaak said:
I don't see why there would be more synchronization overhead than make?
So why not keep it simple and let the build system handle parallel jobs?
I like autobuilding. IMHO
In our previous episode, Henry Vermaak said:
Manually maintaining dependencies between compilation units is stone-age.
I just add all the objects to a variable in a Makefile.
The result is that I have a 27000 line c library that compiles in *half*
the time it takes to compile a 4000 line
On Mon, March 4, 2013 10:33, Michael Schnell wrote:
On 03/04/2013 10:07 AM, Michael Van Canneyt wrote:
We use pthreads on non-windows, and GetTLS/SetTLS on Windows.
Thus the situation is as it was when we discussed this some years ago: a
library call with each access to a threadvar, making
On 03/04/2013 12:29 PM, Tomas Hajny wrote:
It's questionable whether it should be responsibility of a compiler to
provide efficient support for threadvars,
If the target platform does not support threadvars a compiler can't do
it at all.
If the target platform only provides library calls,
On Mon, Mar 04, 2013 at 11:19:38AM +0100, Marco van de Voort wrote:
In our previous episode, Henry Vermaak said:
Manually maintaining dependencies between compilation units is stone-age.
I just add all the objects to a variable in a Makefile.
The result is that I have a 27000 line c
In our previous episode, Henry Vermaak said:
I just add all the objects to a variable in a Makefile.
The result is that I have a 27000 line c library that compiles in *half*
the time it takes to compile a 4000 line lazarus program because my c
lib can be built with make -j 9.
On Mon, Mar 04, 2013 at 09:25:02PM +0100, Marco van de Voort wrote:
In our previous episode, Henry Vermaak said:
I just add all the objects to a variable in a Makefile.
The result is that I have a 27000 line c library that compiles in *half*
the time it takes to compile a 4000
C users and developers are trained in this, and have their experience in
detangling the web of deps etc, have developed semi-automated helper tools
etc.
---
Inflicting this on the Pascal masses is unrealistic and undesirable.
==
100% !
C(++) building system is a nightmare.
Op Sun, 3 Mar 2013, schreef Martin Schreiber:
BTW, a significant percentage of the time is waiting for FPC compiling because
FPC normally crashes without -B.
I think you should focus your efforts on getting those bugs fixed, such as
by submitting bug reports that allow reproduction of the
On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote:
Op Sun, 3 Mar 2013, schreef Martin Schreiber:
BTW, a significant percentage of the time is waiting for FPC compiling
because FPC normally crashes without -B.
I think you should focus your efforts on getting those bugs fixed, such as
Am 03.03.2013 10:46, schrieb Martin Schreiber:
On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote:
Op Sun, 3 Mar 2013, schreef Martin Schreiber:
BTW, a significant percentage of the time is waiting for FPC compiling
because FPC normally crashes without -B.
I think you should focus your
On 03.03.2013 08:23, Martin Schreiber wrote:
On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote:
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems
On Sunday 03 March 2013 10:42:09 Sven Barth wrote:
Do you mean compiling the compiler? If so than for real tests you SHOULD
NOT compile the compiler by hand, but only through make cycle in the
compiler directory or make all in the top level directory. This will
ensure that the compiler is
On 03.03.2013 11:08, Martin Schreiber wrote:
On Sunday 03 March 2013 10:42:09 Sven Barth wrote:
Do you mean compiling the compiler? If so than for real tests you SHOULD
NOT compile the compiler by hand, but only through make cycle in the
compiler directory or make all in the top level
On Sun, 3 Mar 2013, Martin Schreiber wrote:
On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote:
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems
Am 02.03.2013 11:11, schrieb Martin Schreiber:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a surprise.
On Windows FPC linking time of MSEide is
In our previous episode, Michael Van Canneyt said:
I'm sorry, but I do not share your focus on speed. I have many projects,
some of them have more units than mseide does, and yet I never have to wait
more than a couple of seconds. The only exception is the Lazarus IDE.
No, I have also seen
Am 01.03.2013 22:40, schrieb Martin Schreiber:
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Expect the next release to be even slower.
Will it produce better code instead?
What means
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a surprise.
On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it
later,
On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote:
Am 01.03.2013 22:40, schrieb Martin Schreiber:
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Expect the next release to be
Am 02.03.2013 11:16, schrieb Martin Schreiber:
On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote:
Am 01.03.2013 22:40, schrieb Martin Schreiber:
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good
On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote:
I did a quick test on win32, it seems to be a little bit smaller than
2.6.2:
02.03.2013 10:09 5.774.848 mseide.exe
Compiled with which FPC version?
trunk.
??? MSEgui compiles with trunk?
Martin
Am 02.03.2013 11:15 schrieb Martin Schreiber mse00...@gmail.com:
On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote:
I did a quick test on win32, it seems to be a little bit smaller than
2.6.2:
02.03.2013 10:09 5.774.848 mseide.exe
Compiled with which FPC
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a surprise.
On Windows FPC linking time of MSEide is
Am 02.03.2013 11:21, schrieb Martin Schreiber:
On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote:
I did a quick test on win32, it seems to be a little bit smaller than
2.6.2:
02.03.2013 10:09 5.774.848 mseide.exe
Compiled with which FPC version?
trunk.
??? MSEgui
Am 02.03.2013 11:28, schrieb Michael Van Canneyt:
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a
In our previous episode, Florian Kl?mpfl said:
(for example renaming all files to .pp takes off +/- 1 second here)
Nevertheless, I'd be interested in seeing the strace.
Better parallize the building using some build units. Then it will be
probably compiled in less than 10 sec on a
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Afaik Delphi 7 is closed source, so inherently worse than any version of FPC.
Cheers,
Vittorio
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
In our previous episode, Martin Schreiber said:
Compiled with which FPC version?
trunk.
??? MSEgui compiles with trunk?
It is mostly unicodestring centric, so that shouldn't be such a surprise?
___
fpc-devel maillist -
On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Compiled with which FPC version?
trunk.
??? MSEgui compiles with trunk?
It is mostly unicodestring centric, so that shouldn't be such a surprise?
MSEgui has an own
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Compiled with which FPC version?
trunk.
??? MSEgui compiles with trunk?
It is mostly unicodestring centric, so that shouldn't be
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt mich...@freepascal.org wrote:
If you hire 2 painters to paint the whole of your house,
and one doesn't paint the inside, because you don't see it from the
outside, of course he will be finished faster; he didn't perform the same
work.
Am 02.03.2013 13:24, schrieb Marco van de Voort:
In our previous episode, Florian Kl?mpfl said:
(for example renaming all files to .pp takes off +/- 1 second here)
Nevertheless, I'd be interested in seeing the strace.
Better parallize the building using some build units. Then it will be
Am 02.03.2013 15:15, schrieb Craig Peterson:
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
If you hire 2 painters to paint the whole of your house, and one
doesn't paint the inside, because you don't see it from the
outside, of course he will be finished
In our previous episode, Florian Klaempfl said:
Better parallize the building using some build units. Then it will be
probably compiled in less than 10 sec on a modern CPU.
Better paralellize the compiler :-)
In theory yes but I still fear that the threadvars and synchronization
eats
Am 02.03.2013 16:23, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
Better parallize the building using some build units. Then it will be
probably compiled in less than 10 sec on a modern CPU.
Better paralellize the compiler :-)
In theory yes but I still fear
On Sat, Mar 02, 2013 at 04:23:32PM +0100, Marco van de Voort wrote:
In our previous episode, Florian Klaempfl said:
Better parallize the building using some build units. Then it will be
probably compiled in less than 10 sec on a modern CPU.
Better paralellize the compiler :-)
In
On Sat, 2 Mar 2013, Craig Peterson wrote:
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt mich...@freepascal.org wrote:
If you hire 2 painters to paint the whole of your house,
and one doesn't paint the inside, because you don't see it from the outside,
of course he will be finished
In our previous episode, Florian Klaempfl said:
I don't see why there would be more synchronization overhead than make?
In a parallelized compiler symtables etc. might be shared and this might
require a lot of synchronization to prevent data corruption.
With make, the different units can
In our previous episode, Henry Vermaak said:
I don't see why there would be more synchronization overhead than make?
So why not keep it simple and let the build system handle parallel jobs?
I like autobuilding. IMHO that is a core attraction of unit based (modular)
languages.
Manually
Am 02.03.2013 17:24, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
I don't see why there would be more synchronization overhead than make?
In a parallelized compiler symtables etc. might be shared and this might
require a lot of synchronization to prevent data
Am 02.03.2013 16:49, schrieb Michael Van Canneyt:
All this said: You will not hear me claiming that there is no room for
improvement in FPC.
I'm sure there is. However, I do not think we'll be able to match
Delphi's speed without sacrificing the main goal of FPC: to support as
much platforms as
On 2013-03-02 10:28, Michael Van Canneyt wrote:
We can say for sure that the fact you use .pas as filename extension
will cause FPC to do twice the number of stat() calls, because .pp is
searched first...Logical therefore that the IO is slower.
Second time I hear this this week. Can we (in
On Sat, 2 Mar 2013, Graeme Geldenhuys wrote:
On 2013-03-02 10:28, Michael Van Canneyt wrote:
We can say for sure that the fact you use .pas as filename extension
will cause FPC to do twice the number of stat() calls, because .pp is
searched first...Logical therefore that the IO is slower.
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come
On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote:
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the
Hi,
In order to have a good benchmark for FPC I made MSEide+MSEgui Delphi 7
compatible again.
Source (master branch 2400be4999b254dbf335e4777baa33b13ea72649):
http://gitorious.org/mseide-msegui
As testcase I used compiling MSEide, all dcu's, ppu's and o's deleted
before compiling.
System:
On Fri, 1 Mar 2013, Martin Schreiber wrote:
Hi,
In order to have a good benchmark for FPC I made MSEide+MSEgui Delphi 7
compatible again.
Source (master branch 2400be4999b254dbf335e4777baa33b13ea72649):
http://gitorious.org/mseide-msegui
For a correct test, you should not enable debug
On Fri, 1 Mar 2013, Michael Van Canneyt wrote:
On Fri, 1 Mar 2013, Martin Schreiber wrote:
Hi,
In order to have a good benchmark for FPC I made MSEide+MSEgui Delphi 7
compatible again.
Source (master branch 2400be4999b254dbf335e4777baa33b13ea72649):
http://gitorious.org/mseide-msegui
In our previous episode, Michael Van Canneyt said:
What I remember from windows 2000 is that FPC/ld/etc is several factors
slower on the same hardware as when run under Linux.
Afaik the internal linker is default on windows since 2.2.0 ?
There are still some issues with external .a archives,
On Fri, 1 Mar 2013, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
What I remember from windows 2000 is that FPC/ld/etc is several factors
slower on the same hardware as when run under Linux.
Afaik the internal linker is default on windows since 2.2.0 ?
Also
In our previous episode, Michael Van Canneyt said:
In our previous episode, Michael Van Canneyt said:
What I remember from windows 2000 is that FPC/ld/etc is several factors
slower on the same hardware as when run under Linux.
Afaik the internal linker is default on windows since 2.2.0 ?
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Expect the next release to be even slower.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Expect the next release to be even slower.
Will it produce better code instead?
Martin
___
97 matches
Mail list logo
