FPC Graphics options?

classic Classic list List threaded Threaded
194 messages Options
1234 ... 10
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FPC Graphics options?

Zaaphod

I have a few console graphics applications that I originally wrote in Turbo Pascal that I have been able to convert over to Free Pascal and now have windows versions of these programs.  I notice that unless I run my program on a 3.5GHz machine or faster, the graphics are fairly slow.    By slow, I mean noticeably slower than they were on a Pentium 233 DOS machine with Turbo Pascal.  The intended computers for these programs are simple inexpensive PCs with motherboard video, no dedicated video cards, I think it should be possible for any modern computer to severely out perform a Pentium 233 with a VGA card in it, so I’m not sure what the issue is.   I am just using the graph unit for windows, and I wonder if there is a more efficient method of creating a full screen graphics only application than to use the graph unit?    I am only looking for it to work under windows and the main issue I would like to solve is the speed of drawing things on the screen like lines and arcs.  It would be nice if I am also able to get away from BGI fonts and use True Type fonts instead.  I don’t need 3D rendering or anything so complicated, just to draw lines and arcs and maybe ellipses as well as various text, and flood fill closed shapes with some solid color.

 

Any Suggestions?


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Free Pascal - General mailing list
On 11.05.2017 20:43, James Richters wrote:

> I have a few console graphics applications that I originally wrote in
> Turbo Pascal that I have been able to convert over to Free Pascal and
> now have windows versions of these programs.  I notice that unless I run
> my program on a 3.5GHz machine or faster, the graphics are fairly
> slow.    By slow, I mean noticeably slower than they were on a Pentium
> 233 DOS machine with Turbo Pascal.  The intended computers for these
> programs are simple inexpensive PCs with motherboard video, no dedicated
> video cards, I think it should be possible for any modern computer to
> severely out perform a Pentium 233 with a VGA card in it, so I’m not
> sure what the issue is.   I am just using the graph unit for windows,
> and I wonder if there is a more efficient method of creating a full
> screen graphics only application than to use the graph unit?    I am
> only looking for it to work under windows and the main issue I would
> like to solve is the speed of drawing things on the screen like lines
> and arcs.  It would be nice if I am also able to get away from BGI fonts
> and use True Type fonts instead.  I don’t need 3D rendering or anything
> so complicated, just to draw lines and arcs and maybe ellipses as well
> as various text, and flood fill closed shapes with some solid color.
>
>  
>
> Any Suggestions?

You could try the units ptcgraph or sdlgraph as alternatives (both are
part of FPC). Other than that you could try to investigate why the
graphic unit is so slow on Windows...

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Bart-48
In reply to this post by Zaaphod
On 5/11/17, James Richters <[hidden email]> wrote:
> I have a few console graphics applications that I originally wrote in Turbo
> Pascal that I have been able to convert over to Free Pascal and now have
> windows versions of these programs.

Porting them to Lazarus (GUI) is not an option?

Bart
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Graeme Geldenhuys-6
In reply to this post by Zaaphod
On 2017-05-11 19:43, James Richters wrote:
> Any Suggestions?

Speed:
   In recent graphics work I've done, I've noticed that FPC is fantastic
   at created cross-platform applications. But the generated binaries
   are NOT fast at all - no matter how many compiler parameters and
   artificial speed optimisations we tried to implement. Sloppy Java
   code ended up 3x faster than the best I could get out of FPC
   generated binaries.

   I'm not saying this is your performance problem (especially comparing
   a 3Ghs PC vs a 233Mhz PC) - there certainly seems to be another
   problem contributing to your speed issue.

Graphics:
   I highly recommend you take a look as AggPas. It is a 100% high
   quality sub-pixel rendering engine - hand ported from the original
   C++ code. The latest and most up to date AggPas (there are a few
   forks from the original) can be found in the fpGUI code repository.
   The AggPas code is totally independent of the rest of fpGUI, so
   you can write per console applications that uses AggPas and render
   to any image format, byte array etc.

   For examples of what AggPas can do, take a look at this following
   websites:

     Agg (Anti-Grain Geomerty):
       http://www.antigrain.com/about/

     AggPas (Pascal port):
       http://crossgl.com/aggpas/aggpas-demo.htm

     Latest AggPas code:
 
https://github.com/graemeg/fpGUI/tree/develop/src/corelib/render/software


Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Brian
I have an older project (Virtual Pascal) using DPMI32 and writing to the graphics card  , and had the same issue as you when deciding which graphics library to use for Linux. In my case , part of the application is GUI and part is very fast 2D pixel graphics (points lines , polygons etc.)

The first approach in porting to Linux was to write directly to the Linux graphics frame buffer and bypassing X11 entirely. This is very fast but that leaves you without many of the benefits of Linux.

The second approach was to write directly to X11 , but writing a lot of pixel data to the X11 server will cause the X11 server to bog down and even crash. X11 is a server so that approach was ruled out.

The chosen approach is to use SDL2.0+. If you are coming from pixel based BGI graphics where everything is pixel based , SDL takes a bit of getting used to , as everything (SDL 2.0) is based on textures. You write to a texture and render it to the graphics card as and when or periodically.

In your case if you have a lot of pixel writing , SDL 2.0 has a very clever mechanism where you can render to a software (CPU memory) frame buffer at whatever rate you want and render (copy) that frame buffer to the graphics card at say 60Hz frame rate which make things appear faster than the eye can perceive.

Here is basically how to do it.

http://gigi.nullneuron.net/gigilabs/sdl2-pixel-drawing/

There is a nice Image  and TTF library with SDL 2.0

Brian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Brian
Forgot to mention.

SDL2.0 is multi platform and uses accelerated graphics.

https://www.libsdl.org/

The best speed is achieved with NVidia graphics cards and proprietary NVidia drivers rather than the default Linux X.org drivers.

http://www.freepascal-meets-sdl.net/chapter-1-introduction/

Brian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Jon Foster
In reply to this post by Graeme Geldenhuys-6

On 05/11/2017 02:48 PM, Graeme Geldenhuys wrote:

> On 2017-05-11 19:43, James Richters wrote:
>> Any Suggestions?
>
> Speed:
>   In recent graphics work I've done, I've noticed that FPC is fantastic
>   at created cross-platform applications. But the generated binaries
>   are NOT fast at all - no matter how many compiler parameters and
>   artificial speed optimisations we tried to implement. Sloppy Java
>   code ended up 3x faster than the best I could get out of FPC
>   generated binaries.
>
>   I'm not saying this is your performance problem (especially comparing
>   a 3Ghs PC vs a 233Mhz PC) - there certainly seems to be another
>   problem contributing to your speed issue.
Wow, Graeme! That's harsh. One of the last set of benchmarks I did that
focused on integer math and procedure call speed came out as follows:

Run 1M numbers
Intel 2GHz 2016:
===================================
pascal:        2:09s - 2:12
c:             2:06s - 3:05
Java           2:11s - 2:24
js (JIT):      2:23s - 2:27
python:       36:43s - 37:02
php:          38:16s - 40:45
js (interp):  60:51s - 64:10
perl:         69:19s - 74:26

Times are in minutes:seconds.

"Pascal" is, of course, FPC. I believe I used fpc 2.6.4 w/ -O2 on that run.
Its been a while. The code that was used was as identical as it could be
for each of the languages represented. I was interested in the speed of the
languages' general mechanics, not special features that one might have over
the others. These are the performance ranges from my Linux box running at
2GHz. I ran four runs each. On average the Pascal code performed about the
same for each run and the C code, for whatever reason, tended to get slower.

Two things surprised me when I ran this: the Java speed and the speed of
the initial JavaScript run. I used SpiderMonkey (Mozilla) for the JS test
and OpenJDK 6 for Java. Both apparently have *VERY* effective JIT
compilers. You can see from the "js (interp)" entry what you would expect
if the benchmark were run in a browser. But I think Chrome(ium) is/are
starting to ship with JIT enabled in V8. I didn't bother to find out how to
turn off JIT in OpenJDK. If I had, I'd expect it to fall in the 40minut
range like the rest of the interpreters.

As far as raw computational power I'd pit FPC against any
native-code-compiled language, especially considering the register calling
convention. I've rewritten several of the standard *nix routines provided
by GNU simply because I can do it 100x or more faster in FPC.

In short if your suffering a performance issue I'd look to the libraries in
use for poor implementations. Like anything else, bad software can be
written with FPC too.

A funny story:

Back in 2000 I wrote a TStringList replacement because the Delphi/Kylix
version was astoundingly slow (specifically TStringList.IndexOf()). I
thought I'd get fancy and provide a mode where I'd keep the list sorted and
use a binary search to find elements. I figured it'd be fast because
reordering the list was just moving pointers. In either mode it was way
faster than the Borland's implementation. Fast forward to about 2010 and I
was parsing millions of Apache log lines and using my trusty string list
when I noticed it was taking a LOT longer than expected. I turned off the
fancy sorted-binary-search mode and performance was significantly better.
But that left me scratching my head. What was wrong with my logic?

Last year I finally got mad at it and took a closer look. Since I could not
find a flaw in my logic I looked at the assembly code produced by FPC.
Turns out that every time you assign a long string to a variable it makes a
function call to inc & dec the use counter as necesary. This was adding a
*HUGE* performance penalty! I now fake FPC out by casting to pointers to
move the strings in the list, since I'm not actually changing the use
count. The performance gain was staggering!

--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
[hidden email]

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Marco van de Voort
In reply to this post by Zaaphod
In our previous episode, James Richters said:
> I have a few console graphics applications that I originally wrote in Turbo
> Pascal that I have been able to convert over to Free Pascal and now have
> windows versions of these programs.  I notice that unless I run my program
> on a 3.5GHz machine or faster, the graphics are fairly slow.    By slow, I
> mean noticeably slower than they were on a Pentium 233 DOS machine with
> Turbo Pascal.

This is wingraph based? Or what unit and compiler target do you actually
use?

The logical progression would be a TPaintbox in a lazarus gui environment.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Marco van de Voort
In reply to this post by Graeme Geldenhuys-6
In our previous episode, Graeme Geldenhuys said:
>
> Speed:
>    In recent graphics work I've done, I've noticed that FPC is fantastic
>    at created cross-platform applications. But the generated binaries
>    are NOT fast at all - no matter how many compiler parameters and
>    artificial speed optimisations we tried to implement. Sloppy Java
>    code ended up 3x faster than the best I could get out of FPC
>    generated binaries.

(Quite confusing paragraph mixing up graphics (which is typically bound in
speed by the drawing API that you use) and generated code speed, what did
you actually mean?)
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Graeme Geldenhuys-6
On 2017-05-12 08:30, Marco van de Voort wrote:
> (Quite confusing paragraph mixing up graphics (which is typically bound in
> speed by the drawing API that you use) and generated code speed, what did
> you actually mean?)

I was discussed heavily in the Lazarus Forum. The test was a 3D software
raycaster (think Doom or Wolfenstein games, but with 3d camera angles).
Virtually identical code between Object Pascal, C and Java was written,
using the exact same window size and rendering world. The Object Pascal
code compiled with FPC managed to get a dismal 8 FPS maximum. The C and
Java code managed to run between 35-45 FPS.

When the application runs, most of the time spent is finding
intersection points in the raycasting engine and rendering each frame to
the image buffer. In overall comparison, very little time is spent
bit-blitting the image buffer to the screen.

I felt the test was a good one, as 90-95% is spent in the ray-casting
engine, not the graphics API. Also, as the different language
implementations were near identical, it was a good compiler comparison -
to see how good they can optimise near identical written code.

The results shouldn't have come as too much of a surprise though. It was
often said, in this mailing list, that FPC's goal is maintainability and
multiple platform support. Good optimised binaries is a distant third.
The same comparison has been made numerous times between Delphi and FPC,
and the same answer was always given. FPC supports multiple CPU's and
OSes, and at the time Delphi only supported x86, so Borland could do
more optimisations.

Anyway, I don't want to hijack this thread with this discussion, rather
see the discussion in the Lazarus Forum - Graphics section. The test
code was posted there too.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Marco van de Voort
In our previous episode, Graeme Geldenhuys said:
> When the application runs, most of the time spent is finding
> intersection points in the raycasting engine and rendering each frame to
> the image buffer. In overall comparison, very little time is spent
> bit-blitting the image buffer to the screen.

Ah ok, so a tight loop benchmark.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Graeme Geldenhuys-6
On 2017-05-12 10:28, Marco van de Voort wrote:
> Ah ok, so a tight loop benchmark.

And lots of colour value loop-ups. Nothing wrong with that - how else
are you supposed to implement a software raycaster.

It must be noted, my intention was not to implement a "benchmark". I had
a Java implementation, but preferred to continue my work using Object
Pascal. So I ported the code, and then noticed the terrible performance
- so canned that idea after numerous failed attempts to improve what FPC
generated. Obviously, normal desktop apps work fine with FPC, and if you
do graphics work, make sure you offload as much as possible to a GPU.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Felipe Monteiro de Carvalho
In reply to this post by Graeme Geldenhuys-6
On Fri, May 12, 2017 at 10:01 AM, Graeme Geldenhuys
<[hidden email]> wrote:
> The results shouldn't have come as too much of a surprise though. It was
> often said, in this mailing list, that FPC's goal is maintainability and
> multiple platform support. Good optimised binaries is a distant third.

I don't think it is the case since Java is multiplaform also. IMHO
what happened is simple: 10 years ago Java was laughting stock,
infamous for being so slow. Then Oracle and IBM invested millions to
make Java top-dog, probably inferior only to C++. In the same time
frame FPC devs were already satisfied with the speed, so people worked
on adding support for more platforms and fixing bugs. So that's it.
Java has multi-billion dollar companies behind it. We don't.

Java probably has developers who work full-time only in improving
speed. It was just a question of time until they would catch up.

I honestly thought 10 years ago that C++, Java, C# were only temporary
stuff, waiting to be dropped for the "next great thing". While
Objective C indeed proved to be temporary (Apple now loves Swift), but
the big 3 seam to have arrived to stay. From those I guess C# is the
least safe, but C++ and Java look deeply entrenched.

--
Felipe Monteiro de Carvalho
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Graeme Geldenhuys-6
On 2017-05-12 10:40, Felipe Monteiro de Carvalho wrote:
> I don't think it is the case since Java is multiplaform also. IMHO
> ...snip...
> Java has multi-billion dollar companies behind it. We don't.


Apples and Oranges. I honest don't care much about how things arrived
where they are today. The bottom line is that Java now generates
extremely efficient code, even if the written source code is not of
highest quality, or not manually optimised by the developer. FPC can't
do that (yet).

Use the right tool for the job. FPC is not the right tool for software
rendered games (which rely on fast optimised binaries), but FPC is
perfect for many other areas.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Adriaan van Os-2
In reply to this post by Graeme Geldenhuys-6
Graeme Geldenhuys wrote:
> On 2017-05-12 10:28, Marco van de Voort wrote:
>> Ah ok, so a tight loop benchmark.
>
> And lots of colour value loop-ups. Nothing wrong with that - how else
> are you supposed to implement a software raycaster.

Instead of complaining, one should do exact profiling, to determine the cause of the delay. And
then report precise facts. I never have speed-problems in Pascal. One should start by choosing the
right method. There is always a smarter (e.g. faster) way to do things.

Regards,

Adriaan van Os

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Graeme Geldenhuys-6
In reply to this post by Jon Foster
On 2017-05-12 00:57, Jon Foster wrote:
> One of the last set of benchmarks I did that

Please note, I did not set out to implement a benchmark. I think all
purpose written benchmarks are bias and unrealistic. I implemented a
legit software raycaster for a game I was developing. Initially I was
going to implement it in Java, but then thought I would rather like to
use my much loved Object Pascal language. That plan failed in the end.


> Two things surprised me when I ran this: the Java speed and the speed of
> the initial JavaScript run. I used SpiderMonkey (Mozilla) for the JS test
> and OpenJDK 6 for Java.

I was developing with Java 8 (OpenJDK). And yes, Java speed is
phenomenal these days. A far cry from the performance seen in the late 90's.


> In short if your suffering a performance issue I'd look to the libraries in
> use for poor implementations. Like anything else, bad software can be
> written with FPC too.

Both the Java and Object Pascal code was poorly written - because they
were very closely based on a JavaScript implementation which was meant
for a 4KBytes competition (see how much your can do in just 4KB).

Still, the Java compiler did a better job in optimising the final binary
code. The developers in the Lazarus Forum made numerous suggestions on
how to improve the speed of the Object Pascal version. I tried
everything they suggested and maybe gained 2-5 FPS in the end. Still
nothing compared to the performance of the Java or C versions, where no
manual optimisation was applied.


Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Marco van de Voort
In reply to this post by Graeme Geldenhuys-6
In our previous episode, Graeme Geldenhuys said:
> > Ah ok, so a tight loop benchmark.
>
> And lots of colour value loop-ups. Nothing wrong with that - how else
> are you supposed to implement a software raycaster.

I mean it does an awful lot of calculation with very overviewable,
localizzed datastructures that are thus very optimizable.  Moreover, the
achilles heal of Java, GC, doesn't come into play large scale.

A lot of graphics code will have such heavy loops of code, but a raycaster
is extreme since it is purely calculating, and few applications, even if
graphical in nature will have this kind of code as only rate determining
code. And then I'm not even talking about auto-vectorization.

In general FPC and Delphi code is fine, unless you touch such domains, where
it all depends if you implemented all optimizations and transformations in
the book.

Functional language interpreters are afaik another such special case, where
small differences can be amplified enormously. No doubt FPC will score
relatively bad against the corporate (sponsored) behemoths there too

Lies, damned lies and benchmarks.

> It must be noted, my intention was not to implement a "benchmark".

Yes. But you do try to make a performance point with a samplesize of 1,
which is not exactly a typical one.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Graeme Geldenhuys-6
On 2017-05-12 11:22, Marco van de Voort wrote:
> Lies, damned lies and benchmarks.

:)  I went as far as I could with my project and Object Pascal. I
welcome a compiler guru to dissect the FPC and C binaries and do ASM
comparisons to see where GCC did a better job - in the hopes that such
compiler optimisations could one day filter back into FPC. That is all
above my skill level. I also fully understand that optimisation at such
a level is not a top priority for the Free Pascal team, and the effort
vs gains vs targeted (real-world) usage is very limited. Like I said,
FPC is very good at other things, which is fine for 99% of use cases
(mine and others).

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Michael Schnell
In reply to this post by Jon Foster


On 12.05.2017 01:57, Jon Foster wrote:
>
>  One of the last set of benchmarks I did that focused on integer math
> and procedure call speed came out as follows:
Thanks for sharing !
> pascal:        2:09s - 2:12
> js (JIT):      2:23s - 2:27
> python:       36:43s - 37:02

Funny that JS (Text) with JIT is so good, and that Python (binary
byte-code, also supposed to use a kind of JIT), is so bad.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FPC Graphics options?

Marco van de Voort
In reply to this post by Graeme Geldenhuys-6
In our previous episode, Graeme Geldenhuys said:
> > Lies, damned lies and benchmarks.

(from the other posts I get that the program was relatively short, and maybe
even one single compilation unit? Benchmark smells)
 
> :)  I went as far as I could with my project and Object Pascal. I
> welcome a compiler guru to dissect the FPC and C binaries and do ASM
> comparisons to see where GCC did a better job

I'm not a real guru, but you learn at least the jargon a bit after almost
two decades on compiler lists.

Well, my guess is the devels already know.  And it depends on how commonly
useful the optimizations are.

My guess improvements in CSE and loop invariant hoisting would be the most
logical improvement areas.

Did you try ppcjvm on the fpc code btw? Could show if it is mainly in the
JIT or the actual compiler.

- in the hopes that such compiler optimisations could one day filter back
> into FPC.  That is all above my skill level.  I also fully understand that
> optimisation at such a level is not a top priority for the Free Pascal
> team, and the effort vs gains vs targeted (real-world) usage is very
> limited.  Like I said, FPC is very good at other things, which is fine for
> 99% of use cases (mine and others).

Most of the people seem to be busy to process relatively higher level
external systems(like json) and pass them to even higher level languages
(like javascript), often over relatively slow network links.

That said, I had a 5GBit/s camera blazing in the lab with one of our
applications lately. If you really want to, a lot is possible, also with
Delphi FPC/Lazarus.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
1234 ... 10
Loading...