Discussion:
sm2.21b1 and tb24.8.1
(too old to reply)
Dave Yeo
2014-11-03 00:18:09 UTC
Permalink
I've uploaded new builds of SeaMonkey 2.21 and Thunderbird 24.8.1 to
hobbes. Based on the same code as the Bitwise release of Firefox 24.8.1
and have the same issues including lack of HTML 5 sound which I believe
was forgotten to be mentioned.
Issues should be checked with Firefox 24.8.1 to see if they are in the
Gecko code or not.
Thanks to Bitwise for their work on Firefox and help for me to compile.
Dave
Doug Bissett
2014-11-04 05:41:09 UTC
Permalink
Post by Dave Yeo
I've uploaded new builds of SeaMonkey 2.21 and Thunderbird 24.8.1 to
hobbes. Based on the same code as the Bitwise release of Firefox 24.8.1
and have the same issues including lack of HTML 5 sound which I believe
was forgotten to be mentioned.
Issues should be checked with Firefox 24.8.1 to see if they are in the
Gecko code or not.
Thanks to Bitwise for their work on Firefox and help for me to compile.
Dave
I uploaded WarpIn versions to HOBBES and netlabs.
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
A.D. Fundum
2014-11-04 12:42:37 UTC
Permalink
Post by Doug Bissett
I uploaded WarpIn versions to HOBBES and netlabs.
That version doesn't work, at least the SM-package, for one because it
doesn't add the intended installation directory to the list of
LIBPATH-directories, which is used to wrongly verify a perfectly
working system when the ZIP-file instead of the WPI-file is used. If
useless checks with errors instead of warning messages are that
important, then you really should add that directory to the list. Not
to the LIBPATH, slowing the whole system down, but to the list. IOW:
the "."-entry in a LIBPATH, using the right SEAMONKEY.EXE-directory
instead of some installation or installer directory.


--
Doug Bissett
2014-11-04 18:57:59 UTC
Permalink
Post by A.D. Fundum
Post by Doug Bissett
I uploaded WarpIn versions to HOBBES and netlabs.
That version doesn't work, at least the SM-package, for one because it
doesn't add the intended installation directory to the list of
LIBPATH-directories, which is used to wrongly verify a perfectly
working system when the ZIP-file instead of the WPI-file is used. If
useless checks with errors instead of warning messages are that
important, then you really should add that directory to the list. Not
the "."-entry in a LIBPATH, using the right SEAMONKEY.EXE-directory
instead of some installation or installer directory.
You do NOT need SM in the LIBPATH. You also should NOT put stuff into
the SM directory that is not installed by WarpIn. The script will
REMOVE any file that it does not install, or otherwise know about,
when the installer does it's job (that includes any DLL that you may
have incorrectly inserted there).

If you insist on playing games with DLLs, please use the ZIP file
install, because the WarpIn install is meant to help to do things
properly.
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
A.D. Fundum
2014-11-07 13:46:18 UTC
Permalink
Post by Dave Yeo
Issues should be checked with Firefox 24.8.1 to see if they are in
the Gecko code or not.
FWIW: I'm using SM2.14 again, because of such a generic, FF-releated
issue with (probably) scripts (CPU load 100%, crashes and/or "hidden"
messages w.r.t. scripts exceeding the adjusted dom.max_script_run_time
of 20 seconds). I also noticed that it now uses more than one process
id,and that you'll have to kill all procesess to try to end up with a
responsive system again.


--
Dave Yeo
2014-11-07 15:48:21 UTC
Permalink
Post by A.D. Fundum
Post by Dave Yeo
Issues should be checked with Firefox 24.8.1 to see if they are in
the Gecko code or not.
FWIW: I'm using SM2.14 again, because of such a generic, FF-releated
issue with (probably) scripts (CPU load 100%, crashes and/or "hidden"
messages w.r.t. scripts exceeding the adjusted dom.max_script_run_time
of 20 seconds). I also noticed that it now uses more than one process
id,and that you'll have to kill all procesess to try to end up with a
responsive system again.
Yes, one problem is that somehow the preference to turn off out of
process plugins vanished, my apologies.
Go to about:config and toggle dom.ipc.plugins.enabled to false.
Dave
A.D. Fundum
2014-11-10 23:49:14 UTC
Permalink
Post by Dave Yeo
Post by A.D. Fundum
CPU load 100%
Go to about:config and toggle dom.ipc.plugins.enabled to false.
Excellent. I'm still using 2.14, but I can confirm that this setting
solved that 2.21b1-problem.


--
Dariusz Piatkowski
2014-12-02 00:59:03 UTC
Permalink
Hi Dave!
Post by Dave Yeo
I've uploaded new builds of SeaMonkey 2.21 and Thunderbird 24.8.1 to
hobbes. Based on the same code as the Bitwise release of Firefox 24.8.1
and have the same issues including lack of HTML 5 sound which I believe
was forgotten to be mentioned.
Issues should be checked with Firefox 24.8.1 to see if they are in the
Gecko code or not.
Thanks to Bitwise for their work on Firefox and help for me to compile.
I'm curious: what is the difference between your release at the Bitwise stuff?

I tried theirs but hit a couple of issues with Firefox that made me go back...

Thanks!
A.D. Fundum
2014-12-02 11:37:44 UTC
Permalink
Post by Dariusz Piatkowski
I'm curious: what is the difference between your release at the Bitwise stuff?
Just by looking at the increased sizes of the files (FF, SM, TB), you
can tell that FF's browser code is shared (SM = FF + TB, or TB = mail
+ HTML-formatted mail).
Post by Dariusz Piatkowski
I tried theirs but hit a couple of issues with Firefox that
made me go back...
You can use both, FF and SM. The latest FF, just in case a website
requires it. If you like that FF version, then nowaydays you can
upgrade the matching SM as well. If SM would be better, it's likely
that he'll tell Bitwise how he improved FF-components because they are
working together, sharing code and complicated tools. If you don't
like a FF version, then it has no use to try the matching SM version.


--
Dave Yeo
2014-12-02 21:59:52 UTC
Permalink
Post by Dariusz Piatkowski
Hi Dave!
Post by Dave Yeo
I've uploaded new builds of SeaMonkey 2.21 and Thunderbird 24.8.1 to
hobbes. Based on the same code as the Bitwise release of Firefox 24.8.1
and have the same issues including lack of HTML 5 sound which I believe
was forgotten to be mentioned.
Issues should be checked with Firefox 24.8.1 to see if they are in the
Gecko code or not.
Thanks to Bitwise for their work on Firefox and help for me to compile.
I'm curious: what is the difference between your release at the Bitwise stuff?
I tried theirs but hit a couple of issues with Firefox that made me go back...
They both share the same Gecko code (Gecko is the actual engine
underlying all the browsers) and the same tool chain.
Most of the differences are in the UI code and I made next to no changes
to the stock code other then some build optimizations and minor things
like the icons and adding the FPU and exceptq exception code based on
the bitwise code.
I also used different optimizations, the bitwise code was targeted at
i486 with i686 tuning and probably the stock -O2 optimization and I
targeted the i686 with generic tuning (whatever the GCC developers
thought would be best for the common CPU's at release) and -O3
optimization. It's possible that the -O3 exposed compiler bugs but
things have been pretty stable for me.
I'd also recommend marking the DLL's to use high memory (needs the 106
kernel) which at least here helps a lot, currently 274.5 MBs free, but
still drops under some types of usage.
Dave
Dave Saville
2014-12-03 09:24:52 UTC
Permalink
Post by Dave Yeo
I'd also recommend marking the DLL's to use high memory (needs the 106
kernel) which at least here helps a lot, currently 274.5 MBs free, but
still drops under some types of usage.
How, and where is 106?

TIA
--
Regards
Dave Saville
Dave Yeo
2014-12-03 15:40:25 UTC
Permalink
Post by Dave Saville
Post by Dave Yeo
I'd also recommend marking the DLL's to use high memory (needs the 106
kernel) which at least here helps a lot, currently 274.5 MBs free, but
still drops under some types of usage.
How, and where is 106?
On the eCS 2.2b2 beta is where I got it.
Dave
A.D. Fundum
2014-12-03 11:37:40 UTC
Permalink
I targeted the i686 with generic tuning (whatever the GCC
developers thought would be best for the common CPU's
at release) and -O3 optimization. It's possible that the -O3
exposed compiler bugs but things have been pretty stable
for me.
The latest release appears to be stable without the earlier 100% CPU
load, but it still takes a lot of time to fully load a newspaper's
website (which is most likely overloaded with scripts, and has to be
reloaded to display the whole page anyway). Far too long. Hence a
downgrade to SM 2.14, it's a FF problem. It was the first website I
tried, it's not a knwon website to test browsers. I stopped trying
before I experienced any crash.

It's perhaps hard to notice the results of optimizations, but if it
works then there's no technical reason to not optimize indeed. FTR,
again: nobody will be excluded from using it, because you'll need the
memory capacity of i686+ generation CPUs anyway; it's hard to find a
i386/i486/i586 with enough installable RAM to actually use modern
FF/SM/TB normally.


--
Dave Yeo
2014-12-03 17:08:20 UTC
Permalink
Post by A.D. Fundum
I targeted the i686 with generic tuning (whatever the GCC
developers thought would be best for the common CPU's
at release) and -O3 optimization. It's possible that the -O3
exposed compiler bugs but things have been pretty stable
for me.
The latest release appears to be stable without the earlier 100% CPU
load, but it still takes a lot of time to fully load a newspaper's
website (which is most likely overloaded with scripts, and has to be
reloaded to display the whole page anyway). Far too long. Hence a
downgrade to SM 2.14, it's a FF problem. It was the first website I
tried, it's not a knwon website to test browsers. I stopped trying
before I experienced any crash.
I wonder if the site is serving up the same page to 2.14 and 2.21? I was
starting to find some sites complaining about 2.14 and IIRC some such as
github displayed somewhat differently.
Some sites are now optimizing for current and current -1 versions and
not supporting anything older.
Post by A.D. Fundum
It's perhaps hard to notice the results of optimizations, but if it
works then there's no technical reason to not optimize indeed. FTR,
again: nobody will be excluded from using it, because you'll need the
memory capacity of i686+ generation CPUs anyway; it's hard to find a
i386/i486/i586 with enough installable RAM to actually use modern
FF/SM/TB normally.
Optimizations can be weird. Generally better to use newer instructions
but there are some such as CMOV that is actually slower on some CPU's
such as the P4 plus our compilers are buggy when it comes to things like
SSE which demand alignment. Be nice to use SSE for floating point math.
The tuning usually helps, aligning instructions on 4 byte boundaries and
ordering the instructions to take advantage of pipe-lining but even
there P4s need quite a different order then most other CPU's so
basically we're optimizing for everything but P4's which I assume are
getting rare.
Then there is the trade off between more efficient code and the
possibility of cache misses. The code gets bigger with the 4 byte
alignment and occasionally unrolling a loop and such may mean more cache
misses. The newer the CPU, the less of a problem though.
Dave
A.D. Fundum
2014-12-07 23:16:25 UTC
Permalink
Post by Dave Yeo
I wonder if the site is serving up the same page to 2.14 and 2.21?
http://www.tijd.be/beurzen/CAC_NEXT_20.365011860 uses a banner script,
which uses this threshold: <div data-browser-name="ff"
data-browser-version="24.0"></div>

I just used 2.14 -> 2.0.3 (to import old Netscape mail) -> 2.14 ->
2.21, and deleted files in the media directory. Now 2.21 is about as
fast as both the FF beta and SM2.21. Perhaps an ad was the problem,
this is the 5th time it tried it by visiting the same site. So I'll
upgrade to 2.21 too. It looked like problems with scripts. Today the
FF beta was fast too.
Post by Dave Yeo
so basically we're optimizing for everything but P4's
which I assume are getting rare.
386: OS/2 museum, *_BUT_* it's my default because it matches the
requirements of the OS. So I don't have to mention any requirements,
and I don't have to explain to the last 386er that my HelloWorld.EXE
requires a 486, albeit that user won't notice any speed gain due to a
few optimized instructions.

486: OS/2 museum, DOS games (sound/CPU speed), old OS/2 software like
Cosmos/2 requiring older video drivers, testing purposes (e.g. Mozilla
fonts, in the past). A better default choice than a 386, *_BUT_*
you'll have to print on the box that a 486 is a silly requirement.

586/Pentium I: same as 486. Technically a better optimatization choice
than a 486, *_BUT_* you'll have the print the sily requirement on the
box again. You still don't expect that anything will work, but my
HelloWorld.EXE should work (why not?).

Pentium II: eCS' bottom line, enough memory to browse (if you really
have to, do forget e.g. animated GIFs and video), something you could
actually use to write a HelloWorld.EXE because typing and adding more
stupid bugs don't require a 6THz CPU. It's very likely that everybody
reading this isusing at least a PII and a modern (newer than Y2K)
version of OS/2. If so, then that user isn;'t using the main system.

Pentium III: best of both worlds, possibly support of DOS sound and
fast enough for basic daily use, including browsing and not watching
that many videos. Perhaps the bottom line of main systems.

Pentium IV: less DOS sound, more videos.

Newer than Pentium: IV: dunno, I cannot install my eCS 1.2.

So I think it's safe to say that anybody reading this (textmode or
GUI) is using at least a P6/Pentium II. If any, at least a Pentium III
is more likely. But if you're writing a newsgroup reader, then I'd
recommend to use the default optimization of the compiler.

For example, recently I distributed a clipboard utility without its
optimization for a 586, and I used my default choice of 386,
Requirements: same as OS, and I don't have to explain to some museum
that a simple utility requires a 586 because ... erm ....
Post by Dave Yeo
The newer the CPU, the less of a problem though.
FF (PII+)/SM(PII+)/video(PIII+) are special cases anyway, and perhaps
the power tools of programmers. The older the CPU, the more important
a gain of 1% is. Add at least a generation for daily use (FF/SM:
PIII+, video PIV+). Even WinXP will struggle with a faster PIII and
modern HD videos.

Finally DOS sound typically is not a good reason to keep using a
P4/P5. You'd better spend $10 to buy such and old beast to play your
games, and buy newer hardware for daily use. I actually use P6s, but
it's far more likely (>99%) that I'm using at least a Pentium III to
produce this text. Built-in WLAN will also play a role nowadays. My
oldest machines with added built-in WLAN are PIIIs, e.g. a T23 or a
X20. I'm not going to grab a cable and connector to try to be
interesting by using a P4/P5 to type this. E.g. testing yes, serious
production no. It's quite safe to assume the use of a PIII, but a 386
(always, or the default of your compiler) or a P6 (if needed) are
probably the technical bottom lines.


--
A.D. Fundum
2014-12-08 00:13:17 UTC
Permalink
Today the FF beta was fast too.
Oops. The website of the newspaper was fast, but now e.g.
http://www.bbc.co.uk (redirected to http://www.bbc.com) caused a 100%
CPU load, www.google-analytics.com in the bottom left corner, a
matching progress bar in the bottom right corner, and a silent crash
after a while.

FF beta, http://www.bbc.co.uk: stopped by me after several minutes of
100% CPU load, mainly "Busy loading ad.doubleclick.net..." or "Waiting
for ad.doubleclick.net...". IOW: about the same problem.

So back to 2.14 again. Too bad, it looked like some ad of the
newspaper could have been the problem.


--
ivan
2014-12-08 01:09:44 UTC
Permalink
Post by A.D. Fundum
Today the FF beta was fast too.
Oops. The website of the newspaper was fast, but now e.g.
http://www.bbc.co.uk (redirected to http://www.bbc.com) caused a 100%
CPU load, www.google-analytics.com in the bottom left corner, a
matching progress bar in the bottom right corner, and a silent crash
after a while.
FF beta, http://www.bbc.co.uk: stopped by me after several minutes of
100% CPU load, mainly "Busy loading ad.doubleclick.net..." or "Waiting
for ad.doubleclick.net...". IOW: about the same problem.
So back to 2.14 again. Too bad, it looked like some ad of the
newspaper could have been the problem.
--
Any particular reason for not using adblock plus and noscript addons?
They are standard on all our firefox browsers since they became
available.

ivan
--
A.D. Fundum
2014-12-08 11:04:05 UTC
Permalink
Post by ivan
Any particular reason for not using adblock plus and noscript
addons?
They are standard on all our firefox browsers since they
became available.
Good suggestions. I'll consider it, if needed. I was aware of adblock.

Regarding the possible issue of ads (or Facebook's plugin, or ...)
funding the provided free content, I'd like to point out that I
couldn't see the ads (crash) or I started hating the ads after having
to wait (I didn't, <ALT-F4>) several minutes to see any.


--
Dave Yeo
2014-12-08 03:53:30 UTC
Permalink
Post by A.D. Fundum
Today the FF beta was fast too.
Oops. The website of the newspaper was fast, but now e.g.
http://www.bbc.co.uk (redirected to http://www.bbc.com) caused a 100%
CPU load, www.google-analytics.com in the bottom left corner, a
matching progress bar in the bottom right corner, and a silent crash
after a while.
FF beta, http://www.bbc.co.uk: stopped by me after several minutes of
100% CPU load, mainly "Busy loading ad.doubleclick.net..." or "Waiting
for ad.doubleclick.net...". IOW: about the same problem.
So back to 2.14 again. Too bad, it looked like some ad of the
newspaper could have been the problem.
Do you have Flash installed? Have you changed the setting
dom.ipc.plugins.enabled to false in about:config? (I screwed up and
forgot to change the default and thought we'd have another release by now).
As Ivan says, there are add-ons to stop those obnoxious scripts (and
Flash), especially in ads. Personally I'm pretty happy using noscript
and ghostery but find that noscript is all I need here. Others really
like adblock+ but since I never see obnoxious ads, I never bothered to
install it.
Dave
Dave Yeo
2014-12-08 04:07:50 UTC
Permalink
Post by A.D. Fundum
Today the FF beta was fast too.
Oops. The website of the newspaper was fast, but now e.g.
http://www.bbc.co.uk (redirected to http://www.bbc.com) caused a 100%
CPU load, www.google-analytics.com in the bottom left corner, a
matching progress bar in the bottom right corner, and a silent crash
after a while.
FF beta, http://www.bbc.co.uk: stopped by me after several minutes of
100% CPU load, mainly "Busy loading ad.doubleclick.net..." or "Waiting
for ad.doubleclick.net...". IOW: about the same problem.
So back to 2.14 again. Too bad, it looked like some ad of the
newspaper could have been the problem.
Do you have Flash installed? Have you changed the setting
dom.ipc.plugins.enabled to false in about:config? (I screwed up and
forgot to change the default and thought we'd have another release by now).
As Ivan says, there are add-ons to stop those obnoxious scripts (and
Flash), especially in ads. Personally I'm pretty happy using noscript
and ghostery but find that noscript is all I need here. Others really
like adblock+ but since I never see obnoxious ads, I never bothered to
install it.
Dave
A.D. Fundum
2014-12-08 11:28:28 UTC
Permalink
Post by Dave Yeo
Post by A.D. Fundum
Oops. The website of the newspaper was fast
Do you have Flash installed?
Yes, an ancient flash7a63RW-release.
Post by Dave Yeo
Have you changed the setting dom.ipc.plugins.enabled
to false in about:config?
Oops/eCS. I'll try it again (no problem, if anything slow/"modern"
websites are the problem), albeit the FF beta was slow too. I assumed
(duh) that the settings were right, because the newspaper's site was
fast again, I used the latest uploaded version, and it works with
SM2.14 (so I'm not expecting some new miracle).
Post by Dave Yeo
Personally I'm pretty happy using noscript
I'll consider it. but first I'll try it with Flash (nice-to-have, but
outdated) and the right settings. I'm using the newspaper's website to
obtain data, and I can imagine that they've hidden the data behind
scripts. It's not pure HTML, because often I have to reload the page
to make its HISTORIEK-table appear (if needed I can use another data
source, the "open" of stock exchange indexes often is lower or higher
than the lowest or highest value, and it's a reliable data source).

Regarding ads and http://bbc.com, I can confirm that I wasn't looking
for big & black... ;-)


--
Dave Yeo
2014-12-08 16:13:58 UTC
Permalink
Post by A.D. Fundum
Post by Dave Yeo
Post by A.D. Fundum
Oops. The website of the newspaper was fast
Do you have Flash installed?
Yes, an ancient flash7a63RW-release.
Post by Dave Yeo
Have you changed the setting dom.ipc.plugins.enabled
to false in about:config?
Oops/eCS. I'll try it again (no problem, if anything slow/"modern"
websites are the problem), albeit the FF beta was slow too. I assumed
(duh) that the settings were right, because the newspaper's site was
fast again, I used the latest uploaded version, and it works with
SM2.14 (so I'm not expecting some new miracle).
SM2.14 has the oops setting correct and ads rotate so perhaps when the
newspapers site was fast, there was no flash.
Post by A.D. Fundum
Post by Dave Yeo
Personally I'm pretty happy using noscript
I'll consider it. but first I'll try it with Flash (nice-to-have, but
outdated) and the right settings. I'm using the newspaper's website to
obtain data, and I can imagine that they've hidden the data behind
scripts. It's not pure HTML, because often I have to reload the page
to make its HISTORIEK-table appear (if needed I can use another data
source, the "open" of stock exchange indexes often is lower or higher
than the lowest or highest value, and it's a reliable data source).
You can just enable some scripts based on source, so stopping scripts
from clickbait_ads.com from running while allowing the newspapers
scripts to run. Takes a while at first to get things working as you have
to whitelist the scripts you want to allow.
Also it's often the scripts that slow things down.
Post by A.D. Fundum
Regarding ads and http://bbc.com, I can confirm that I wasn't looking
for big & black... ;-)
The BBC uses Flash in a lot of articles
Dave

Dave Yeo
2014-12-08 04:01:22 UTC
Permalink
Post by Dave Yeo
so basically we're optimizing for everything but P4's
which I assume are getting rare.
[lots of interesting stuff clipped]

I should specify that even the P4 will benefit from the optimization,
just not enough.
As you mention, a P6 sounds like a reasonable minimum for Mozilla, if
only due to memory requirements and Mozilla won't even build if
targeting a 386 due to needing the GCC atomics function.
Generally I do just go with the defaults, and better programs that
really demand performance such as the Mozilla JavaScript JIT or video
encoding software such as FFmpeg will dynamically use the best
instruction set.
Still get bitten. I recently uploaded a build of Flac using the defaults
with someone using a PII getting a sigill (bad instruction) crash. Seems
it now defaults to using SSE2. Guess have to include 2 binaries next time.
Dave
A.D. Fundum
2014-12-08 10:53:46 UTC
Permalink
Post by Dave Yeo
As you mention, a P6 sounds like a reasonable minimum for
Mozilla, if only due to memory requirements
There's an unused trick to make clear that a P6 is an implied minimum
requirement, without having to print this requirement on the box. A
rebranded "HelloWorld for eCS", replacing a "HelloWorld/2". There's no
need for a "Mozilla for eCS" nor "VLC for eCS", but it should work for
common apps. eCS implies the use of a P6+.

If the user is still using OS/2, then the user will already be aware
of having to have new APIs, and so on. There's no Korean FP15, for
example, so they had to make their own. IBM's last GA Korean FP is
FP5. If "HelloWorld for eCS" still works with Warp 4, then the user is
lucky.
Post by Dave Yeo
Still get bitten. I recently uploaded a build of Flac using the
defaults with someone using a PII getting a sigill (bad
instruction) crash. Seems it now defaults to using SSE2.
Guess have to include 2 binaries next time.
Yes. Or one, of (theoretical) course, without using SSE2 instructions.
Using audio while adding more bugs to HelloWorld.EXE is no problem
with a PII, BTW. The CPU load of playing MP3s will be about about 3-5%
(less than 10%, anyway).

W.r.t. PIIIs, without SSE2, underlying problems are that IBM's
hardware often still works, and that eCS doesn't require a lot of
resources. I don't own eCS 2 (yet), but if its install procedure would
use SSE2 instructions then that would have been a new frontier. They
could even intentionally add an useless piece of SSE2 code to eCS 3
earliest install procedure, as long as you're still able to buy eCS 2
without SSE2 instructions. A bit like promoting the sales of newer
hardware and software by introducing our own version of Windows retry
8 (or by dropping support for XP). Now you have to release "Flac for
Windows 95/XP" and a "Flac for Windows Vista/7/8".

So developers can promote the support of SSE2 by printing that
requirement on the box of eCS 3. I'm not talking about recommended
hardware, I'm talking about the technical requirements. The PII user
cannot use "Flac for eCS 3", because it won't be possible to install
eCS 3. Just like you cannot install eCS 1.x on a P4/P5. If not having
SSE2 becomes a PITA of developers, then it may be reasonable to force
an upgrade many years (since 2006) after the introduction of SSE2
CPUs. You can still use eCS 1/2, but you cannot use "Flac for eCS 3".
Use an old version of Flac, or buy eCS 3 and "new" $30 Pentium IV
hardware. I'd recommend a single clear boundary, like a new main
version of the OS.

Finally anybody reading this is using (as opposed to owning) at least
a Pentium II indeed, unless they are still busy sending their angry,
justified replies. I'm not sure about my "> 99%" using a PIII+ to
read this thread, but I was trying to say that it'll be far more than
50%, but less than 100.0%. Your reported error seems to confirm this,
somebody expects that Flac works with a PII. So would I (including
PIIIs), at least by default. The use of a SSE2 CPU would be a (fair,
as such, but) unexpected requirement.


--
Dave Yeo
2014-12-08 04:06:36 UTC
Permalink
Post by Dave Yeo
so basically we're optimizing for everything but P4's
which I assume are getting rare.
[lots of interesting stuff clipped]

I should specify that even the P4 will benefit from the optimization,
just not enough.
As you mention, a P6 sounds like a reasonable minimum for Mozilla, if
only due to memory requirements and Mozilla won't even build if
targeting a 386 due to needing the GCC atomics function.
Generally I do just go with the defaults, and better programs that
really demand performance such as the Mozilla JavaScript JIT or video
encoding software such as FFmpeg will dynamically use the best
instruction set.
Still get bitten. I recently uploaded a build of Flac using the defaults
with someone using a PII getting a sigill (bad instruction) crash. Seems
it now defaults to using SSE2. Guess have to include 2 binaries next time.
Dave
Dariusz Piatkowski
2014-12-03 17:22:48 UTC
Permalink
Hi Dave!
Post by Dave Yeo
Post by Dariusz Piatkowski
Hi Dave!
Post by Dave Yeo
I've uploaded new builds of SeaMonkey 2.21 and Thunderbird 24.8.1 to
hobbes. Based on the same code as the Bitwise release of Firefox 24.8.1
and have the same issues including lack of HTML 5 sound which I believe
was forgotten to be mentioned.
Issues should be checked with Firefox 24.8.1 to see if they are in the
Gecko code or not.
Thanks to Bitwise for their work on Firefox and help for me to compile.
I'm curious: what is the difference between your release at the Bitwise stuff?
I tried theirs but hit a couple of issues with Firefox that made me go back...
They both share the same Gecko code (Gecko is the actual engine
underlying all the browsers) and the same tool chain.
..snip...
Post by Dave Yeo
I'd also recommend marking the DLL's to use high memory (needs the 106
kernel) which at least here helps a lot, currently 274.5 MBs free, but
still drops under some types of usage.
OK, I've got the following on my system:

Directory of G:\test

4-06-14 11:35a 6784 124 highmem.exe
4-06-14 11:35a 17635 124 highmem_g.exe

I also have ABOVE512:

1-28-04 7:21a 12603 0 ABOVE512.exe

Do you run either one for ALL of the files (EXE & DLLs) that make up Firefox
distro?

Thanks!
-Dariusz
Dave Yeo
2014-12-03 18:55:48 UTC
Permalink
Post by Dariusz Piatkowski
Post by Dave Yeo
I'd also recommend marking the DLL's to use high memory (needs the 106
Post by Dave Yeo
kernel) which at least here helps a lot, currently 274.5 MBs free, but
still drops under some types of usage.
Directory of G:\test
4-06-14 11:35a 6784 124 highmem.exe
4-06-14 11:35a 17635 124 highmem_g.exe
1-28-04 7:21a 12603 0 ABOVE512.exe
Do you run either one for ALL of the files (EXE & DLLs) that make up Firefox
distro?
For SeaMonkey (Firefox should be very similar) I ran highmem.exe -b on
all the DLLs except xul.dll on which I used highmem -c on. I found
marking the exe to create unstability here, your mileage may vary.
Dave
Dariusz Piatkowski
2014-12-07 22:20:58 UTC
Permalink
Dave!
Post by Dave Yeo
Post by Dariusz Piatkowski
Post by Dave Yeo
I'd also recommend marking the DLL's to use high memory (needs the 106
Post by Dave Yeo
kernel) which at least here helps a lot, currently 274.5 MBs free, but
still drops under some types of usage.
Directory of G:\test
4-06-14 11:35a 6784 124 highmem.exe
4-06-14 11:35a 17635 124 highmem_g.exe
1-28-04 7:21a 12603 0 ABOVE512.exe
Do you run either one for ALL of the files (EXE & DLLs) that make up Firefox
distro?
For SeaMonkey (Firefox should be very similar) I ran highmem.exe -b on
all the DLLs except xul.dll on which I used highmem -c on. I found
marking the exe to create unstability here, your mileage may vary.
Dave
Hmm...so this is interesting.

I did exactly as what you suggested. Rebooted the machine just to make sure that
upon Firefox start-up I would get the correct/intended load of DLLs.

Now, here is what a normal Firefox usage in my environment looks like. I
typically have 6-8 Firefox windows open within which there may be anywhere from
2 to 10 sessions/window open. I keep my machine up 24x7, it's a SMP box, 5-core
setup, running latest ACPI drivers. I still have "SET NSPR_OS2_NO_HIRES_TIMER=1"
in my CONFIG.SYS even with the latest ACPI drop (3.22.0.6) where there
apparently were some high-res timer changes. If I do not have this in place
Firefox very quickly (usually upon 3rd window instance) starts to show
continuous CPU spikes. The whole setup usually works fine for about 2-3 days,
until I get down to about 1.2Gig of RAM left, at which point Firefox basically
starts to crawl...eventually it nearly stops responding which is always followed
by "sudden death"...lol...OK, no worries, a re-start usually allows me to
re-cover the contents in the opened TABs and I get back in business only to
repeat the same scenario about 2-3 days later.

OK, so in this test, I deployed the HIGHMEM settings and proceeded to utilize
Firefox in exactly the same fashion. Within the 1st day Firefox arrived at the
"sudden death" gateway...it literally was nearly non-responsive...I decided to
close down a few windows instead of basically killing it (usually with
CAD-Popup) and to my astonishment closing down the sessions freed up some memory
and not only that, but the CPU spikes immediately went away and re-openning new
sessions hasn't caused the CPU spikes to come back. So I've been plugging away
for another day now with just the 1.1-1.2Gig RAM left...no ill effects so far.

Anyways...the high-memory placement seems to have had a positive impact here.
I'll try XUL.DLL and the EXE next.

Thanks again...great suggestion!

-Dariusz
Dave Yeo
2014-12-08 04:16:28 UTC
Permalink
Post by Dariusz Piatkowski
Dave!
[...]
Post by Dariusz Piatkowski
OK, so in this test, I deployed the HIGHMEM settings and proceeded to utilize
Firefox in exactly the same fashion. Within the 1st day Firefox arrived at the
"sudden death" gateway...it literally was nearly non-responsive...I decided to
close down a few windows instead of basically killing it (usually with
CAD-Popup) and to my astonishment closing down the sessions freed up some memory
and not only that, but the CPU spikes immediately went away and re-openning new
sessions hasn't caused the CPU spikes to come back. So I've been plugging away
for another day now with just the 1.1-1.2Gig RAM left...no ill effects so far.
I usually shutdown the browser once or twice a day, if only due to my
crappy internet connection. After a crash it takes forever to repopulate
the tabs/windows whereas session restore is quick.
There some cases where still run out of low shared memory, just not very
often. I have an applet that shows the free low shared memory (263MBs
currently) and the other day while loading a page it dropped about 150
MBs and quickly returned to normal. It does slowly go down with time
which is another reason to restart the browser occasionally.
Post by Dariusz Piatkowski
Anyways...the high-memory placement seems to have had a positive impact here.
I'll try XUL.DLL and the EXE next.
Careful with the .exe.
If you've had to kill the browser often or it has crashed you might want
to clear your cache directory as well as crashes seem to leave orphan
cache directories hanging around. By clear I mean deleting everything
under cache in your profile
Dave
Loading...