Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/12/2017 10:13 PM, Graeme Geldenhuys wrote:
 Your unit obvious saves some time if it is already API compatible 
with the TP Graph unit.
Yes, that's exactly what I'm saying. It's a drop-in replacement for the 
graph unit. It runs TP7 BGI (or FPC programs for go32v2 for that matter) 
graphic demos with only a recompilation under Windows or Linux. The only 
reason we haven't replaced the regular graph unit yet, is backward 
compatibility with the previous win32 graph unit, which has some extra 
windowsisms, which aren't compatible with ptcgraph (and will never be, 
because they are not platform independent). And, as you probably know, 
backward compatibility is followed religiously by the FPC project ;-)


Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-12 19:10, Nikolay Nikolov wrote:

All the ptcgraph graph drawing procedures and
functions render to a software framebuffer, which is periodically
blitted to the screen


And that is exactly what I suggested (or implied), but just using 
AggPas. Your unit obvious saves some time if it is already API 
compatible with the TP Graph unit.


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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Help me find a mp3 -> pcm audio data pascal implementation

[fredvs]

Sandro Cumerlato wrote
> Hello Fred,
> I compiled it a few years ago, but I don't remember which compiler I
> used, sorry.
> 
> IAP is  demo itself, but I remember that during my testing it was
> quite unstable.
> 
> Maybe you can contact the author (C.W. Budde) directly for more info, good
> luck.
> 
> Sandro Cumerlato

OK, thanks.

Fre;D



-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Help-me-find-a-mp3-pcm-audio-data-pascal-implementation-tp5728503p5728544.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/12/2017 10:30 AM, Marco van de Voort wrote:

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?)
Indeed, Graeme's example (a software raytracer) has absolutely *nothing* 
to do with the slowness of the win32/win64 graph unit. The bottleneck in 
the graph unit implementation is the speed of the windows gdi drawing 
routines, which were never really designed to be used in the way Turbo 
Pascal's graph unit works. Because the TP7 graph unit was designed for 
DOS, where you get direct access to the video hardware, normally, 
there's simply no concept for double buffering. TP7 graph unit programs 
never really render a full frame and then call SwapBuffers(), they just 
draw on the screen and it's immediately visible. The way the win32/win64 
graph unit is implemented, is by effectively doing the equivalent of 
SwapBuffers() after each graph procedure/function call that draws 
something. Ptcgraph uses a different approach and that's why it is in 
practice much faster. All the ptcgraph graph drawing procedures and 
functions render to a software framebuffer, which is periodically 
blitted to the screen in a separate thread (at about 60 fps, but the 
framerate isn't really controlled). This works great, especially on 
modern multicore CPUs. Of course, this goes up to a point, where the 
resolution gets too high for software rendering and the framerate drops 
somewhat (but this happens at Full HD resolutions, that TP7 programs are 
unlikely to use - and even there the speed may be acceptable, if the CPU 
is fast enough). The main disadvantage is that you get a CPU core loaded 
at 100%, but this isn't really that much worse, compared to what certain 
"modern" applications do :) I even know a happy ptcgraph user, who uses 
ptcgraph in Full HD resolutions on a Raspberry PI. :) So, please, try 
ptcgraph and see if it makes a difference for you.


Best regards,
Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-12 17:24, Jon Foster wrote:

I don't suppose you could post a link to the Lazarus forum discussion. I'm
extremely curious and so far my hunting on the forum hasn't turned up anything.


Indeed, searching the Lazarus Forums is 99% luck, 1% relevant.

The start of the thread:
   http://forum.lazarus.freepascal.org/index.php/topic,3.0.html


My Object Pascal version:

http://forum.lazarus.freepascal.org/index.php/topic,3.msg235937.html#msg235937

My Java version:

http://forum.lazarus.freepascal.org/index.php/topic,3.msg236090.html#msg236090


JavaScript and C versions:

http://forum.lazarus.freepascal.org/index.php/topic,3.msg236352.html#msg236352


Improved JavaScript versions:

http://forum.lazarus.freepascal.org/index.php/topic,3.msg236356.html#msg236356



PLEASE NOTE:
  Many of the guys there did not pay attention to detail. The demo 
should run at an exact resolution, and the camera viewpoint should

be in the centre of the tunnel. Some versions posted by others, the
camera viewpoint is on the edge of the tunnel or at different 
resolutions. So when you do comparisons, make sure everything is exactly 
the same, otherwise you don't get accurate comparisons.



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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/11/2017 10:25 PM, Sven Barth via fpc-pascal wrote:

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...
If you want to keep your old code, try ptcgraph! If you want to use the 
"legacy" graph unit api, ptcgraph is pretty much as fast as you can go 
:) It should be faster than the regular graph unit under windows. If 
it's still not fast enough for you, you should switch to a more modern 
api, but this requires rewriting your code. And afaik, sdlgraph is 
broken and has never worked, so don't waste time with it.


Disclaimer: I'm the author of ptcgraph, so I'm obviously biased, but 
that also means I've done a lot of work on porting the "legacy" graph 
unit api to modern platforms. Ultimately, it's up to you to decide what 
to use, but since you already have code, that uses the graph unit, 
trying ptcgraph should be the cheapest option, requiring almost no 
changes to the code.


Best regards,
Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/12/2017 03:11 AM, Graeme Geldenhuys wrote:

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.
I don't suppose you could post a link to the Lazarus forum discussion. I'm 
extremely curious and so far my hunting on the forum hasn't turned up anything.


THX!

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

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Help me find a mp3 -> pcm audio data pascal implementation

[Sandro Cumerlato]

Hello Fred,
I compiled it a few years ago, but I don't remember which compiler I
used, sorry.

IAP is  demo itself, but I remember that during my testing it was
quite unstable.

Maybe you can contact the author (C.W. Budde) directly for more info, good luck.

Sandro Cumerlato




On 12 May 2017 at 13:16, fredvs  wrote:
> Hello Sandro.
>
>
> Sandro Cumerlato wrote
>> IIRC a Pascal mpeg decoder is implemented within IAP:
>>
>> https://github.com/CWBudde/IAP
>
> Wow.
>
> I see the code is for Delphi.
> Did you try it with fpc ?
>
> There are no demo for mpeg decoder.
> Do you know how to use it ?
>
> Thanks.
>
> Fre;D
>
>
>
> -
> Many thanks ;-)
> --
> View this message in context: 
> http://free-pascal-general.1045716.n5.nabble.com/Help-me-find-a-mp3-pcm-audio-data-pascal-implementation-tp5728503p5728534.html
> Sent from the Free Pascal - General mailing list archive at Nabble.com.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Best way to check SimpleIPC for messages

[Michael Van Canneyt]

On Fri, 12 May 2017, nore...@z505.com wrote:

Is the best general way to check IPC messages in SimpleIPC to spawn a 
thread? and check


I noticed in fpgui sample apps that use simpleipc, graemeg checks the 
messages in the fpgui OnIdle event, AFAICT, not a separate thread. But 
what if you are running a console mode program that has no onidle event?


Obviously "avoid threads where possible" but only if there is a simpler 
mechanism not reinventing a thread. So it seems to me onidle in fpgui is 
a simpler way than creating a new separate thread yourself, but how to 
do it in a program that has no fpgui onidle?


Check manually. What else is left ? 
There is no message queue, so no loop in which to check at regular basis.


On that note what would a lazarus app generally do to check for 
messages, without locking the app up? A similar OnIdle solution?


Yes. The sample programs check in Application.OnIdle.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Best way to check SimpleIPC for messages

[noreply]

Is the best general way to check IPC messages in SimpleIPC to spawn a 
thread? and check


I noticed in fpgui sample apps that use simpleipc, graemeg checks the 
messages in the fpgui OnIdle event, AFAICT, not a separate thread. But 
what if you are running a console mode program that has no onidle event?


Obviously "avoid threads where possible" but only if there is a simpler 
mechanism not reinventing a thread. So it seems to me onidle in fpgui is 
a simpler way than creating a new separate thread yourself, but how to 
do it in a program that has no fpgui onidle?


On that note what would a lazarus app generally do to check for 
messages, without locking the app up? A similar OnIdle solution?


Making some progress on the SimpleIPC DLL for any programming language, 
but trying to figure out whether the end user of the dll should create 
his own thread to check for ipc messages, or have the dll do it for him 
to simplify, then fire a callback when message received.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Sven Barth via fpc-pascal]

Am 12.05.2017 11:10 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
>
> On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote:>> Am 11.05.2017
>
>> 18:14 schrieb "Jon Foster" 
>> >:> > Anyhow tips on the FPC->C++
>> front would be appreciated. I will probably > search the list archives
>> as I know this topic comes up repeatedly. I > don't understand how
>> ginormous an undertaking this might be but maybe I > can contribute
>> something on this front.>> I can't speak for other approaches to
>> interface with C++ code, but > patches to the compiler's cppclass
>> support are definitely welcome :D It > will never support everything
>> there is in C++, but if we'd manage to > interface with most library
>> code that would be something...
>
>
> Apologies for bad threading here. Sven, can I just go off on a slight
tangent before that part of the discussion adjourns to fpc-devel, since
this is a user rather than a developer question.
>
> What's the current situation with FPC interface to the Subversion support
libraries which I think is something you were looking at at one point?

Nope, I never looked at the Subversion libraries.

> In extremis, I suppose that it should be possible for a program written
in FPC to use Lua as a shim when calling C++.

Before that I'd say the Delphi support for the binding generator SWIG
should be checked (at least I thought it already had some).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-12 11:55, Marco van de Voort wrote:

(from the other posts I get that the program was relatively short, and maybe
even one single compilation unit? Benchmark smells)


As I'm always told when reporting issues... supply a small example 
program that shows the problem. I wasn't going to post the full source 
code for a whole game, just to show that the raycasting engine is where 
the slowdown happens. My profiling already narrowed that part down. So I 
posted a single unit as a small example program. No other intentions 
were implied.




Did you try ppcjvm on the fpc code btw?


No, I've never used the JVM backend of FPC. Time permitting, I'll give 
it a try - simply out of curiosity.



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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Help me find a mp3 -> pcm audio data pascal implementation

[fredvs]

Hello Sandro.


Sandro Cumerlato wrote
> IIRC a Pascal mpeg decoder is implemented within IAP:
> 
> https://github.com/CWBudde/IAP

Wow.

I see the code is for Delphi.
Did you try it with fpc ?

There are no demo for mpeg decoder.
Do you know how to use it ?

Thanks.

Fre;D



-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Help-me-find-a-mp3-pcm-audio-data-pascal-implementation-tp5728503p5728534.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Adriaan van Os]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

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.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Felipe Monteiro de Carvalho]

On Fri, May 12, 2017 at 10:01 AM, Graeme Geldenhuys
 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Mark Morgan Lloyd]

On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote:>> Am 11.05.2017


18:14 schrieb "Jon Foster" 
>:> > Anyhow tips on the FPC->C++
front would be appreciated. I will probably > search the list archives
as I know this topic comes up repeatedly. I > don't understand how
ginormous an undertaking this might be but maybe I > can contribute
something on this front.>> I can't speak for other approaches to
interface with C++ code, but > patches to the compiler's cppclass
support are definitely welcome :D It > will never support everything
there is in C++, but if we'd manage to > interface with most library
code that would be something...


Apologies for bad threading here. Sven, can I just go off on a slight 
tangent before that part of the discussion adjourns to fpc-devel, since 
this is a user rather than a developer question.


What's the current situation with FPC interface to the Subversion 
support libraries which I think is something you were looking at at one 
point?


In extremis, I suppose that it should be possible for a program written 
in FPC to use Lua as a shim when calling C++.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal