Re: [MSEide-MSEgui-talk] To Martin family.
I want to offer my sincerest condolences to Martin's family, friends, associates and anyone else who knew him. May GOD grant you peace in this time of darkness. I admired Martin and will miss our discussions. 2018 was a foul year. Sorrowfully, Jon On 12/26/2018 11:36 AM, fredvs wrote: > Martin was my best developer friend. > > His generosity and intelligence is legendary. > > We will miss him immensely. > > I am totally destroyed. > > Fre;D > > > > > -- > Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ > > > ___ > mseide-msegui-talk mailing list > mseide-msegui-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- Sent from my Debian Linux laptop -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com 541-410-2760 Making computers work for you! -- Sent from my Debian Linux laptop -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com 541-410-2760 Making computers work for you! ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On 05/24/2017 01:27 PM, Fred van Stappen wrote: > So LLVM does something like what Java's compiler does. The kernel of FreeBSD is made by LLVM-clang compiler. (Even if the script to build the kernel needs 8 different compilers ! (that are in fact copy the same clang compiler with 8 different names !). Apple traded out GCC for CLang / LLVM some time ago. The only downside I've heard about LLVM is that its slow. Like GCC & friends weren't. But I think a lot GCC slowness is inherited from binutils and that's probably the same for CLang/LLVM. That's one of the reasons that FPC has been struggling to build internal replacements for the binutils suite. Still have to use binutils on many platforms. -- Sent from my Debian Linux workstation -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On 05/24/2017 10:51 AM, Martin Schreiber wrote:
> On Wednesday 24 May 2017 18:58:40 Graeme Geldenhuys wrote:
>> On 2017-05-24 17:52, Martin Schreiber wrote:
>>> which will be optimized ("opt") and compiled to machine code ("llc") or
>>> runned by a just in time compiler or interpreter ("lli").
>> So LLVM does something like what Java's compiler does. I know nothing
>> about LLVM. :)
>>
> There is also a Java Script backend for LLVM (LLVM bitcode -> Java Script).
>
The LLVM project looked very interesting. I've had an eye on it for a
while. I was looking to implement my own language too. :-D
--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about
Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com
541-410-2760
Making computers work for you!
--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about
Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On 05/24/2017 06:32 AM, Graeme Geldenhuys wrote: > On 2017-05-24 14:15, Martin Schreiber wrote: > Bottom line FPC sucks for game development - unless you offload > pretty much everything onto a GPU - something I was hoping wouldn't be > needed for that project. > > FPC's saving grace is that most applications seem to be console, web or > desktop apps, so those inefficient binaries go unnoticed. Actually all you've done is proven that floating point is slow. FPC produces some pretty good code. I can still parse the entirety of the fpGUI "src" tree and build a fully completed model of the class hierarchy faster than the blink of an eye. All on my aging core 2 2GHz. In fact it happens so fast I have to go look to see if the tree was built, because otherwise I'm under the impression nothing happened. So its saving grace is that it does most everything else well. There is always room for improvement. -- Sent from my Debian Linux workstation -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On 05/24/2017 07:31 AM, Martin Schreiber wrote: > On Wednesday 24 May 2017 15:15:15 Martin Schreiber wrote: >> On Wednesday 24 May 2017 07:47:09 Martin Schreiber wrote: >>>> So what's MSElang's frame rate and on what kind of machine/OS? >>> Not ready yet. >> Linux 32 bit >> Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz >> >> With round() operations >> https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mcte >> st/mctest.pas >> >> FPC 3.0.2 >> -O- -> 8 FPS >> -O4 -CfSSE3 -CpCOREI -> access violation >> -O3 -CfSSE3 -CpCOREI -> access violation > -O1 -CpCOREI -CfSSE3 -> 12.5 FPS > Interesting! Only a 25% increase between your 3.2GHz and my 1.9GHz CPUs. -- Sent from my Debian Linux workstation -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com 541-410-2760 Making computers work for you! -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On 05/24/2017 06:15 AM, Martin Schreiber wrote: > On Wednesday 24 May 2017 07:47:09 Martin Schreiber wrote: > >>> So what's MSElang's frame rate and on what kind of machine/OS? >> Not ready yet. >> > Linux 32 bit > Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz > > With round() operations > https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest.pas > > FPC 3.0.2 > -O- -> 8 FPS > -O4 -CfSSE3 -CpCOREI -> access violation > -O3 -CfSSE3 -CpCOREI -> access violation > -O4 -CpCOREI -> 8.2 FPS > > 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.pas > -O3 -> 8.1 > -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 41.5 FPS ROCK ON! Since a server crash got me up *WAY* early this morning I ended up with an hour of extra time so I went over Jonas' suggestions again. I made tweaks fixing integer types, using trunc() instead of round, ... The over all improvement is only +0.6%, as I predicted nowhere near the 10x+ needed to compete with the other languages. I'd also like to point out that most of these things deal with internals in the compiler, which is what the initial complaint was. I also tried the SSE3 flag, which for a brief period of time brought me up to 10fps on my 1.9GHz i3 notebook. That is just under a 3x improvement. But then it segfaulted. As Jonas pointed out -O1 is about as far as you can take it with -CfSSE3 due to bugs in FPC. Also Jonas pointed out that they don't have a floor() with a float output. Indeed I could not find any rounding mechanism, in the docs, that produced a float output. So tried substituting -frac(). It was actually marginally slower. :-) His item #4 about the time base is my doing. It was the method I substituted for the the SDL_GetTicks() time source, which is probably much faster than FPC's time(). I'm sure there is a much better system call for that. But the short of it is that its only happening once per render and its total contribution to the performance deficit is inconsequential. Your machine is closer to what Graeme's is/was than mine is and that 41.5FPS is *SWEET*! THX - Jon -- Sent from my Debian Linux laptop Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On 05/07/2017 03:05 AM, Graeme Geldenhuys wrote: > On 2017-05-07 08:20, Martin Schreiber wrote: >> MSElang has been designed as a high performance language so it can't be so >> simple. > Huh? Java is an excellent performance language. Please ignore all statements > on the Internet older than say 5 years. The Java language has come a long > way, and > is *very* fast now. In fact, it actually generates binary code that is > magnitudes faster than what FPC can achieve. I've recently proved this in > the Lazarus Forum, and no amounts of "tweaks" or obscure coding methods in > Object Pascal or FPC compiler options could come close to the performance I > saw in Java 8. Hey Martin! Although Graeme fails to take into account the platforms where Java is interpreted and its many other stupidities he does have a good test case. I think I stirred up to the pot on the FPC mail list as best as I can and using Graeme's code proved that FPC has a *HUGE* weakness in the floating point arena. And actually my Delphi compiler for Linux (Kylix v3) didn't do much better. Seems to me I remember that being the case from my Delphi windoze days too. Fortunately I avoid floating-point math and typically don't need it. And in the cases where I do... actually the only fractional values I have dealt with in a long time is money and I use the currency type which doesn't really count. :-) IEEE floating-point is hideous for that. If MSElang is far enough along it would be interesting to see what it can do with with Graeme's ray-caster. I've dumbed it down to <300 lines and removed the external SDL dependency so it can be run as a raw computational benchmark. If you have the time to perform a translation and want to give it a whirl the reduced code is at https://github.com/jafcobend/fpcflop in the "mctest.pas" Although many on the FPC mailing list seem content to come up with excuses or blame Graeme for poor design it seems to me the real questions is: Why is x/y, when both are declared as singles, so much slower in FPC then it is in language X. So I'd really like to see how MSElang scores in this arena. I've been contemplating some game scenarios and I've been keeping my eye out for an improved language. Maybe I should get on board with MSElang. Anyhow, if you take on the challenge please CC my email address below. I'm going to try and avoid the mail lists and newsgroups for a while. I need to go earn a living and these things have soaked up a ton of time. :-D - Jon -- Sent from my Debian Linux laptop Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On 04/22/2017 03:18 AM, Martin Schreiber wrote: > On Saturday 22 April 2017 11:48:46 Graeme Geldenhuys wrote: >> On 2017-04-22 10:37, Graeme Geldenhuys wrote: >>> for the life of me I can't find that post. >> Saying that, I did track down the Delphi blog post that sparked the >> conversation on Google+ I'm looking for. >> >> https://web.archive.org/web/20170217114422/http://blog.marcocantu.com/blog/ >> 2017-february-delphi-linux-compiler.html >> > MSElang/MSEpas does not use basic datatypes with variable size. MSEpas has > int8, int16, int32, int64, card8, card16, card32 and card64 which can be > mapped to the traditional pascal type names as you like. > > Martin Considering how many different architectures out there it is probably a wise choice to name types by size. I would. :-) Or maybe just two generic names followed by a bit size modifier like with C structures. That way you could use a 4 bit unsigned int where ever it might be convenient... not just in structures. The developer could "type" them too for type safety (type nibble = unsigned:4;). However when I started with Delphi v1 & 2 (came as a bundle) you had size specific types like "Longint" and "ShortInt" and then the generic types like "integer" were mapped to the architecture /convenient/ types: * Delphi 1 (16bit Win3x compiler) integer was 16bit signed (ShortInt). * Delphi 2 integer was a signed 32 bit int (LongInt). This was pretty much the norm for most compilers during the 16/32 bit transition. I still think its a good idea to have a type that shifts size based on architecture, for things like for loops you want to use the most machine efficient and its likely that the hardware is going to use a native size register regardless of whether you want less or not. Seems FPC lost site of this feature. I was surprised to read integer is always 32bit. I expected it to be Int64 on 64bit platforms. And as you say, one could ifdef/type a platform convenient type if they so chose. But its nice if the compiler does that for you. -- Sent from my Debian Linux laptop -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com 541-410-2760 Making computers work for you! -- Sent from my Debian Linux laptop -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com 541-410-2760 Making computers work for you! -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang bechmark
On 04/21/2017 07:52 AM, Martin Schreiber wrote: > Hi, > > The attached program on Linux-x86: > MSElang with LLVM 3.8.0 -O3 > > time ./test1.bin > > real0m2.582s > user0m2.467s > sys 0m0.111s > Binary size 18088 bytes after strip. > > FPC 3.0.3 -O3: > > time ./test1_fpc > > real0m4.074s > user0m3.955s > sys 0m0.119s > Binary size 177576 bytes after strip. > > Looks good! :-) > > Martin > Now you're catching my attention... However when I compile test1.pas with fpc v3.0.0-3 the finished size is only 26,004 bytes. I don't think you used smart linking. Still it looks impressive. Does your binary require libc? FPC exes don't require any libs so they pack a bit more in the run time, rather than linking with libc. -- Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
[MSEide-MSEgui-talk] Out of date download page
So how come the downloads page on www.msegui.com is still touting v3.8.0? -- Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Bugs I mentioned in fgGUI Android thread
On 04/04/2017 11:39 AM, Martin Schreiber wrote: > On Tuesday 04 April 2017 17:12:37 Jon Foster wrote: >> Martin, >> >> Per your request in the discussion we were having in the fpGUI news groups >> about the "need" for form files and streaming form layouts I will detail >> what I remember of my trial runs of recent MSEgui versions. I used 4.4 >> (4.4.1 I think) and 3.8.8. 4.4.x worked better in the visuals department. >> The problems I ran into fall roughly in three categories: > [...] > > Which operating system/window manager? > Can you try again with current git master version: > https://gitlab.com/mseide-msegui/mseide-msegui/tree/master > so we can sort out the problems? > Please compile MSEide in clone-directory with > fpc -Fulib/common/* -Fulib/common/kernel/linux apps/ide/mseide.pas OK, I cloned the git repo and compiled MSEide. Almost all of the problems persist. Still too numerous for me to do much with it. My current desktop setup and the one I've been using for years: Debian 7 i386. Enlightenment 0.16.x (aka E16-1.0.0). Intel Core 2 x 4 @3GHz. Using Xorg 1.12.4 with ATI video card & 2 monitors. Looks like it is using the Xorg supplied ATI Radeon driver, with RandR and such. Also have an Intel based notebook in basically the same configuration... except its using the "fbdev" video driver instead of Intel's since it was too buggy. The hardware is too new for the driver. >> 1. Z-Ordering problems: Forms falling / rising unexpectedly. The worst >> [...] > Maybe a window manager with buggy NET_RESTACK_WINDOW protocol handling. > Starting MSEgui applications with --NORESTACKWINDOW activates a workaround, > see README.TXT. > >> 2. Form content disappearing. Particularly with the 3.x version using the >> [...] > That looks similar like an effect of a buggy RADEON driver > https://bugs.freedesktop.org/show_bug.cgi?id=69543 > https://bugs.freedesktop.org/show_bug.cgi?id=84253 > Switching off EXAPIXMAPS helps, see README.TXT. Fascinating this appears to be the case. The fbdev driver on the notebook does not have this issue. Things sure seem to have gone downhill since Xorg took over for Xfree86. Assuming your also correct about WM issues with #1 above I still have to say that all of the other software on my system is running without these issues. I'm not going to invest any more time into this ... unless I can find the time to get the current Enlightenment going. Everything is too fine tuned to disrupt. > >> 3. Won't connect to MySQL: In 3.x I'd get an "Access Violation" after >> setting the properties and then setting the "connected" property to true. >> [...] > That should already been fixed. > http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/msg10791.html > A heavy regression, sorry. This is fixed in "master". > [...] THX! -- Jon Foster JF Possibilities, Inc. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
[MSEide-MSEgui-talk] Command line build of IDE and class lib?
Is there a simple way to perform a build of MSEide MSEgui from the command line, without an existing IDE? THX - Jon -- Sent from my Debian Linux workstation -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com 541-410-2760 Making computers work for you! -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
