pascal speed

[tr_escape]

I would like to my ideas about this topic:


actaully speed issues like as pee racing ; my compiler beats your compiler.

but we have look all features of the compiler / with ide.

all the time on internet you can find xxx language vs yyyyy language but developers don't care about maintance time. for example if your codes can be understanable and can recompile over 10 years thats the real power of the compiler/ide.

[BeniBela]

. for example if your codes can be understanable and can recompile over 10 years thats the real power of the compiler/ide.

Until they cannot be recompiled anymore

Code: [Select]

  type x = class
    procedure dosomething;
    field: integer;
  end;


[OldPascal]

Hello,
Thanks for reply.
To Jurrasic Pork,
Regarding the LCL   it does not work on my system:
SpeedTest3.pas(3,16) Fatal: Can't find unit LclIntf used by SpeedTest
Since you mentioned that it does not make any significant different results then I decided to keep my original code which is more generic...applicable for other systems.
To tr_escape,
Your argument is absolutely valid however, if someone is doing extensive numerical calculations, the timing accumulates and it shows in  final outcome which is in duration of the program to complete a numerical task.....Like you said....it is not about comparing this and that compiler....Like I said, it is about opportunity to make it better because it is not impossible....someone already did it.
To engkin,
Thanks for links.....I looked at them....I must confess that it is beyond my capabilities...I've got too rusty...need more brushing, oiling and repainting myself first.....however, I see code for exp function is written is assembler language....I will look into that and see if there is a room for some improvements to be made.  If I find something useful, I will post it here.  Regarding sin, cos, and sqrt, I have no clue....

[Jurassic Pork]

hello,
to OldPascal :
Have you something like this :

[Nitorami]

OldPascal

I am an old rusty Pascal user myself, and I had some discussions on speed on this forum. What I learned is to be very careful with microbenchmarks: In my mandelbrot benchmark program, I noted that execution time halved when I just inserted an unused string in the main body. I thought of a bug of course but learned that modern superscalar processor architectures are an entirely different thing than back 1990, when you could tell the execution time by counting the number of CPU cycles. Modern CPUs use a lot of internal optimisation mechanisms which make speed quite unpredictable and depend on many other things than just the plain executable code. It's a bit of black magic. Consult Agner Fog's excellent articles for an insight, and you'll probably give up on it.

If you NEED high speed for mathematical calculations, then use the openblas libararies. They are operating on vectors or matrices rather than scalars, and are accordingly faster. Written in assembler, they can exploit the various optimisation measures of most available CPUs, and they are free. While the calling syntax is standard C, it is easy to convert to Pascal. Without any experience, I managed to get a matrix multiplication running within an evening (and the friendly support of forum members). It is five times faster than the best Pascal code I could make.

[OldPascal]

To Jurassic Pork,
I did coding using Geany editor.   The reason I did that is because I can use the same editor to compile c, fortran, and many other codes.  Just giving myself a way of equal footing comparison of compiling.  You did it with Lazarus.....which I am sure your code works...I did not bother to verify because when I try copy and paste on the lazarus editor....the paste did not do anything  so I guess the paste is not working in suse.  It a minor inconvenience...because code is long I dont bother  right now.  I will look into algorithm of exp instead.
To Nitorami,
Thanks for comments. They are useful.

Thanks to everyone on this forum for feedback...

[Handoko]

If you NEED high speed for mathematical calculations, then use the openblas libararies. They are operating on vectors or matrices rather than scalars, and are accordingly faster. Written in assembler, they can exploit the various optimisation measures of most available CPUs, and they are free. While the calling syntax is standard C, it is easy to convert to Pascal. Without any experience, I managed to get a matrix multiplication running within an evening (and the friendly support of forum members). It is five times faster than the best Pascal code I could make.

You may also try Fastcode Project, here is their website:
http://fastcode.sourceforge.net/

[BobS]

You never bothered to say what if any optimizations you use, be that as it may here are a couple of references you may find useful if you are interested in the topic:
Good source of latency information for opcodes:
http://ref.x86asm.net/#HTML-Editions

For information on branch prediction and such I find this Intel document useful:
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html

[MathMan]

You never bothered to say what if any optimizations you use, be that as it may here are a couple of references you may find useful if you are interested in the topic:
Good source of latency information for opcodes:
http://ref.x86asm.net/#HTML-Editions

As long as you only take the info as an indication I'd say. It's not that the info there - or on many similar sources - is incorrect but on a modern core (anything after let's say Nehalem architecture) the instruction latency is heavily depending on the actual state of the core. Meaning what instructions are in flight, what is their dependency on the individual pipelines (integer, fp, etc.) and so on ...

Best one can do is implement and measure. Unfortunately there are all so many ways one can arrange instructions for a certain computation and to find the best schedule is hard. That's why tools like the "GNU Superoptimizer" (if I remember the name correct) have been invented. And what these do to code readability one can easily see when looking e.g. at the asm sources of GMP.

[BobS]

@Mathman, I think it's still useful to know latency for various things especially when you have choices in your algorithms (e.g. is it worth using an fmul instead of an fdivr? well yes latency 4 vs 11-25) or when faced with choosing which instructions to use for comparison--if your code is good to start with you can reduce the time needed to optimize (or so I hope ).  However the Intel reference goes into a lot more of the other things you need to keep in mind.  It actually took me a bit of time to find a good listing of the latencies for all modern ia-64 ops as a lot of sites seem to omit it for the reasons you mention (or maybe my search engine wasn't nice to me that day ).

I haven't done any serious assembly programming for 20+ years (and first learned with IBM 370 assembly which was luxurious compared to 8080), which is why I went looking for those references a few weeks ago.  For example it used to be you could do some things to help branch prediction even in your Pascal code back in the olden days now it's gotten more advanced: multi-branch prediction, longer pipelines etc. and modern compliers are more optimized it seems (if you use all the options correctly), though so far I've only skimmed the subject (looking for easy things to do, ahem). 

The other thing is parts of code I might once have worried about optimizing run so fast on even say a several year old  microprocessor in a cheap laptop that it's not worth the time to try and optimize them (I'm not talking phones or embedded stuff running on say an Atmel processor etc.-- though even there things I would have worried about on a Z80 running at 1.7MHz just aren't a problem now ). 

If the OP is interested the references I mentioned seem a good place to start catching up or so I'm finding (and more fun than playing CivV ).

[photor]

very good

You never bothered to say what if any optimizations you use, be that as it may here are a couple of references you may find useful if you are interested in the topic:
Good source of latency information for opcodes:
http://ref.x86asm.net/#HTML-Editions

As long as you only take the info as an indication I'd say. It's not that the info there - or on many similar sources - is incorrect but on a modern core (anything after let's say Nehalem architecture) the instruction latency is heavily depending on the actual state of the core. Meaning what instructions are in flight, what is their dependency on the individual pipelines (integer, fp, etc.) and so on ...

Best one can do is implement and measure. Unfortunately there are all so many ways one can arrange instructions for a certain computation and to find the best schedule is hard. That's why tools like the "GNU Superoptimizer" (if I remember the name correct) have been invented. And what these do to code readability one can easily see when looking e.g. at the asm sources of GMP.

[lagprogramming]

   Msdos is a valid target. Two months ago work has started for Win16 target. Any kind of optimization is welcome to be added to fpc as long as it can individually be turned on/off. The fact that new CPUs won't benefit much of those optimizations should not be a concern, it's not a waste of resources, it's continuous improvement. 

[MathMan]

@Mathman, I think it's still useful to know latency for various things especially when you have choices in your algorithms (e.g. is it worth using an fmul instead of an fdivr? well yes latency 4 vs 11-25) or when faced with choosing which instructions to use for comparison--if your code is good to start with you can reduce the time needed to optimize (or so I hope ).  However the Intel reference goes into a lot more of the other things you need to keep in mind.  It actually took me a bit of time to find a good listing of the latencies for all modern ia-64 ops as a lot of sites seem to omit it for the reasons you mention (or maybe my search engine wasn't nice to me that day ).

...

If the OP is interested the references I mentioned seem a good place to start catching up or so I'm finding (and more fun than playing CivV ).

No worries - we're in complete agreement here