Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dariusz Piatkowski

Pages: [1] 2 3 ... 74
1
Applications / Re: Apache Open Office 4.1.8 Crash
« on: May 08, 2022, 02:32:40 pm »
Hi Doug!

Quote
I went down this path, deployed 4.1.11 with all the appropriate pre-requisite RPM package updates....only to find out that 4.1.11 turned out to be abysmally slow openning up any of my spreadsheets, as well as few other documents.

Personally, I think 4.1.11 opens spredsheets (and other things) faster than the older versions. Use Appache OpenOffice Quick Start, with the "-calc" (and others as needed) parameter, in a startup folder, and it will open quickly...

All excellent pointers on what I would have to agee defines the pre-requisites for most optimal setup. I did actually do all of the above (normally my AOO is configured to LH), I do not use the 'Quick Start' functionality, but in this case I gave it a go just to be sure.

In my testing I went through multiple configurations, clean re-boot (to baseline the DLL loads, etc.) and literally noted the timing in both cases: 1) open an existing spreadsheet, 2) open just the app (Calc). 4.1.11 was literally 3x slower in all instances. The weird part was that my CPU meter would show on-going multiple spikes during the load, sort of like what I used to occasinally see with FF after several days of use and massive memory consumption (typically over 1G), but this would occur on a freshly re-booted machine, with literally gobs of free memory available.

Anyways, it'll be 4.1.7 here until the next version is released and I'll give that a go.

2
Applications / Re: Apache Open Office 4.1.8 Crash
« on: May 07, 2022, 03:17:47 am »
"Buyer beware" though...

Quote
Or is there an easier way?

Yeah. Get AOO 4.1.11, and update it properly. If you ever paid for AOO (you must have, since you have 4.1.8), you are entitled to updates. You probably need to rattle BWW's chain to get it though, or be nice, and donate (pay) for it again.

I went down this path, deployed 4.1.11 with all the appropriate pre-requisite RPM package updates....only to find out that 4.1.11 turned out to be abysmally slow openning up any of my spreadsheets, as well as few other documents.

We are talking 3x as long as the previous 4.1.7 version at least. So I went back to 4.1.7 as I have far too many spreadsheets that I open up for a few minutes at a time only and the wait was simply bothering me too much! (spoiled...??? LOL..maybe)

3
This is a purely academic example, but you could use such an architecture to build a better Machine Learning model, here is why:

1) to some extent this depends on the ML architecture you want to use, but vast majority of computing and memory access is LOCAL, that means each one of the machines has the full MEM<=>CPU bus available to a smaller sub-set of the overall ML model, therefore the computations run faster

2) of course the coding required to do this - if you are starting from scratch - would require you to use some kind of parallel computing APIs, not sure to what extent the existing ML libraries (Python based stuff like Tensor, etc.) are capable of scaling up like this

This would work very nicely...way back I built such a ML model that did edge recognition in an image, and the follow-up was speaker recognition based on normalized (GSM compression) audio feed. This was not a sophisticated archtecture, basically several layers of varying sized networks, all using straight-forward backpropagation learning...needless to say, the final error (GLOBAL) minima took a while to get to. I would routinely train the darn thing for 2-3 days only to discover that my model was getting stuck in a LOCAL minima.

That was a C++ code, my undergrad thesis and let's just say we are talking here the mid-90's (LOL...damn, that flew by).

Anyways, if I needed to build that now, a parallel architecture like what you are describing would be more scalable. Of course you'd be hard pressed to beat a fast GPU, which can sit in a single machine where the CPU off-loads majority of the computation over to the GPU and uses it's local memory anyways...like I said, purely academic, but oh so fun to consider!!!

4
Internet / Re: New Browser Delay Discussion
« on: April 17, 2022, 03:04:21 am »
Paul, Dmitriy, everyone...

Glad to hear you made it out of Russia and that you're safe....

I cannot overemphasize the importance of this...glad to hear you are OK, things may be a little rough today (believe me, this comes from someone that was a refugee for about 2 yrs. of his life, albeit in a different non-war type of a settings), but with time stability will come as well!

...The fundamental issue is the lack of transparency.  Why not be clear  where things stand? If you read Roderick's post, the browser has been coming in a few weeks for what seems like years  now.  Your post actually sets out some of the technical limitations blocking progress...

Paul hit the proverbial nail on the head with the above statement. The status reporting, the communications, etc. always feel like it's nearly a 3rd or 4th hand message (forget even the regular "2nd hand" moniker). So at least from my perspective, having previously had the pleasure of participating in the Firefox Testing List where I got the chance to see the activities first-hand, there appears to be a giant gap in what's actually taking place "on the ground" and where the plans being communicated suggest things should be.

Dmitriy,
Your post here is, as best as I can tell, the only concise and clear Status Update on where the browser project is today and what the real challenges are.

At this point in time you have far too important matters to take care of than things such as OS/2 projects, especially given the lack of funding that would facilitate your continued employment.

Take care of yourself and don't hesitate to reach out if things get bad!

5
Internet / Re: New Browser Delay Discussion
« on: April 15, 2022, 03:36:53 pm »
First thing first: Congratulations Mentore!!!

Not a bad idea, just a little cumbersome maybe? Dunno. Maybe it's just me and my somehow schizofrenic way of seeing things: from one side, I'm thinking about building a linux eeePC nettop cluster solution just for fun (I've got six of these little boxes), from the other side I'm still attached to a one-box solution. I'm getting old, it seems  ;D

But yes: it's really an interesting idea IMHO. Also, in the current environment shifting to 64 bit there's not much time left...

Like you, I have never been able to pull myself away from the sheer "natural" way that one can interact with the WPS. Yes, it sure has its ugly side, but all in all it still beats a slew of other options that are out there.

Today I rely on the very option I laid out to get me an up-to-date browser config w/o physically shifting to another machine. I do this only b/c I have a couple of other PCs on the home LAN (they are all Win boxes) so putting one of them to work serving my OS/2 needs only seemed fitting! lol

For those who do not have such an option, one of these micro hardware platforms is absolutely the way to go.

Look, I'm always hoping that we will have something native, but I'd rather not find myself barelling towards the wall at full speed. Instead I'd rather have the option to slam on the brakes and make a turn before the inevitable end comes.


6
Internet / Re: New Browser Delay Discussion
« on: April 15, 2022, 04:32:48 am »
Guys...I do not want to be seen as only pouring fuel on the fire, but I honestly think it behooves us to come up with another browser option if the OS/2 platform is to survive in ANY sort of form and/or shape. This is BTW coming from a guy who's been running OS/2 ONLY on bare metal all these years...so you bet your "you know what" that committment is here!

Anyways, I bring back my suggestion to completely off-load the browser chores to a tiny bare metal platform where you can convert the darn box into an App server.

Literally, these things come in the tiniest of formats, some actually will attach to the back of your monitor's VESA bracket/mount and all you basically need is a power cable running to it (most are WiFI based, of course you can run a CAT cable if you want/prefer). Cost here is a couple of hundred USD, wide range of power hardware available, so you can pick something up for as little as $75. It is that cheap b/c it has no powerful GPU, crazy amount of RAM, or big SDD.

Combine that with a RDP solution like FreeRDP and our problems are nearly solved.

Heck, I'b be much happier pouring more money into fixing the current FreeRDP memory leaks than putting that cash into a native browser build.

Further on, we could all probably figure out the best combo to configure for our needs, and such a standard build could become an "off the shelf" solution for our use. Yes, I do literally mean: we should build an App Server image and make that available so that anyone else who wants to stand one of these tiny platforms just orders the hardware, dumps the image on there and installs FreeRDP on his/her current OS/2 box.

As they say: just my 2-cents!

7
Programming / Re: i686 vs Pentium 4
« on: March 12, 2022, 06:25:42 pm »
Dave,

...The output of -Q --help=target is interesting too. Something like,
Code: [Select]
gcc -march=native -Q --help=target > march_native.txt
gcc -march=sandybridge -Q --help=target > march_sandybridge.txt
diff -u march_native.txt march_sandybridge.txt

Hmm...OK, this simple gcc call does NOT work on my machine...which perhaps implies I have something else wrong? lol

Here is what I get (I won't post the whole thing, but it's about 200 lines of the same repeated error message until the very end):

Code: [Select]
{standard input}: Assembler messages:
{standard input}:1: Error: no such instruction: `the following options are target specific:'
{standard input}:2: Error: junk at end of line, first unrecognized character is `-'
{standard input}:3: Error: junk at end of line, first unrecognized character is `-'
...
{standard input}:183: Error: no such instruction: `known assembler dialects (for use with the -masm=option):'
{standard input}:184: Error: no such instruction: `att intel'
{standard input}:186: Error: no such instruction: `known ABIs (for use with the -mabi=option):'
{standard input}:187: Error: no such instruction: `ms sysv'
{standard input}:189: Error: no such instruction: `known code models (for use with the -mcmodel=option):'
{standard input}:190: Error: junk at end of line, first unrecognized character is `3'
{standard input}:192: Error: no such instruction: `valid arguments to -mfpmath=:'
{standard input}:193: Error: junk at end of line, first unrecognized character is `3'
{standard input}:195: Error: no such instruction: `known indirect branch choices (for use with the -mindirect-branch=/-mfunction-return=options):'
{standard input}:196: Error: no such instruction: `keep thunk thunk-extern thunk-inline'
{standard input}:198: Error: no such instruction: `known choices for return instrumentation with -minstrument-return=:'
{standard input}:199: Error: junk `nop5' after expression
{standard input}:201: Error: no such instruction: `known data alignment choices (for use with the -malign-data=option):'
{standard input}:202: Error: no such instruction: `abi cacheline compat'
{standard input}:204: Error: no such instruction: `known vectorization library ABIs (for use with the -mveclibabi=option):'
{standard input}:205: Error: no such instruction: `acml svml'
{standard input}:207: Error: no such instruction: `known address mode (for use with the -maddress-mode=option):'
{standard input}:208: Error: no such instruction: `long short'
{standard input}:210: Error: no such instruction: `known preferred register vector length (to use with the -mprefer-vector-width=option):'
{standard input}:211: Error: junk at end of line, first unrecognized character is `1'
{standard input}:213: Error: no such instruction: `known stack protector guard (for use with the -mstack-protector-guard=option):'
{standard input}:214: Error: no such instruction: `global tls'
{standard input}:216: Error: no such instruction: `valid arguments to -mstringop-strategy=:'
{standard input}:217: Error: no such instruction: `byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop'
{standard input}:218: Error: no such instruction: `vector_loop'
{standard input}:220: Error: no such instruction: `known TLS dialects (for use with the -mtls-dialect=option):'
{standard input}:221: Error: no such instruction: `gnu gnu2'
{standard input}:223: Error: no such instruction: `known valid arguments for -march=option:'
{standard input}:224: Error: no such instruction: `i386 i486 i586 pentium lakemont pentium-mmx winchip-c6 winchip2 c3 samuel-2 c3-2 nehemiah c7 esther i686 pentiumpro pentium2 pentium3 pentium3m pentium-m pentium4 pentium4m prescott nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel geode k6 k6-2 k6-3 athlon athlon-tbird athlon-4 athlon-xp athlon-mp x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 btver1 btver2 generic native'
{standard input}:226: Error: no such instruction: `known valid arguments for -mtune=option:'
{standard input}:227: Error: no such instruction: `generic i386 i486 pentium lakemont pentiumpro pentium4 nocona core2 nehalem sandybridge haswell bonnell silvermont goldmont goldmont-plus tremont knl knm skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake intel geode k6 athlon k8 amdfam10 bdver1 bdver2 bdver3 bdver4 btver1 btver2 znver1 znver2'

At first I thought maybe this was a session related thing...so I even tried bash, but same result.

Any idea what my gcc is choking on here???

8
Programming / Re: i686 vs Pentium 4
« on: March 10, 2022, 03:13:31 pm »
I hit the GCC bug forum in an attempt to find any known issues with mtune optimization logic for the amdfma10 processors. While nothing obvious jumped out, I did do some pretty extensive reading on a couple of general "optimization logic" bug threads:

1) Bug 81616 - Update -mtune=generic for the current Intel and AMD processors  (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616)

2) GCC buglist with "amdfam10" filter (https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=amdfam10)

Also came across this decent post on the relationship between march and mtune => https://lemire.me/blog/2018/07/25/it-is-more-complicated-than-i-thought-mtune-march-in-gcc/, great info in the discussion section actually.

So here is the kicker, it would appear (juding by the performance tests these teams were running) that best performance results were obtained when using the mtune=K8 option on the amdfam10 architecture. Hmm....strange I thought, b/c K8 is an older architecture and the Phenom (in my case) really did not introduce new features, other than basically an updated memory controller and L3 cache (more than doubled – from 2MB to 6MB). Not sure if there are any actual instrution set differences.

Anyways, alright, so I'm already trying this out, why not give this new combo a whirl?

Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 18130
Total time (secs): 18.130000
Iterations/Sec   : 99282.956426
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=k8 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 99282.956426 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=k8 -DPERFORMANCE_RUN=1  -lpthread / Heap / 6:PThreads

Wow...so that's a pretty significant difference: 99282.956426 (mtune=k8) vs 84811.647466 (no mtune).

The differences narrow down significantly when looking at tuned results: 99282.956426 (mtune=k8) vs 98231.827112 (mtune=generic).

9
Programming / Re: i686 vs Pentium 4
« on: March 09, 2022, 08:27:54 pm »
Try with only -march=amdfam10 as the -mtune=amdfam10 is redundant and might be the problem, -mtune is implied to be the same as -march if it is not stated.
Also try -march=native.

1) amdfam10
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14149
Total time (secs): 14.149000
Iterations/Sec   : 84811.647466
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 84811.647466 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -DPERFORMANCE_RUN=1  -lpthread / Heap / 6:PThreads

2) pentium4
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14515
Total time (secs): 14.515000
Iterations/Sec   : 82673.096796
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 82673.096796 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -DPERFORMANCE_RUN=1  -lpthread / Heap / 6:PThreads

3) native
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 15119
Total time (secs): 15.119000
Iterations/Sec   : 79370.328725
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=native -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 79370.328725 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=native -DPERFORMANCE_RUN=1  -lpthread / Heap / 6:PThreads

Looks to me like -mtune is still doing something...

10
Programming / Re: i686 vs Pentium 4
« on: March 09, 2022, 04:31:58 pm »
Hi Dave!

That is strange, is it repeatable?

Hmm, maybe the approach I took to implementing the various -march and -mtune settings was incorrect: I included those in the main makefile as part of the CFLAGS line.

So now I've re-ran, having cleaned-up the CFLAGS and used the CLI make call with the XCFLAGS instead.

1) AMD optimized
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14098
Total time (secs): 14.098000
Iterations/Sec   : 85118.456519
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=amdfam10 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

...crc stuff SNIPPED...

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 85118.456519 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=amdfam10 -DPERFORMANCE_RUN=1  -lpthread / Heap / 6:PThreads

2) AMD generic
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 18324
Total time (secs): 18.324000
Iterations/Sec   : 98231.827112
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=generic -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

...crc stuff SNIPPED...

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 98231.827112 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=amdfam10 -mtune=generic -DPERFORMANCE_RUN=1  -lpthread / Heap / 6:PThreads

3) PENTIUM4 optimized
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 14391
Total time (secs): 14.391000
Iterations/Sec   : 83385.449239
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -mtune=pentium4 -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

...crc stuff SNIPPED...

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 83385.449239 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -mtune=pentium4 -DPERFORMANCE_RUN=1  -lpthread / Heap / 6:PThreads

4) PENTIUM4 generic
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 19648
Total time (secs): 19.648000
Iterations/Sec   : 91612.377850
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -mtune=generic -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

...crc stuff SNIPPED...

Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 91612.377850 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -march=pentium4 -mtune=generic -DPERFORMANCE_RUN=1  -lpthread / Heap / 6:PThreads

In both architecture cases, the "generic" option produces a better results as compared to CPU specific tune, this is not a good outcome, as you said, maybe a compiler bug?

On my AMD CPU, the AMD -march gives a better result than P4 (which is to be expected).

11
Programming / Re: i686 vs Pentium 4
« on: March 09, 2022, 04:37:16 am »
I'll play around with the different optimization flags Dave which you discussed in your post next...

Hmm...so a bit of a surprise actually, I did not anticipate this.

1) tune & arch = amdfam10
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 13914
Total time (secs): 13.914000
Iterations/Sec   : 57496.047147
Iterations       : 800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 4

2) arch=amdfam10, tune=generic
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 17822
Total time (secs): 17.822000
Iterations/Sec   : 67332.510380
Iterations       : 1200000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 4

3) same config as #2 above, but running the full 6 cores
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 21224
Total time (secs): 21.224000
Iterations/Sec   : 84809.649453
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

4) same #3 above, but with arch=pentium4, tune=generic
Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 21252
Total time (secs): 21.252000
Iterations/Sec   : 84697.910785
Iterations       : 1800000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DMULTITHREAD=6 -DUSE_PTHREAD -DPERFORMANCE_RUN=1  -lpthread
Parallel PThreads : 6

The GCC architecture specific tune option produced WORSE performance than the GENERIC option, which at least to me is not intuitive, quite the opposit actually.

..and while I focused in the above tests on multi-threaded performance, the single-threaded runs matched the tune results that I saw here (same conclusion).

12
Programming / Re: i686 vs Pentium 4
« on: March 08, 2022, 02:04:27 pm »
Dave, everyone...

So anyways, my next idea is to benchmark the differences in optimizing for different CPU architectures. I found this, https://www.eembc.org/coremark/index.php a benchmark designed to test integer and pipeline speed on various CPU's see the Details part of the above page.
So I downloaded the source and built it and now share it, it is attached and includes the logs I generated...

Nice!!! Thank you...

Here are the results for my Phenom II X6 running at 3.8GHz:

Code: [Select]
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 17587
Total time (secs): 17.587000
Iterations/Sec   : 17058.054245
Iterations       : 300000
Compiler version : GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)
Compiler flags   : -O2 -DPERFORMANCE_RUN=1
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0xcc42
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 17058.054245 / GCC9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00) -O
2 -DPERFORMANCE_RUN=1   / Heap

I'll play around with the different optimization flags Dave which you discussed in your post next. Also, the above is a result when executed on my system in as-is state, so various CPU spikes, etc...not quieted by any means! lol

13
Programming / Re: i686 vs Pentium 4
« on: March 08, 2022, 03:22:50 am »
As I stated at the top, the conversation should be about the architecture, not the benefits/drawbacks of RPM, that ship has sailed. Our volunteers are comfortable with RPM and we get RPM and we do need a package manager, which Warpin is not...

Thanks Dave fore re-focusing this discussion on the main topic.

...The question is how to easily fix the performance hit from using Netburst on most anything that isn't on Netburst...

So what do we actually know, as opposed to believe, this performance penalty to be?

As you know I'm happily chugging away using my AMD Phenom II CPU, old tech by today's standards, but it does support some of the instructions that have the potential to improve system performance, that being: SSE, SSE2, SSE4a. So from that perspective I do not see anything wrong with the move towards pentium4 releases.

If anything, I wish we actually had a more real choice, that being CPU specific package builds, basically along the lines of what you did for me building my Phenom specific FF release. In that case, I did genuinely see an improved performance and could benchmark enough to actually put a real metric on the results.

14
Hmm...interesting because I have been using Thunderbird here with my Gmail account and had the 2-way authentication turned on quite some time ago.

Google does have a process in place (application password) that will allow you to define app-specific password that the application can authenticate with. Works quite fine with TB, I only wish the Google Contacts add-on would handle that...

Can't speak to PMMail, but I suppose that should apply as well given that you need to provide ID/PASS credentials there as well.

15
Hekki,

I can use my internet bank with Simple Browser. It is slow and crashes often, but it doesn't leak shared memory like FreeRDP.

Have you ever tried troublshooting that FreeRDP memory leak?

I have and I suspect due to lack of know-how wasn't able to produce real results. But yes, I do see this here and it's the only -ve to that approach.

Pages: [1] 2 3 ... 74