On 11.02.2013 20:49, Graeme Geldenhuys wrote:
guessing here) that the FreeBSD release was created with different
optimizer settings than the Linux one (regarding the RTL and packages).
Both FPC 2.6.0 installs were from the binary releases made by the FPC
team. I never install FPC from FreeBSD p
On 11.02.2013 20:56, DaWorm wrote:
Could it be OS calls are slower on FreeBSD? I don't suppose there's an
easy way to profile application versus OS call execution time, is there?
There is:
=== command begin ===
$> time fpc -h > /dev/null
fpc -h > /dev/null 0,01s user 0,01s system 46% cpu 0,
Could it be OS calls are slower on FreeBSD? I don't suppose there's an
easy way to profile application versus OS call execution time, is there?
Jeff.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/
On 2013-02-11 18:24, Sven Barth wrote:
>
> AFAIK the optimizations are CPU specific, not OS specific.
That is what I expected too.
> guessing here) that the FreeBSD release was created with different
> optimizer settings than the Linux one (regarding the RTL and packages).
Both FPC 2.6.0 inst
On 2013-02-11 19:11, Sven Barth wrote:
>
> I would say the "No of tests" is the number of different test functions
> that have been invoked (all within one single test program).
Correct. The first four sets are the same persistence tests, but against
different persistence backends (CSV, TAB, var
On 2013-02-11 19:03, Mark Morgan Lloyd wrote:
>>
>> No of tests | Type of Tests | Linux | FreeBSD
>> -+-++
>> 151| CSV persistence |0:22|0:27
>> -+-++
>>
On 11.02.2013 20:03, Mark Morgan Lloyd wrote:
Graeme Geldenhuys wrote:
Both OS's run FPC 2.6.0 and the exact same revision of tiOPF, FPTest and
fpGUI. fpGUI is used for the GUI test runner of FPTest.
Here is the summary of the unit test results, and the times it took in
minutes and seconds.
N
Graeme Geldenhuys wrote:
Both OS's run FPC 2.6.0 and the exact same revision of tiOPF, FPTest and
fpGUI. fpGUI is used for the GUI test runner of FPTest.
Here is the summary of the unit test results, and the times it took in
minutes and seconds.
No of tests | Type of Tests | Linux |
On 11.02.2013 19:12, Graeme Geldenhuys wrote:
So this got me wondering. Does FPC compiler optimizations differ between
FreeBSD and Linux, even for the same CPU type? If so, then the results
is probably understandable, because there are more Linux developers and
testers in the Free Pascal project,
Hi,
I'm not sure how it works, but does FPC compiler optimizations for the
amd64 (x86_64) CPU's get shared across various OSes?
eg: I've read various reviews that FreeBSD benchmarks often perform
better than the same benchmarks run on Linux. It was even shown that
FreeBSD runs Linux executable fa
On Mon, February 11, 2013 10:04, Sven Barth wrote:
> On 11.02.2013 09:55, Jonas Maebe wrote:
>> On 11 Feb 2013, at 09:45, Sven Barth wrote:
>>> On 10.02.2013 23:04, Marco van de Voort wrote:
I never spent more than an evening on the test though, since I rather
get
rid of all the ming
Am 11.02.2013 11:47, schrieb Marco van de Voort:
In our previous episode, Jonas Maebe said:
Then we would still have the problem of the outdated tools. Maybe we could
write Pascal based substitutes for them that only need to handle the cases of
compiler/rtl compilation...
The only problem I'm
In our previous episode, Jonas Maebe said:
> > Then we would still have the problem of the outdated tools. Maybe we could
> > write Pascal based substitutes for them that only need to handle the cases
> > of compiler/rtl compilation...
>
> The only problem I'm aware of is cp copying the read-onl
In our previous episode, Jonas Maebe said:
> >> I never spent more than an evening on the test though, since I rather get
> >> rid of all the mingw parts instead (think fpmake here)
> >
> > This might be the best. Let's see that fpmake can handle all that and then
> > get rid of the remaining too
On 11 Feb 2013, at 10:04, Sven Barth wrote:
> On 11.02.2013 09:55, Jonas Maebe wrote:
>>
>>
>> As I've said before: I think the compiler and RTL should remain
>> Makefile-based (whether or not that is in addition to fpmake support for
>> them, doesn't matter to me), to make porting to new platf
On 11.02.2013 09:55, Jonas Maebe wrote:
On 11 Feb 2013, at 09:45, Sven Barth wrote:
On 10.02.2013 23:04, Marco van de Voort wrote:
I never spent more than an evening on the test though, since I rather get
rid of all the mingw parts instead (think fpmake here)
This might be the best. Let's s
On 10 Feb 2013, at 22:32, Vittorio Giovara wrote:
> On Sun, Feb 10, 2013 at 8:39 PM, Jonas Maebe wrote:
>
>> I don't remember ever hearing about this or seeing a bug report about
>> this. It's unlikely that this is related to FPC vs LLVM code or debug info
>> generation though. And adding suppor
On 11 Feb 2013, at 09:45, Sven Barth wrote:
> On 10.02.2013 23:04, Marco van de Voort wrote:
>> I never spent more than an evening on the test though, since I rather get
>> rid of all the mingw parts instead (think fpmake here)
>
> This might be the best. Let's see that fpmake can handle all tha
On 10.02.2013 23:04, Marco van de Voort wrote:
I never spent more than an evening on the test though, since I rather get
rid of all the mingw parts instead (think fpmake here)
This might be the best. Let's see that fpmake can handle all that and
then get rid of the remaining tool dependencies.
19 matches
Mail list logo