On 9 December 2011 09:47, Florian Klaempfl wrote:
>
> According to measurements of me and other peoples, random is only 7-10
> times slower (depending on the CPU).
What do you feed your computer, because mine differs vastly from yours.
Not to mention that our clients still run P4 workstations und
2011/12/9 Graeme Geldenhuys :
> On 8 December 2011 21:39, Florian Klämpfl wrote:
>> Can you please post your test program? On my core 2 duo it is only 10
>> times slower.
>
> Attached in the first post. Here is my console output for compiling
> and running that test program.
Can you compile the f
Am 09.12.2011 07:27, schrieb Jürgen Hestermann:
>
>
> Reimar Grabowski schrieb:
>> The parameter should default to FALSE to not break existing code
>> relying on FPCs random function
> And what about existing code coming from Delphi/Turbo Pascal? This was a
> strong argument in the past for doin
On 8 December 2011 21:39, Florian Klämpfl wrote:
> Can you please post your test program? On my core 2 duo it is only 10
> times slower.
Attached in the first post. Here is my console output for compiling
and running that test program.
-[ FPC under linux ]---
Reimar Grabowski schrieb:
The parameter should default to FALSE to not break existing code relying on FPCs random function
And what about existing code coming from Delphi/Turbo Pascal? This was a
strong argument in the past for doing even crap coding.
As the fast random function then has t
Why don't refactoring the slow RTL random to MyRandom so you can switch? You
can do it in a few miniutes.
In my opinion the current RTL random function should not change, because
other FPC developers are depend on current code base.
But a fast random or other random implementation should put into
On Thursday 08 December 2011 13:49:16 Koenraad Lelong wrote:
> /usr/lib/fpc/2.6.0/units/arm-embedded/rtl/system.o does not support
> interworking, whereas test-1.elf does
does this thread help ?
http://lists.freepascal.org/lists/fpc-devel/2011-August/025615.html
___
My Delphi's random is only 7 times faster then fpc's random (Celeron 700).
Bart
On 12/8/11, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
>> >> the default option exactly like you suggested,
>> >
>> > Did I suggest this?
>>
>> Sorry, I wasn't clear - you suggested that p
2011/5/1 Johann Glaser :
> If you find any improvements or comments don't hesitate to send me an
> EMail.
I just used it. I only needed readline() and add_history(), these two
functions are already enough to make a ReadLn() substitute that really
works and It works like a charm! Thank you!
I thi
In our previous episode, Tomas Hajny said:
> >> the default option exactly like you suggested,
> >
> > Did I suggest this?
>
> Sorry, I wasn't clear - you suggested that people interested in keeping
> the current solution raised their voice (which at least Felipe and
> Karl-Michael did).
And me.
Am 08.12.2011 19:38, schrieb Graeme Geldenhuys:
> 2011/12/8 Tomas Hajny :
>> that FPC has ever claimed performing functionality at the same speed as
>> Delphi...
>
> We all know FPC is much slower that Delphi... we live with it. But a
> function being 529x slower, and being the default implementat
Hi,
On 8/12/2011 8:50 μμ, Graeme Geldenhuys wrote:
On 8 December 2011 18:41, Florian Klaempfl wrote:
And? The conclusion is what we concluded years ago: be as delphi
compatible as possible else people start to cry soon or later. The funny
thing is only that this time the people cry who didn't
On 8 December 2011 18:38, Graeme Geldenhuys wrote:
> 2011/12/8 Tomas Hajny :
>> that FPC has ever claimed performing functionality at the same speed as
>> Delphi...
>
> We all know FPC is much slower that Delphi... we live with it. But a
> function being 529x slower, and being the default implemen
On Thu, 08 Dec 2011 12:51:18 -0500
waldo kitty wrote:
> i wouldn't say specifically place it in the maths unit but what's wrong with
> having both available via a "fastrandom" boolean parameter that is passed? if
> the parameter is not passed, it is defaulted to TRUE... if one wants the MT
> r
At 10:50 AM 12/8/2011, Graeme Geldenhuys wrote:
On 8 December 2011 18:41, Florian Klaempfl wrote:
>
> And? The conclusion is what we concluded years ago: be as delphi
> compatible as possible else people start to cry soon or later. The funny
> thing is only that this time the people cry who didn
On 8 December 2011 18:35, Jürgen Hestermann wrote:
> speed increase of computers is overcompensated by burdening more code on
> them (which is also a consequence of an attitude like yours).
+1
>If random() dominates your program it will do so in ten years too.
@Karl-Michael
Apparently the Rand
On 8 December 2011 18:41, Florian Klaempfl wrote:
>
> And? The conclusion is what we concluded years ago: be as delphi
> compatible as possible else people start to cry soon or later. The funny
> thing is only that this time the people cry who didn't draw this
> conclusion yet.
I'll be the first
On 8 December 2011 19:51, waldo kitty wrote:
> "fastrandom" boolean parameter that is passed? if the parameter is not
> passed, it is defaulted to TRUE... if one wants the MT random, then they
> send FALSE in this parameter... seems simple enough... i think ;)
That sounds perfect to me, but now w
2011/12/8 Tomas Hajny :
> that FPC has ever claimed performing functionality at the same speed as
> Delphi...
We all know FPC is much slower that Delphi... we live with it. But a
function being 529x slower, and being the default implementation
Well, now that just makes we cringe. And as Jurgen
On 12/8/2011 02:48, Graeme Geldenhuys wrote:
On 8 December 2011 09:25, Felipe Monteiro de Carvalho wrote:
And what about people using FPC only and depending on our Random being
statistically strong, they are less important then theorical Delphi
migrants?
[like what was told to me numerous tim
Tomas Hajny schrieb:
Since when does the definition of "compatibility" include the same speed?
Well, a factor of multiple hundreds is not just a different speed. It
makes the function unusalbe for the same purpose.
___
fpc-pascal maillist - f
On Thu, December 8, 2011 17:24, Jürgen Hestermann wrote:
> Schindler Karl-Michael schrieb:
>> How disgraceful is a replacement by a less accurate solution and how
>> about the grace to implement your own solution ;-)
>>
>>
> You miss the whole point. It's not a matter of coding effort but of
> back
Am 08.12.2011 17:24, schrieb Jürgen Hestermann:
>
> In other situations the Delphi compatibilty is pulled up even if the
> implementation is outrageous. But suddenly everybody wants to depart
> from Delphi. Strange.
And? The conclusion is what we concluded years ago: be as delphi
compatible as po
Schindler Karl-Michael schrieb:
The only question is on the time, when computers are so fast, that hardly anyone will bother about speed of the method.
That's nonsense. The only thing that happens if computers speed
increases is, that you put more code into the same time slot. Otherwise
wo
Schindler Karl-Michael schrieb:
How disgraceful is a replacement by a less accurate solution and how about the
grace to implement your own solution ;-)
You miss the whole point. It's not a matter of coding effort but of
backwards compatibility with existing code and also with expectations
On Thu, December 8, 2011 16:08, Graeme Geldenhuys wrote:
> 2011/12/8 Tomas Hajny :
>> Anyway: some people expressed their wish to keep the current solution as
>> the default option exactly like you suggested,
>
> Did I suggest this?
.
.
Sorry, I wasn't clear - you suggested that people intereste
2011/12/8 Tomas Hajny :
> Anyway: some people expressed their wish to keep the current solution as
> the default option exactly like you suggested,
Did I suggest this?
> and you still argue with
> them that their view is not valid - strange...
Clearly somewhere our lines have crossed. Strange
On Thu, December 8, 2011 08:48, Graeme Geldenhuys wrote:
> On 8 December 2011 09:25, Felipe Monteiro de Carvalho wrote:
.
.
>> And what about people using FPC only and depending on our Random being
>> statistically strong, they are less important then theorical Delphi
>> migrants?
>
> [like what
Hi,
I had some problems making or using a compiler for arm-embedded so I
tried the new 2.6.0-rc1.
Compiling with :
make clean buildbase installbase CROSSINSTALL=1 CROSSOPT="-CfSoft
-XParm-elf-" OS_TARGET=embedded CPU_TARGET=arm PREFIX=/usr/ SUBARCH=armv7m
went fine.
Compiling a test-app with
On 8 December 2011 12:56, Schindler Karl-Michael wrote:
> about a more accurate method, which is too expensive for your application at
> the
> moment.
Yeah, I'll just tell my clients that they can't run my app yet, we
need to wait a few more years for Intel and AMD to catch up to my
work. Like th
Why sprinkle ifdefs everywhere? Change all calls to Random with calls to
FastRandom, and have one ifdef there that uses Random in Delphi and a fast
substitute in FPC. Still readable, still fast, and you would be done by
now instead of spending so much time arguing about it. Plus, should Delphi
d
> From: Graeme Geldenhuys
> Subject: Re: [fpc-pascal] Re: Why is Random(255) some 529x slower
> comparedDelphi 7?
> To: FPC-Pascal users discussions
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> On 8 December 2011 11:35, Schindler Karl-Michael wrote:
>> now,
Hi,
On 8/12/2011 9:48 πμ, Graeme Geldenhuys wrote:
[like what was told to me numerous times before] They (FPC users)
should speak up now, or forever hold your peace. And those that have
spoken so far, all seem to be fine with a less statistically strong
default Random(), and have the statistic
On 8 December 2011 11:33, Henry Vermaak wrote:
>
> I agree, quality first.
I would normally agree with that. But such huge magnitudes slower
(20ms vs 10585ms) on a new Quad-Core type system? That just seems a
bit excessive, and considering most use cases are not even for
statistical type applicat
On Thu, Dec 8, 2011 at 10:45 AM, Graeme Geldenhuys
wrote:
> Nice, now I need to riddle my code with IFDEF statements (making in
> much harder to read) because lots of the code in question is shared
> between Delphi and FPC. :-/
According to the Delphi documentation you could in the future need
if
On 8 December 2011 11:35, Schindler Karl-Michael wrote:
> now, will cause another change in the future. The only question is on the
> time, when
> computers are so fast, that hardly anyone will bother about speed of the
> method.
I absolutely despise such logic! It's a disgrace to the programmin
Hi
My 2 cents:
Since computers get faster and faster with time, there is a time line for more
accurate techniques, even if they are more costly. So, shifting to a faster,
but less accurate method now, will cause another change in the future. The only
question is on the time, when computers are
On 08/12/11 09:13, Vincent Snijders wrote:
2011/12/8 Graeme Geldenhuys:
On 8 December 2011 09:25, Felipe Monteiro de Carvalho wrote:
And what if it changes in the future to being slow and statistically
strong, we change again too?
The random number generator can be implemented in such a way
2011/12/8 Graeme Geldenhuys :
> On 8 December 2011 09:25, Felipe Monteiro de Carvalho wrote:
>>
>> And what if it changes in the future to being slow and statistically
>> strong, we change again too?
>
> The random number generator can be implemented in such a way that the
> backend generator is us
On 8 December 2011 10:08, Florian Klaempfl wrote:
> dicussed it years ago might not followed up this mailing list anymore
> but just use it so they cannot speak up today either.
That's their loss.
--
Regards,
- Graeme -
___
fpGUI - a cross-platf
On 8 December 2011 10:04, Marco van de Voort wrote:
>
> It's a strange case where people are advocating the introduction of a slower
> "manager" to improve the speed of random :-)
It's called an acceptable compromise, by those that use it most.
Just like FPC doesn't do micro code optimizations o
Am 08.12.2011 09:03, schrieb Graeme Geldenhuys:
> On 8 December 2011 09:50, Florian Klaempfl wrote:
>>
>> Actually those who depend on speed should have spoken up ten years ago
>> when the MT was implemented.
>
> I for one did not even know about the existence of Free Pascal 10 year
> ago. I don't
In our previous episode, Graeme Geldenhuys said:
> > And what about people using FPC only and depending on our Random being
> > statistically strong, they are less important then theorical Delphi
> > migrants?
>
> [like what was told to me numerous times before] They (FPC users)
> should speak up
On 8 December 2011 09:50, Florian Klaempfl wrote:
>
> Actually those who depend on speed should have spoken up ten years ago
> when the MT was implemented.
I for one did not even know about the existence of Free Pascal 10 year
ago. I don't believe I am alone either.
On a side note:
As for Jonas d
44 matches
Mail list logo
