On Saturday 27 May 2017 03:37:59 Ryan Joseph wrote:
>
> Is MSElang another Pascal compiler? I’ve never heard of it. I know LLVM is
> being used by Apple for Objective-C/Swift (I think) but for Pascal?
>
https://gitlab.com/mseide-msegui/mselang/wikis/home
Martin
> On May 24, 2017, at 11:47 PM, Martin Schreiber wrote:
>
> MSElang, LLVM 3.8.0
> No options -> 4.2 FPS
> -O3 -> 5.9 FPS
> -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 33.5 FPS
>
> With trunci32() operations
> https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest_trunc
seems fpc faster than llvm on -O3/4 only . this is a good news :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
On Saturday 20 May 2017 21:34:34 Jonas Maebe wrote:
>
> Also in summary, very little was learned from this. We have known for a
> long time that FPC needs SSA for better code generation for loops (and
> Florian has been working on it for a long time too).
>
Here for comparison the results of FPC /
s Richters
Sent: Tuesday, May 23, 2017 5:40 PM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] FPC Graphics options?
Just like you now use -FuSomePath to tell the compiler where to find units, you
can use -FiSomePath to tell the compiler where to look for include files.
I&#
to someone.
James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of
James Richters
Sent: Tuesday, May 23, 2017 5:40 PM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] FPC Graphics options?
>Just like you now use
3, 2017 2:07 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?
On 05/23/2017 08:28 PM, James Richters wrote:
I have done the "download snapshot" but I just don't know what to do with it
now to properly integrate it into my compiler.
Follow the instructio
>Just like you now use -FuSomePath to tell the compiler where to find units,
>you can use -FiSomePath to tell the compiler where to look for include files.
I've been trying to compile with Free Pascal Text IDE, I have no experience
with compiling programs from the command line, but this gave me
Am 23.05.2017 um 05:15 schrieb Ryan Joseph:
> and compiling with -O2 -Cfsse3 (the non-SDL
If you do benchmarking, at least -O3 should be used, -O4 is also fine most of
the time.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.fr
t: Tuesday, May 23, 2017 2:07 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?
On 05/23/2017 08:28 PM, James Richters wrote:
> I have done the "download snapshot" but I just don't know what to do with it
> now to properly integrate it
On 05/22/2017 07:13 PM, James Richters wrote:
The problem is not the ALT-tab from the graphics window, it's ALT being
pressed when the window focus changes. CTRL is also affected, but not
shift.
this is really sounding like a problem i remember from early GUIs several
decades ago... when swit
will find the correct versions of all the files necessary?
James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On
Behalf Of James Richters
Sent: Monday, May 22, 2017 7:13 PM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] FPC
ikolov
Sent: Tuesday, May 23, 2017 1:03 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?
On 05/23/2017 06:09 PM, James Richters wrote:
> I think I figured out my problem, but I'm not sure how to fix it. I was
> looking at the code here: https:
all the files necessary?
James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of
James Richters
Sent: Monday, May 22, 2017 7:13 PM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] FPC Graphics options?
Here is a simpl
.freepascal.org] On Behalf Of
James Richters
Sent: Monday, May 22, 2017 7:13 PM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] FPC Graphics options?
>Here is a simple sample program that has the issue for me on both my windows
>10 desktop and my windows 10 laptop, bo
On 2017-05-22 23:11, nore...@z505.com wrote:
What happens if you use the SVN bridge that allows you to run svn
commands to a git server? does git suffer the same problems in this mode
too?
Replied in "fpc-other" mailing list.
Regards,
Graeme
___
f
> On May 22, 2017, at 9:24 PM, Marco van de Voort wrote:
>
> I saw Florian worked hard last weekend, and the new value is 23.0 - 23.6
> (was 19.1 - 19.5) for x86_64. Sometimes floating point division by zero.
>
> and for x86 10.8 but half of the time I get an exception (ctrl-C ??!?!) here.
Tha
I realized I should have posted this in fpc-other. So, please reply in
[fpc-other] and not here.
On 05/23/2017 03:03 AM, Nikolay Nikolov wrote:
On 05/23/2017 01:20 AM, nore...@z505.com wrote:
On 2017-05-18 19:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster
wrote:
62.44
On 05/23/2017 01:20 AM, nore...@z505.com wrote:
On 2017-05-18 19:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster
wrote:
62.44 1.33 1.33 fpc_frac_real
26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33 2.12 0.22 FPC_DIV_INT64
Thanks for profili
>Here is a simple sample program that has the issue for me on both my windows
>10 desktop and my windows 10 laptop, both are 64bit.
>https://hastebin.com/nubonozaho.pas
I started thinking about this, and did some more tests, and I think I have
narrowed down what is really happening, but not sure
On 2017-05-18 10:12, Graeme Geldenhuys wrote:
On 2017-05-18 16:04, Ryan Joseph wrote:
After I looked at the code I didn't see anything strange about it
Thank you, that's what I thought too.
it just got me thinking, if that code can be that slow how slow is
all the stuff I’m writing on a dail
On 2017-05-18 19:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster
wrote:
62.44 1.33 1.33 fpc_frac_real
26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33 2.12 0.22 FPC_DIV_INT64
Thanks for pr
On 2017-05-19 05:25, Graeme Geldenhuys wrote:
On 2017-05-19 06:58, Florian Klämpfl wrote:
Over the weekend I’ll verify by testing on both FreeBSD and Windows,
and
then see if “calling conventions” make any difference.
*BSD is the same as Linux.
Good to know, thanks.
It has its purposes, b
On 2017-05-19 06:16, Graeme Geldenhuys wrote:
On 2017-05-18 16:33, Reimar Grabowski wrote:
and JS is clearly not faster than FPC.
The JavaScript version runs very smooth on my system. There is no
framerate counter though, so I don't know how much faster.
http://jsdo.it/notch/dB1E
Again, w
On 2017-05-19 06:32, Graeme Geldenhuys wrote:
Bottom line is, with the exact same code, NO work-arounds is required
for GCC or Java! So why must we have work-arounds for FPC? It's a
compiler or RTL issue - not being able to understand the code good
enough to generate more efficient binaries.
Ag
Hi,
On Mon, 22 May 2017, Nikolay Nikolov wrote:
> Today, I checked whether we can take advantage of this optimization for
> floats, but I didn't see any load-modify-store instructions in the x86
> instruction set (neither x87, nor SSE/AVX). Are there any floating point
> instructions on any archi
Am 22.05.2017 um 19:34 schrieb Nikolay Nikolov:
>
>
> On 05/20/2017 12:07 AM, Nikolay Nikolov wrote:
>>
>>
>> On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote:
>>> On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Fri, 19 May 2017, Sven Barth via fpc-pascal wrot
On 05/20/2017 12:07 AM, Nikolay Nikolov wrote:
On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote:
On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:
I think Jeppe wanted to add vector support. Though the question
here i
In our previous episode, Marco van de Voort said:
>
> i386:
> just compile : 7.9 (both 3.0.2 and 3.1.1)
> -O4 3.0.2: 8.2 3.1.1: 8.1
> -O4 -Opcoreavx2 -Cfavx2 -Cpcoreavx2 3.0.2 8.35 3.1.1 : 12.1
>
>
> x64: only 3.1.1, sometimes divide by zero (have to set exception mask?)
>
On 05/16/2017 02:45 PM, Nikolay Nikolov wrote:
Tonight I'll also add the option for changing the title bar text,
when in windowed mode.
Implemented in r715. Note that you still cannot change the window title,
after the window has been created, but at least now you can set it (in a
multiplat
On 21/05/17 14:58, Felipe Monteiro de Carvalho wrote:
Well, Java also has its issues.
Please move that kind of posts to the fpc-other mailing list.
Thanks.
Jonas
FPC mailing lists admin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
ht
On Thu, May 18, 2017 at 5:05 PM, Graeme Geldenhuys
wrote:
> Use Java instead. ;-) Check. Oh wait, that's what I did for that project.
Well, Java also has its issues. I am studying Java and I am completely
shocked that you need to use "volatile" to avoid serious hard-to-debug
multithreading bugs.
On 21/05/17 10:35, Florian Klämpfl wrote:
Am 20.05.2017 um 23:15 schrieb Sven Barth via fpc-pascal:
At least if the compiler also recognizes that oy and oz are constant...
If the typed constants are declared as read only, we could treat them as real
constants. Maybe at
least in -O4 mode?
Th
On 05/21/2017 06:34 AM, Ryan Joseph wrote:
I just compiled with ppcx64 3.1.1 (from 3.0.2) and went from 8fps to 22fps
without optimizations and 28fpc with (I got some divide by zero errors but
that’s just translations). What is that about? What changed?
Just curious, why isn’t -Cfsse3 alway
Am 20.05.2017 um 23:15 schrieb Sven Barth via fpc-pascal:
> On 20.05.2017 21:34, Jonas Maebe wrote:
>> There's at least one minor twist of the classic "C compiler evaluates
>> constant stuff at compile time":
>> 1) oy and oz are constant. The "floor" function is a standard C library
>> function, an
> On May 21, 2017, at 2:34 AM, Jonas Maebe wrote:
> The Pascal test program that was benchmarked here contains a number of
> bugs/wrong translations from the C code (some stem from the original version,
> another one was added):
Thanks for looking this over. I’m personally a little worried whe
On 20.05.2017 21:34, Jonas Maebe wrote:
> There's at least one minor twist of the classic "C compiler evaluates
> constant stuff at compile time":
> 1) oy and oz are constant. The "floor" function is a standard C library
> function, and hence C compilers know what it does and can evaluate it at
> c
Am 20.05.2017 um 21:34 schrieb Jonas Maebe:
> Also in summary, very little was learned from this. We have known for a long
> time that FPC needs SSA
> for better code generation for loops (and Florian has been working on it for
> a long time too).
Actually, this is not completely true :) What FP
On 19/05/17 02:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster wrote:
62.44 1.33 1.33 fpc_frac_real
26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33 2.12 0.22 FPC_DIV_INT64
Thanks for profil
On 05/19/2017 06:13 PM, Jon Foster wrote:
On 05/19/2017 04:11 AM, Nikolay Nikolov wrote:
On 05/19/2017 03:54 AM, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster
wrote:
62.44 1.33 1.33 fpc_frac_real
26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33
On 05/19/2017 04:11 AM, Nikolay Nikolov wrote:
On 05/19/2017 03:54 AM, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster
wrote:
62.44 1.33 1.33 fpc_frac_real
26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33 2.12 0.22 FPC_DIV_INT64
Thanks for profi
Am 19.05.2017 22:24 schrieb "Sven Barth" :
>
> On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
> > Hi,
> >
> > On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:
> >
> >> I think Jeppe wanted to add vector support. Though the question here is
> >> whether one wants to optimize/detect thi
On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote:
On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:
I think Jeppe wanted to add vector support. Though the question here is
whether one wants to optimize/detect this at the
On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote:
> Hi,
>
> On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:
>
>> I think Jeppe wanted to add vector support. Though the question here is
>> whether one wants to optimize/detect this at the AST level and convert
>> that to implicit vector
Hi,
On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:
> I think Jeppe wanted to add vector support. Though the question here is
> whether one wants to optimize/detect this at the AST level and convert
> that to implicit vectors or at the CSE level.
I think the higher level you can do an opti
In our previous episode, Sven Barth via fpc-pascal said:
> >
> > I also tried -Oofastmath, but to no avail. (floor is still external, and
> > still double)
>
> Floor is not declared as inline and even the Trunc()/Frac() intrinsics it
> uses wouldn't be inlined as they're assembler routines and FPC
Am 19.05.2017 16:39 schrieb "Karoly Balogh (Charlie/SGR)" <
char...@scenergy.dfmk.hu>:
>
> Hi,
>
> On Fri, 19 May 2017, Reimar Grabowski wrote:
>
> > Final: The render function takes about 90%, the cast-to-int about 5%. No
> > other interesting functions shown. So the missing time must be spent
> >
Am 19.05.2017 15:29 schrieb "Marco van de Voort" :
>
> In our previous episode, Sven Barth via fpc-pascal said:
> >
> > You only compiled the program with SSE, but not the RTL. And to
completely
> > avoid the x87 FPU you additionally need to fiddle around with some
> > defines/code inside the compi
On 05/18/2017 07:21 PM, Ryan Joseph wrote:
On May 19, 2017, at 8:01 AM, Jon Foster
wrote:
You can find both versions in my GitHub account:
https://github.com/jafcobend/fpcflop
Thanks again, I was finally able to get this complied. No idea why the
inclusion of SDL 2 was crashing at that line.
Hi,
On Fri, 19 May 2017, Reimar Grabowski wrote:
> Final: The render function takes about 90%, the cast-to-int about 5%. No
> other interesting functions shown. So the missing time must be spent
> doing floating point math and branching (ifs), as that's all the render
> function does.
Well, if I
In our previous episode, Sven Barth via fpc-pascal said:
>
> You only compiled the program with SSE, but not the RTL. And to completely
> avoid the x87 FPU you additionally need to fiddle around with some
> defines/code inside the compiler as well.
Hmm. in addition to my earlier benchmarks, the R
On Fri, 19 May 2017 14:34:40 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:
>[...]
> Not the point, the point is, does javascript generate exceptions on division
> by zero by default?
No. It creates Infinity.
Mattias
___
fpc-pascal maillist
On Fri, 19 May 2017 12:16:28 +0100
Graeme Geldenhuys wrote:
> Again, what does that say about FPC generated binary performance.
That we get a performance boost when we can compile FPC to JS?
You should try to compile graemecraft with FPC for the JVM, perhaps it boosts
performance. ^^
R.
___
On Fri, 19 May 2017 12:32:17 +0100
Graeme Geldenhuys wrote:
> And no, I don’t agree that this is a “special case”.
Doing lots of calculations in a tight loop is more or less a special case.
On the other hand I have written quite some code that doesn't do much else than
computing lots of stuff th
Am 19.05.2017 12:51 schrieb "Mattias Gaertner" :
>
> On Fri, 19 May 2017 10:54:25 +0200
> Sven Barth via fpc-pascal wrote:
>
> >[...]
> > Even though FPC might use SSE for maths it will still use the x87 to
> > transfer floating values to/from function, especially if they take
Extended
> > as para
Am 19.05.2017 13:32 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-05-19 12:11, Nikolay Nikolov wrote:
>>
>> In FPC, if you want to use SSE and
>> avoid the x87 FPU, you have to compile with a specific compiler options
>> and forfeit the option for your executable to run
In our previous episode, Graeme Geldenhuys said:
> > Then maybe the original code was DESIGNED for gcc and/or java ?
>
> Now you are taking the piss!
>
> The code I worked from was JavaScript actually. I posted the link a
> couple minutes ago. Translating the JavaScript code to Object Pascal was
On 2017-05-19 13:14, Karoly Balogh (Charlie/SGR) wrote:
Ps: can someone direct me to the right code you are discussing?
Forwarded Message
Subject: Re: [fpc-pascal] FPC Graphics options?
Date: Fri, 12 May 2017 18:29:05 +0100
From: Graeme Geldenhuys
To: fpc-pascal
On 2017-05-19 12:43, Marco van de Voort wrote:
Then maybe the original code was DESIGNED for gcc and/or java ?
Now you are taking the piss!
The code I worked from was JavaScript actually. I posted the link a
couple minutes ago. Translating the JavaScript code to Object Pascal was
a manual pr
Hi,
On Fri, 19 May 2017, Graeme Geldenhuys wrote:
> Bottom line is, with the exact same code, NO work-arounds is required
> for GCC or Java! So why must we have work-arounds for FPC? It's a
> compiler or RTL issue - not being able to understand the code good
> enough to generate more efficient bi
In our previous episode, Graeme Geldenhuys said:
> Bottom line is, with the exact same code, NO work-arounds is required
> for GCC or Java!
Then maybe the original code was DESIGNED for gcc and/or java ?
> So why must we have work-arounds for FPC?
The language is different. E.g. I get crashes
In our previous episode, Jon Foster said:
>
> I read that some were having trouble compiling Graeme's code because of SDL
> version differences so I stripped out the SDL code and replaced the timing
> function with traditional time/now calls. I then realized I still had Kylix
> buried in some r
On 2017-05-19 12:11, Nikolay Nikolov wrote:
In FPC, if you want to use SSE and
avoid the x87 FPU, you have to compile with a specific compiler options
and forfeit the option for your executable to run on non-SSE capable
CPUs, because FPC generates native code. If you want to keep
All good and w
On 2017-05-19 12:16, Graeme Geldenhuys wrote:
The JavaScript version runs very smooth on my system.
ps:
And it doesn't use WebGL either. Simply blitting of a
memory image to the canvas.
Regards,
Graeme
___
fpc-pascal maillist - fpc-pascal@l
On 05/19/2017 02:11 PM, Nikolay Nikolov wrote:
On 05/19/2017 03:54 AM, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster
wrote:
62.44 1.33 1.33 fpc_frac_real
26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33 2.12 0.22 FPC_DIV_INT64
Thanks for prof
On 2017-05-18 16:33, Reimar Grabowski wrote:
and JS is clearly not faster than FPC.
The JavaScript version runs very smooth on my system. There is no
framerate counter though, so I don't know how much faster.
http://jsdo.it/notch/dB1E
Again, what does that say about FPC generated binary
On 05/19/2017 03:54 AM, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster wrote:
62.44 1.33 1.33 fpc_frac_real
26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33 2.12 0.22 FPC_DIV_INT64
Thanks for
On Fri, 19 May 2017 10:54:25 +0200
Sven Barth via fpc-pascal wrote:
>[...]
> Even though FPC might use SSE for maths it will still use the x87 to
> transfer floating values to/from function, especially if they take Extended
> as parameter/result.
Can you elaborate on this?
I thought on x64 does
On 2017-05-19 06:58, Florian Klämpfl wrote:
Over the weekend I’ll verify by testing on both FreeBSD and Windows, and
then see if “calling conventions” make any difference.
*BSD is the same as Linux.
Good to know, thanks.
It has its purposes, but it is not suitable for the main repository o
Am 19.05.2017 03:30 schrieb "Ryan Joseph" :
>
>
> > On May 19, 2017, at 3:48 AM, Florian Klämpfl
wrote:
> >
> > Well, the reason are the linux calling conventions: there are no callee
saved xmm registers. This
> > means FPC does not use any single/double register variables. I have
some prototype f
Am 18. Mai 2017 11:59:30 nachm. schrieb Graeme Geldenhuys
:
> On 2017-05-18 21:48, Florian Klämpfl wrote:
>>
>> Well, the reason are the linux calling conventions:
>
> Not sure if it makes any difference, but I was testing under 64-bit
> FreeBSD. I believe on the Lazarus Forum, some folk were usin
> On May 19, 2017, at 8:01 AM, Jon Foster wrote:
>
> You can find both versions in my GitHub account:
> https://github.com/jafcobend/fpcflop
Thanks again, I was finally able to get this complied. No idea why the
inclusion of SDL 2 was crashing at that line.
The profiler on Mac seems to be in
> On May 19, 2017, at 3:48 AM, Florian Klämpfl wrote:
>
> Well, the reason are the linux calling conventions: there are no callee saved
> xmm registers. This
> means FPC does not use any single/double register variables. I have some
> prototype fixes in my local
> git mirror, but they are neit
> On May 18, 2017, at 10:40 PM, Jon Foster
> wrote:
>
> 62.44 1.33 1.33 fpc_frac_real
> 26.76 1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
> 10.33 2.12 0.22 FPC_DIV_INT64
Thanks for profiling this.
Floor is there
On 05/18/2017 08:56 AM, Reimar Grabowski wrote:
On Thu, 18 May 2017 08:40:43 -0700
Jon Foster wrote:
I limited run time to 10secs, and used "time" to verify actual run time.
Here are the results, time output listed first and the first section of the
gprof output without comments:
A little of
On 2017-05-18 21:48, Florian Klämpfl wrote:
Well, the reason are the linux calling conventions:
Not sure if it makes any difference, but I was testing under 64-bit
FreeBSD. I believe on the Lazarus Forum, some folk were using Linux and
some on Windows.
Over the weekend I’ll verify by testi
Am 18.05.2017 um 16:00 schrieb Ryan Joseph:
>
>> On May 18, 2017, at 8:53 PM, Michael Van Canneyt
>> wrote:
>>
>> The complaint of Graeme was that a FPC ray tracer is much slower slower than
>> an equivalent
>> raytracer in Java. All the rest are diversions from the original subject.
>
> That
On 2017-05-18 14:45, nore...@z505.com wrote:
When I toyed around with Andorra3D it had some concept/code for a
Camera, but he may have added it with his own code
He must have done it himself. Reimar is correct, OpenGL doesn't have a
Camera object/view. But in tutorials and texts they often use
On Thu, 18 May 2017 17:07:47 +0200 (CEST)
Michael Van Canneyt wrote:
> Giving people advice that they should use perl instead of FPC for math is
> simply insulting.
But Python is ok?
Btw. everyone knows that you do your math in C if you do Python or Perl.
R.
___
In our previous episode, Graeme Geldenhuys said:
> > I was extremely curious to see if those calls to Floor() were causing it.
>
> From memory, I remember trying replacing Floor() with Frac() and even
> Trunc(), and neither made any difference in the speed.
>
> So I don't believe it is simply d
On Thu, 18 May 2017 08:40:43 -0700
Jon Foster wrote:
> I limited run time to 10secs, and used "time" to verify actual run time.
> Here are the results, time output listed first and the first section of the
> gprof output without comments:
A little of topic but did gprof just work like it used t
On 2017-05-18 15:28, Ryan Joseph wrote:
I was extremely curious to see if those calls to Floor() were causing it.
From memory, I remember trying replacing Floor() with Frac() and even
Trunc(), and neither made any difference in the speed.
So I don't believe it is simply down to the Floor() u
Ryan Joseph wrote
>> On May 18, 2017, at 9:19 PM, Reimar Grabowski <
> reimgrab@
> > wrote:
>>
>> By getting the source of Graemes test, using a profiler on it and having
>> a look at the results?
>
> I tried (had to change the code to support SDL 2 even) but gave up after
> it crashed on one l
On Thu, 18 May 2017 17:06:39 +0200 (CEST)
Michael Van Canneyt wrote:
> And here I was thinking that math is what computers are for... :/
Back in the day, yes.
But nowadays computers do strings.
R.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal
In our previous episode, Ryan Joseph said:
> > No, they should not.
> > It's no real world problem, just a test program. A real game would be done
> > differently and then FPC is fast.
>
> Asking honestly, so you don?t think there?s anything troubling about a 8
> fps vs 40 fps from the same code?
On 05/18/2017 07:19 AM, Reimar Grabowski wrote:
On Thu, 18 May 2017 20:32:57 +0700
Ryan Joseph wrote:
On May 18, 2017, at 8:23 PM, Graeme Geldenhuys
wrote:
The compiler must be doing something really stupid for it mess up like that but
how can we know?
By getting the source of Graemes te
On Thu, 18 May 2017 22:04:19 +0700
Ryan Joseph wrote:
> > On May 18, 2017, at 9:58 PM, Reimar Grabowski wrote:
> >
> > No, they should not.
> > It's no real world problem, just a test program. A real game would be done
> > differently and then FPC is fast.
>
> Asking honestly, so you don’t
On 2017-05-18 16:25, Ryan Joseph wrote:
Please do and keep us informed if you don’t mind.
No problems, will do.
Regards,
Graeme
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pa
> On May 18, 2017, at 10:05 PM, Graeme Geldenhuys
> wrote:
>
> ps:
> I might have a few days free soon (between jobs), then I might dig more into
> this problem. Seeing that everybody is so keen to know.
Please do and keep us informed if you don’t mind. On Mac with ppcx64 the
program crashe
On 2017-05-18 16:04, Ryan Joseph wrote:
After I looked at the code I didn't see anything strange about it
Thank you, that's what I thought too.
it just got me thinking, if that code can be that slow how slow is
all the stuff I’m writing on a daily basis? It’s just worrying that’s
all.
+1
Th
On Thu, 18 May 2017, Graeme Geldenhuys wrote:
On 2017-05-18 15:58, Reimar Grabowski wrote:
A real game would be done differently and then FPC is fast.
Oh, so work around the FPC problem. I get it now. ;-)
Wanne do PacMan in 160x100 resolution, no problem for FPC.
Check.
Wanne do som
On Thu, 18 May 2017, Reimar Grabowski wrote:
On Thu, 18 May 2017 21:00:48 +0700
Ryan Joseph wrote:
That’s right. I’d really like to know what the hell FPC is doing to make it so
slow (besides the call to Floor()). The compiler team should be worried about
this also I would think.
No, th
On 2017-05-18 15:58, Reimar Grabowski wrote:
A real game would be done differently and then FPC is fast.
Oh, so work around the FPC problem. I get it now. ;-)
Wanne do PacMan in 160x100 resolution, no problem for FPC.
Check.
Wanne do something more modern...
Use Java instead. ;-) Chec
> On May 18, 2017, at 9:58 PM, Reimar Grabowski wrote:
>
> No, they should not.
> It's no real world problem, just a test program. A real game would be done
> differently and then FPC is fast.
Asking honestly, so you don’t think there’s anything troubling about a 8 fps vs
40 fps from the same
> On May 18, 2017, at 9:19 PM, Reimar Grabowski wrote:
>
> By getting the source of Graemes test, using a profiler on it and having a
> look at the results?
I tried (had to change the code to support SDL 2 even) but gave up after it
crashed on one line. Graeme suggested a staggering differenc
On Thu, 18 May 2017 21:00:48 +0700
Ryan Joseph wrote:
> That’s right. I’d really like to know what the hell FPC is doing to make it
> so slow (besides the call to Floor()). The compiler team should be worried
> about this also I would think.
No, they should not.
It's no real world problem, jus
On Thu, 18 May 2017 15:53:46 +0200 (CEST)
Michael Van Canneyt wrote:
> Yes, it was.
Don't tell me which mail I replied to, that's just rude.
> The complaint of Graeme was that a FPC ray tracer is much slower slower than
> an
> equivalent raytracer in Java. All the rest are diversions from the
On 2017-05-18 08:23, Graeme Geldenhuys wrote:
On 2017-05-18 13:42, Reimar Grabowski wrote:
The GPU also does clipping calculations
based on the viewpoint (camera position) in the 3D scene.
Camera position?
OpenGL has no concept of a camera.
Yes, yes, but you know what I mean. Camera, View Poi
> On May 18, 2017, at 8:53 PM, Michael Van Canneyt
> wrote:
>
> The complaint of Graeme was that a FPC ray tracer is much slower slower than
> an equivalent raytracer in Java. All the rest are diversions from the
> original subject.
That’s right. I’d really like to know what the hell FPC is
On Thu, 18 May 2017 08:45:59 -0500
nore...@z505.com wrote:
> On 2017-05-18 07:42, Reimar Grabowski wrote:
> > Camera position?
> > OpenGL has no concept of a camera.
>
> When I toyed around with Andorra3D it had some concept/code for a
> Camera, but he may have added it with his own code, not
1 - 100 of 193 matches
Mail list logo
