I would agree, if this is about "bloatware", but this is a completely different case. We talk about a more accurate method, which is too expensive for your application at the moment. However, progress will make it affordable for more and more problems and eventually for your application, too. Now let me also pour some oil into the fire: How disgraceful is a replacement by a less accurate solution and how about the grace to implement your own solution ;-)

Michael

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 decide to change their Random call to something slower in the next rev, you only have to change one routine to switch back to a faster version. Maybe later a patch could be worked on to implement FastRandom and BetterRandom in the RTL, and use some sort of procedure variable to allow Random to call one or the other. But you'd probably find the need to do that isn't so urgent once you've made the other change.

Jeff.

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 would fly!

How disgraceful is a replacement by a less accurate solution

I never had the intention to remove FPC's Random MT implementation completely. Simply make it the non-default option, and move it into a more specialized unit (maths.pp) where other more specialized math and statistical functions are defined.

and how about the grace to implement your own solution

In the mean time, I have implemented my own faster performing random generator, and used that instead. Even though my problem is now solved, I would still like to make the change to FPC too. I'll prepare a patch and see what the FPC developers say.

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 of people coming from Delphi/Turbo Pascal who not even question the speed (and accuracy) of the random() function. Of course, there is a need for both versions of random() but since decades I (and others) know it to be fast but unreliable. In FPC it suddenly turned into an accurate (which I didn't know so I would not even have used this reliablility) but slow version (which breaks my code).

In other situations the Delphi compatibilty is pulled up even if the implementation is outrageous. But suddenly everybody wants to depart from Delphi. Strange.

Jürgen Hestermann wrote

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 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.

Since when does the definition of "compatibility" include the same speed? Could something become incompatible by being too fast too? I don't think that FPC has ever claimed performing functionality at the same speed as Delphi...

Tomas

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.

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 said, such a magnitude slower makes in unusable!

I'll be the first to admit, I think most of this "delphi compatibility" is crap. But there is a BIG difference between being compatible, and being totally unusable. Clearly many here have listed that they use Random in a recursion function, and in such a case the HUGE speed penalty makes the current Random() implementation unsuitable and unusable.

Will an implementation like Waldo Kitty suggested be a suitable compromise? If so, I'll go ahead and create a patch.

Why a patch at all? Sorry, but to me, this is all but a storm in a teacup...

If Jürgen's "test" application is intended to
measure "transfer" speed, the test is
fundamentally flawed when it would depend on the speed of data generation.

So why doesn't he implement his own random
function for his specific needs? That satisfies
his special usage and leaves everyone else, who
doesn't seem to mind/care with the default
function that provides greater "randomness".
For all of my applications, I definitely prefer
the later and can't think of a single instance
where the implementation of the random function
in FPC makes any significant difference in
performance. For me, I prefer" rather safe than sorry (fast)"...

Ralf

That's false, since people already said that they use it and are happy with it. Honestly, nothing new is being said here and you ignore other people's viewpoints. The majority that have spoken up are against your change. Even Delphi's implementation says that it can change, so relying on its performance is stupid. So the only solution for you is to implement your own (as you've already done) and use it both in Delphi and fpc.

Henry

Hi,

it's unusable by you.

I can live currently with the current implementation or with any implementation you or someone else do.

IMHO, "Much adoe about nothing" ....

regards,

Can you please post your test program? On my core 2 duo it is only 10 times slower.

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 ]----------------------- [random_test]$ fpc speedtest.pas
Free Pascal Compiler version 2.5.1 [2011/09/20] for x86_64 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Linux for x86-64
Compiling speedtest.pas
Linking speedtest
/usr/bin/ld: warning: link.res contains output sections; did you forget -T? 71 lines compiled, 0.6 sec

[random_test]$ ./speedtest
Length(psData) = 200401
ByteValue: 171
Length(Source) = 200401
First Loop....
elapsed time: 11250
----------------------------------------------------------------

And here is the output under Windows with Delphi 7 Enterprise

--------------------[ Delphi 7 ]------------------------------- Y:\tests\random_test>dcc32 speedtest.pas
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation speedtest.pas(72)
73 lines, 0.11 seconds, 72504 bytes code, 3593 bytes data.

Y:\tests\random_test>speedtest.exe
Length(psData) = 200401
ByteValue: 209
Length(Source) = 200401
First Loop....
elapsed time: 11

-----------------------------------------------------------------

So 11250 (FPC) divided by 11 (Delphi) = 1022 times slower... even worse than before!

FPC 2.5.1 is from the 'fixes_2_6' system has a Intel Core 2 Quad Q9400 CPU @ 2.66GHz with 4GB memory running Ubuntu 10.04.3 (64-bit). Windows is running under VirtualBox 4, and is Win2000 with SP4 installed and hardware virtualization enabled.

2011/12/9 Graeme Geldenhuys :

Can you compile the fpc version for 32 bits (may make some difference) and run it on windows (probably make no difference) to reduce the differences in platform when you compare with Delphi?

Vincent

Vincent Snijders wrote

Can you compile the fpc version for 32 bits (may make some difference) and run it on windows (probably make no difference) to reduce the differences in platform when you compare with Delphi?

-----------------------FPC 2.4.5 (r17953 from fixes_2_4 branch) ----------- Y:\tests\random_test>C:\FPC\2.4.5\bin\ppc386.exe speedtest.pas Free Pascal Compiler version 2.4.5 [2011/08/15] for i386 Copyright (c) 1993-2010 by Florian Klaempfl

Y:\tests\random_test>speedtest
Length(psData) = 200401
ByteValue: 180
Length(Source) = 200401
First Loop....
elapsed time: 7421
---------------------------------------------------------------------

So that's 7421 (FPC 32bit) divided by 11 (Delphi 7) = 674 times slower

I'm compiling FPC 2.5.1 for 32bit windows now, to see if there is any difference between FPC versions, but I doubt there would be a big difference.

What is weird is that the 32bit FPC is so much faster than the 64bit FPC. Strange...