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
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 now, or
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 believe
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 on
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
2011/12/8 Graeme Geldenhuys graemeg.li...@gmail.com:
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
On 08/12/11 09:13, Vincent Snijders wrote:
2011/12/8 Graeme Geldenhuysgraemeg.li...@gmail.com:
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
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 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 programming
On Thu, Dec 8, 2011 at 10:45 AM, Graeme Geldenhuys
graemeg.li...@gmail.com 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
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
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
From: Graeme Geldenhuys graemeg.li...@gmail.com
Subject: Re: [fpc-pascal] Re: Why is Random(255) some 529x slower
comparedDelphi 7?
To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
Message-ID:
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
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 that
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 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 was told
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 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 interested in
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
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
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 -
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
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 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 will
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 to
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 Random
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't
On 8 December 2011 18:38, Graeme Geldenhuys graemeg.li...@gmail.com 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
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
2011/5/1 Johann Glaser johann.gla...@gmx.at:
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
My Delphi's random is only 7 times faster then fpc's random (Celeron 700).
Bart
On 12/8/11, Marco van de Voort mar...@stack.nl 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
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
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
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
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 doing even
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 under
37 matches
Mail list logo
