2013/3/8 Graeme Geldenhuys :
> 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 from Michael Schnelll.
Am 08.03.2013 00:43 schrieb "Graeme Geldenhuys" :
>
> 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 out, fix another p
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
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
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 m
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 ?!
Whi
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
t
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 w
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 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 stand
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
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 for
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 undocument
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 fo
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 2
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 secon
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
create
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 indepen
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 processors
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 buildi
"make -j 16 deb-pkg" vs "make -j 2 deb-pkg", sure :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 3.
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
In our previous episode, Henry Vermaak said:
> > That does't work, since in FPC an unit is an interface AND an
> > implementation. And inline functions are in the implementation, not the
> > interface.
> >
> > The only way is to simply toss the modular system (units) out, and work with
> > $i, de
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 un
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 maintena
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 als
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.
> > >
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 ther
On Tue, 5 Mar 2013, Mattias Gaertner wrote:
Michael Van Canneyt 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.20
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
Michael Van Canneyt 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 Morg
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 p
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 uni
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 o
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, choo
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 di
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,
a
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 dependenci
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 dependencies, and learn to
in
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
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. I
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 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 ma
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 27
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, a
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,
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
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
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 GN
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 whe
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 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
performance
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 k
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 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 about
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 ob
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 direc
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 compile
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 obvi
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
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
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 p
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
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 real
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 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 (i
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 p
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 cor
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 ma
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
On Sat, 2 Mar 2013, Craig Peterson wrote:
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt 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
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 compile
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 tha
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 synchronizat
Am 02.03.2013 15:15, schrieb Craig Peterson:
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt
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
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
proba
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt 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.
Delphi is generating e
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 such
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 ha
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 - fpc-deve
> 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.
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
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
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?
>>
>
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 about
Am 02.03.2013 11:15 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
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: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
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
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, curr
On Fri, 1 Mar 2013, Martin Schreiber wrote:
Am 01.03.2013 20:52, schrieb Michael Van Canneyt:
For a correct test, you should not enable debug information in FPC.
Or enable generation of turbo debug information and the corresponding
linker map in Delphi.
Otherwise you are comparing apples wi
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 inst
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
__
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-dev
Am 01.03.2013 20:52, schrieb Michael Van Canneyt:
For a correct test, you should not enable debug information in FPC.
Or enable generation of turbo debug information and the corresponding
linker map in Delphi.
Otherwise you are comparing apples with pears, as -D+ in delphi does not
do nearly th
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 si
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:
> 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, 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
1 - 100 of 102 matches
Mail list logo
