8:18 a.m.
I just removed 32bit CPU support from Darktable's spec file due
technical reasons.
Are there any other things I need to clean up in Fedora infrastructure?
8:27 a.m.
On 06/11/15 14:18, Germano Massullo wrote:
I just removed 32bit CPU support from Darktable's spec file due
technical reasons.
Are there any other things I need to clean up in Fedora infrastructure?
Well you should start by reading the relevant guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
1:11 p.m.
For example, SSE3 instructions set is one of the minimum requirements and
99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
architecture supports it.
2:50 p.m.
On 11/06/2015 02:11 PM, Germano Massullo wrote:
For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it.
For that kind of thing, add a runtime test for required CPU features at
startup. If you don't want to touch the original code, just add an
introducer that checks current hardware, then execs the app in /usr/libexec.
That may not be necessary if the app already fails in a friendly way on
old CPUs (as opposed to hanging or mysterious crashes).
9:24 p.m.
On 11/06/2015 09:50 PM, Stuart Gathman wrote:
On 11/06/2015 02:11 PM, Germano Massullo wrote:
>
> For example, SSE3 instructions set is one of the minimum requirements
> and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
> Prescott architecture supports it.
>
For that kind of thing, add a runtime test for required CPU features at
startup.
That's what they actually do.
cf. https://bugzilla.redhat.com/show_bug.cgi?id=1278064#c14
$ darktable
[dt_init] unfortunately we depend on SSE3 instructions at this time.
[dt_init] please contribute a backport patch (or buy a newer processor).
That may not be necessary if the app already fails in a friendly way
on
old CPUs (as opposed to hanging or mysterious crashes).
Ralf
3 p.m.
Germano Massullo wrote:
For example, SSE3 instructions set is one of the minimum requirements
and
99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
architecture supports it.
I think building it with SSE3 is better than excluding the architecture
entirely. And FYI, requiring SSE3 is not really allowed even for x86_64 (you
are allowed to assume only SSE2), so by that argument, there is no
architecture left.
Of course, a better solution would be to fix the package to work on all CPUs
you support. But if upstream doesn't care, it's going to be a problem. :-(
We have a similar issue with QtWebEngine, because Chromium/V8 upstream
requires SSE2 in their JIT and there is no interpreter fallback. (They are
now working on an "interpreter" mode, but it is not a real interpreter
fallback either, some stuff still uses the JIT.)
Kevin Kofler
9:29 p.m.
On 11/06/2015 10:00 PM, Kevin Kofler wrote:
Germano Massullo wrote:
> For example, SSE3 instructions set is one of the minimum requirements and
> 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
> architecture supports it.
I think building it with SSE3 is better than excluding the architecture
entirely. And FYI, requiring SSE3 is not really allowed even for x86_64 (you
are allowed to assume only SSE2), so by that argument, there is no
architecture left.
ACK. Does anybody know if there are any x86_64/64bit-CPUs which
do not
support sse3?
I don't see sse3 in /proc/cpuinfo of any machine I have, but I also
don't see any runtime error/warning from darktable.
Of course, a better solution would be to fix the package to work on
all CPUs
you support.
ACK.
But if upstream doesn't care, it's going to be a problem. :-(
Exactly - That's the actual problem. Upstream does not care and Fedora
seems unable to address this issue.
Ralf
10 p.m.
On 06/11/15 07:29 PM, Ralf Corsepius wrote:
On 11/06/2015 10:00 PM, Kevin Kofler wrote:
> Germano Massullo wrote:
>> For example, SSE3 instructions set is one of the minimum
>> requirements and
>> 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
>> architecture supports it.
>
> I think building it with SSE3 is better than excluding the architecture
> entirely. And FYI, requiring SSE3 is not really allowed even for
> x86_64 (you
> are allowed to assume only SSE2), so by that argument, there is no
> architecture left.
ACK. Does anybody know if there are any x86_64/64bit-CPUs which do not
support sse3?
I don't see sse3 in /proc/cpuinfo of any machine I have, but I also
don't see any runtime error/warning from darktable.
> Of course, a better solution would be to fix the package to work on
> all CPUs
> you support.
ACK.
> But if upstream doesn't care, it's going to be a problem. :-(
Exactly - That's the actual problem. Upstream does not care and Fedora
seems unable to address this issue.
Ralf
According to my system, it has SSSE3. Is it SSE3?
Taken from A10-7400P laptop.
--
Luya Tshimbalanga
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net
10:03 p.m.
Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:
On 06/11/15 07:29 PM, Ralf Corsepius wrote:
>> But if upstream doesn't care, it's going to be a problem. :-(
> Exactly - That's the actual problem. Upstream does not care and Fedora
> seems unable to address this issue.
>
> Ralf
>
According to my system, it has SSSE3. Is it SSE3?
Taken from A10-7400P laptop
any system not older than 10 years has SSE3 and frankly systems older
than 10 years are hardly a traget for Fedora at all
10:41 p.m.
On 11/07/2015 05:03 AM, Reindl Harald wrote:
Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:
> On 06/11/15 07:29 PM, Ralf Corsepius wrote:
>>> But if upstream doesn't care, it's going to be a problem. :-(
>> Exactly - That's the actual problem. Upstream does not care and Fedora
>> seems unable to address this issue.
>>
>> Ralf
>>
> According to my system, it has SSSE3. Is it SSE3?
That's what my question
actually was about.
I see ssse3 on all my x86_64ers, I see sse3 on my 32bit atoms, but I
don't know if ssse3 implies sse3 and I don't know what -msse3 actually
does to the instruction set when being used on x86_64ers and which
impact it has (-msse3 is not part of Fedora's gcc implicit CFLAGS).
any system not older than 10 years has SSE3 and frankly systems
older
than 10 years are hardly a traget for Fedora at all
So, Fedora or Linux as a resort to escape Windows on old HW is not a
Fedora target anymore?
Ralf
5:31 a.m.
Am 07.11.2015 um 05:41 schrieb Ralf Corsepius:
On 11/07/2015 05:03 AM, Reindl Harald wrote:
>
> Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:
>> On 06/11/15 07:29 PM, Ralf Corsepius wrote:
>>>> But if upstream doesn't care, it's going to be a problem. :-(
>>> Exactly - That's the actual problem. Upstream does not care and Fedora
>>> seems unable to address this issue.
>>>
>> According to my system, it has SSSE3. Is it SSE3?
That's what my question actually was about.
https://en.wikipedia.org/wiki/SSE3#CPUs_with_SSE3
I see ssse3 on all my x86_64ers, I see sse3 on my 32bit atoms, but I
don't know if ssse3 implies sse3 and I don't know what -msse3 actually
does to the instruction set when being used on x86_64ers and which
impact it has
https://en.wikipedia.org/wiki/SSE3#New_instructions
(-msse3 is not part of Fedora's gcc implicit CFLAGS).
and that is really sad because it wastes for 99.9% of users performance
and hence i override the builds of perormance relevant software since
years with optimized falgs while hat -fstack-protector-all in use long
before Fedora supported and switched to -fstack-protector-strong
in other words: you get the small performance impact of hardening back
by better utilize your existing hardware instead castrate your whole
software to nostalgic decades
> any system not older than 10 years has SSE3 and frankly systems
older
> than 10 years are hardly a traget for Fedora at all
So, Fedora or Linux as a resort to escape Windows on old HW is not a
Fedora target anymore?
come on and install a recent Fedora on such old machines, guess what
SSE3 or not is your smallest problem
2:20 p.m.
On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:
> On 06/11/15 07:29 PM, Ralf Corsepius wrote:
>
>> But if upstream doesn't care, it's going to be a problem. :-(
>>>
>> Exactly - That's the actual problem. Upstream does not care and Fedora
>> seems unable to address this issue.
>>
>> Ralf
>>
>> According to my system, it has SSSE3. Is it SSE3?
> Taken from A10-7400P laptop
>
any system not older than 10 years has SSE3 and frankly systems older than
10 years are hardly a traget for Fedora at all
On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
place
my LaserJet 4L printer works. My 64-bit systems drop control
sequences (like they don't flush the output buffer), leaving the last page
of every job sitting in printer memory. I reported the bug a few years ago,
but it got closed as WONTFIX and now I can't find it in bugzilla.
2:54 p.m.
Am 11.11.2015 um 21:20 schrieb Fred New:
On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald
<h.reindl(a)thelounge.net
<mailto:h.reindl@thelounge.net>> wrote:
Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:
On 06/11/15 07:29 PM, Ralf Corsepius wrote:
But if upstream doesn't care, it's going to be a
problem. :-(
Exactly - That's the actual problem. Upstream does not care
and Fedora
seems unable to address this issue.
Ralf
According to my system, it has SSSE3. Is it SSE3?
Taken from A10-7400P laptop
any system not older than 10 years has SSE3 and frankly systems
older than 10 years are hardly a traget for Fedora at all
On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
place my LaserJet 4L printer works. My 64-bit systems drop control
sequences (like they don't flush the output buffer), leaving the last
page of every job sitting in printer memory. I reported the bug a few
years ago, but it got closed as WONTFIX and now I can't find it in bugzilla
we talk about a *bleeding edge distribution*
https://en.wikipedia.org/wiki/HP_LaserJet_4#4L_and_4P
"The LaserJet 4 series was discontinued in the 1990s"
why in the world does somebody install a operating system released in
2015 to drive harwdare realeased 10-15 years ago and *why in the world*
should recent hardware feautures ignored forever because of users with
such hardware?
you CAN NOT HAVE both - leading edge software and legacy support forever
that's the same disucssion as others have with "my PHP crap don't work
with anything above PHP 5.2 so why can't i have newest software *but
not* recent PHP
3:10 p.m.
Am 11.11.2015 um 21:54 schrieb Reindl Harald:
Am 11.11.2015 um 21:20 schrieb Fred New:
> On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald <h.reindl(a)thelounge.net
> any system not older than 10 years has SSE3 and frankly systems
> older than 10 years are hardly a traget for Fedora at all
>
> On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
> place my LaserJet 4L printer works. My 64-bit systems drop control
> sequences (like they don't flush the output buffer), leaving the last
> page of every job sitting in printer memory. I reported the bug a few
> years ago, but it got closed as WONTFIX and now I can't find it in
> bugzilla
we talk about a *bleeding edge distribution*
https://en.wikipedia.org/wiki/HP_LaserJet_4#4L_and_4P
"The LaserJet 4 series was discontinued in the 1990s"
why in the world does somebody install a operating system released in
2015 to drive harwdare realeased 10-15 years ago and *why in the world*
should recent hardware feautures ignored forever because of users with
such hardware?
you CAN NOT HAVE both - leading edge software and legacy support forever
that's the same disucssion as others have with "my PHP crap don't work
with anything above PHP 5.2 so why can't i have newest software *but
not* recent PHP
and to make it clear:
when you and the other 5 users think they can demand support for ancient
hardware forever because these days cheap hardware is too much cost i
tell you that my lifetime for adpot a ton of regressions cuased by
replacing perfect fine working software with half baken replacements is
*much more* worth because you can buy reasonable hardware, i can't buy
additional lifetime wasted over the last years by braindead software
decisions
3:35 p.m.
Reindl Harald composed on 2015-11-11 22:10 (UTC+0100):
when you and the other 5 users think they can demand support for
ancient
hardware forever because these days cheap hardware is too much cost i
tell you that my lifetime for adpot a ton of regressions cuased by
replacing perfect fine working software with half baken replacements is
*much more* worth because you can buy reasonable hardware, i can't buy
additional lifetime wasted over the last years by braindead software
decisions
Must be nice to be affluent. This thread proves you simply don't get that not
everyone is in position to buy, buy, buy to replace what ain't broke just
because marketers and manufacturers have something ostensibly better to
offer. Many, many many have no choice but to make do with whatever they have
or can acquire without money. They too want to do the best they can with what
they have or can get without money, meaning for many, first choice would not
be a yesteryear distro. Compatibililty with more blessed peers or for other
reasons may be necessary, and dictate at least some "bleeding edge" software.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
3:44 p.m.
Am 11.11.2015 um 22:35 schrieb Felix Miata:
Reindl Harald composed on 2015-11-11 22:10 (UTC+0100):
> when you and the other 5 users think they can demand support for ancient
> hardware forever because these days cheap hardware is too much cost i
> tell you that my lifetime for adpot a ton of regressions cuased by
> replacing perfect fine working software with half baken replacements is
> *much more* worth because you can buy reasonable hardware, i can't buy
> additional lifetime wasted over the last years by braindead software
> decisions
Must be nice to be affluent. This thread proves you simply don't get that not
everyone is in position to buy, buy, buy to replace what ain't broke just
because marketers and manufacturers have something ostensibly better to
offer. Many, many many have no choice but to make do with whatever they have
or can acquire without money. They too want to do the best they can with what
they have or can get without money, meaning for many, first choice would not
be a yesteryear distro. Compatibililty with more blessed peers or for other
reasons may be necessary, and dictate at least some "bleeding edge" software
it's not a matter of be affluent
if buying every decade a new computer is too uch just don't demand
bleeding edge software runs on yours and use a LTS distribution - is
that really so hard to understand?
4:57 p.m.
Reindl Harald composed on 2015-11-11 22:44 (UTC+0100):
Felix Miata composed:
> Must be nice to be affluent. This thread proves you simply
don't get that not
> everyone is in position to buy, buy, buy to replace what ain't broke just
> because marketers and manufacturers have something ostensibly better to
> offer. Many, many many have no choice but to make do with whatever they have
> or can acquire without money. They too want to do the best they can with what
> they have or can get without money, meaning for many, first choice would not
> be a yesteryear distro. Compatibililty with more blessed peers or for other
> reasons may be necessary, and dictate at least some "bleeding edge"
software
it's not a matter of be affluent
Affluence is relative. If you don't have money, you don't buy new stuff,
especially to replace working stuff.
if buying every decade a new computer is too uch just don't
demand
What's magical about a decade? Nothing. It's arbitrary. People last more than
a decade. Cars last more than a decade. Houses last more than a decade.
Refrigerators last more than a decade. No good reason a PC can't last more
than a decade before polluting a landfill.
bleeding edge software runs on yours and use a LTS distribution - is
that really so hard to understand?
You seem unable to understand that there are far more than a few easily
classifiable use cases, or that bleeding edge doesn't imply being first to
tell computer users (or let them find out the hard way) theirs are too old
for continuing to use the distro they've been using and are used to and/or
prefer and/or shared with those they need or want to maintain maximum
compatibility with.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
3:41 p.m.
On 11 November 2015 at 14:10, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 11.11.2015 um 21:54 schrieb Reindl Harald:
>
>
> Am 11.11.2015 um 21:20 schrieb Fred New:
>>
>> On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald <h.reindl(a)thelounge.net
>> any system not older than 10 years has SSE3 and frankly systems
>> older than 10 years are hardly a traget for Fedora at all
>>
>> On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
>> place my LaserJet 4L printer works. My 64-bit systems drop control
>> sequences (like they don't flush the output buffer), leaving the last
>> page of every job sitting in printer memory. I reported the bug a few
>> years ago, but it got closed as WONTFIX and now I can't find it in
>> bugzilla
>
>
> we talk about a *bleeding edge distribution*
>
> https://en.wikipedia.org/wiki/HP_LaserJet_4#4L_and_4P
> "The LaserJet 4 series was discontinued in the 1990s"
>
> why in the world does somebody install a operating system released in
> 2015 to drive harwdare realeased 10-15 years ago and *why in the world*
> should recent hardware feautures ignored forever because of users with
> such hardware?
>
> you CAN NOT HAVE both - leading edge software and legacy support forever
>
> that's the same disucssion as others have with "my PHP crap don't work
> with anything above PHP 5.2 so why can't i have newest software *but
> not* recent PHP
and to make it clear:
when you and the other 5 users think they can demand support for ancient
Harald, he didn't demand anything. He just stated what he was using
and why. You need to back the angry sysadmin a bit :). Save it for
when someone wants to know why they can't get their Leading Edge i386
to work with Fedora anymore and what the developers are going to do
about it or else he will post nasty notes to slashdot.
hardware forever because these days cheap hardware is too much cost i
tell
you that my lifetime for adpot a ton of regressions cuased by replacing
perfect fine working software with half baken replacements is *much more*
worth because you can buy reasonable hardware, i can't buy additional
lifetime wasted over the last years by braindead software decisions
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Stephen J Smoogen.
2:49 p.m.
On 11/11/2015 03:54 PM, Reindl Harald wrote:
Am 11.11.2015 um 21:20 schrieb Fred New:
>
> On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
> place my LaserJet 4L printer works. My 64-bit systems drop control
> sequences (like they don't flush the output buffer), leaving the last
> page of every job sitting in printer memory. I reported the bug a few
> years ago, but it got closed as WONTFIX and now I can't find it in
> bugzilla
we talk about a *bleeding edge distribution*
https://en.wikipedia.org/wiki/HP_LaserJet_4#4L_and_4P
"The LaserJet 4 series was discontinued in the 1990s"
why in the world does somebody install a operating system released in
2015 to drive harwdare realeased 10-15 years ago and *why in the
world* should recent hardware feautures ignored forever because of
users with such hardware?
This should not be a big problem---the printer used to work, so we have
a regression. From Fred's description, it looks like a simple issue,
actually.
I agree with you that the ball is in Fred's court, though: he's the one
that wants to keep his stuff running so at least he should help to
diagnose and report the problem (which he did), and follow up by
tracking it to some satisfactory resolution (which he didn't). It seems
to me that Fred should find, reopen and pursue his bugzilla report.
On the other hand, Harald, I have to say that in this case my irony
detector bent the needle. You often voice your displeasure in this forum
that some setup you used for years was broken by new stuff, and yet you say
you CAN NOT HAVE both - leading edge software and legacy support
forever
I just see this quoted back at you in the future :)
2:51 a.m.
Am 12.11.2015 um 21:49 schrieb Przemek Klosowski:
On the other hand, Harald, I have to say that in this case my irony
detector bent the needle. You often voice your displeasure in this forum
that some setup you used for years was broken by new stuff, and yet you say
> you CAN NOT HAVE both - leading edge software and legacy support forever
I just see this quoted back at you in the future :)
it's a difference replacing working software with some
alpha/beta-quality stuff lacking half of the features and waiting years
to get useable as before or just drop the support for hardware older
than 10 years for the sake of use capabilities of more recent one
3:01 p.m.
On 11 November 2015 at 13:20, Fred New <fred.new2911(a)gmail.com> wrote:
On Sat, Nov 7, 2015 at 6:03 AM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
>
>
>
> Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:
>>
>> On 06/11/15 07:29 PM, Ralf Corsepius wrote:
>>>>
>>>> But if upstream doesn't care, it's going to be a problem. :-(
>>>
>>> Exactly - That's the actual problem. Upstream does not care and Fedora
>>> seems unable to address this issue.
>>>
>>> Ralf
>>>
>> According to my system, it has SSSE3. Is it SSE3?
>> Taken from A10-7400P laptop
>
>
> any system not older than 10 years has SSE3 and frankly systems older than
> 10 years are hardly a traget for Fedora at all
>
On the other hand, my >10 year-old 32-bit system (Fedora 22) is the only
place my LaserJet 4L printer works. My 64-bit systems drop control sequences
(like they don't flush the output buffer), leaving the last page of every
job sitting in printer memory. I reported the bug a few years ago, but it
got closed as WONTFIX and now I can't find it in bugzilla.
I don't doubt it is WONTFIX :).
That printer is old enough to vote and drink in the United States.
Depending on how the printer is connected to the computer you would
need either a parallel port debugger or whatever monstrosity is
converting USB to RS232 (if you are using serial input).. or SCSI?
At a certain point this sort of hardware can only be supported if
there are owners who can do the kind of work needed to make it work.
Which usually means that at some point you move off of the
'cutting/bleeding' edge distributions to something like Debian or
CentOS 5.
--
Stephen J Smoogen.
11:13 p.m.
On Sat, 7 Nov 2015 04:29:48 +0100
Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 11/06/2015 10:00 PM, Kevin Kofler wrote:
> Germano Massullo wrote:
>> For example, SSE3 instructions set is one of the minimum
>> requirements and 99% of 32 bit only CPUs do not support it. Only
>> Pentium 4 >= Prescott architecture supports it.
>
> I think building it with SSE3 is better than excluding the
> architecture entirely. And FYI, requiring SSE3 is not really
> allowed even for x86_64 (you are allowed to assume only SSE2), so
> by that argument, there is no architecture left.
ACK. Does anybody know if there are any x86_64/64bit-CPUs which do
not support sse3?
I don't see sse3 in /proc/cpuinfo of any machine I have, but I also
don't see any runtime error/warning from darktable.
SSE3 is reported as 'pni' (Prescott New Instructions)
> Of course, a better solution would be to fix the package to work
on
> all CPUs you support.
ACK.
> But if upstream doesn't care, it's going to be a problem. :-(
Exactly - That's the actual problem. Upstream does not care and
Fedora seems unable to address this issue.
Ralf
1:40 a.m.
Il 07/11/2015 04:29, Ralf Corsepius ha scritto:
I don't see sse3 in /proc/cpuinfo of any machine I have, but I
also
don't see any runtime error/warning from darktable.
Because SSE3 is shown as
"pni", Prescott New Instructions [1] [2]
[1]: https://en.wikipedia.org/wiki/SSE3
[2]:
http://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-c...
7:02 a.m.
Ralf Corsepius wrote:
Exactly - That's the actual problem. Upstream does not care and
Fedora
seems unable to address this issue.
I think the only way to really fix this package would be to track down and
add patches reverting all commits like these:
http://redmine.darktable.org/projects/darktable/repository/revisions/a8f3...
http://redmine.darktable.org/projects/darktable/repository/revisions/2807...
…
Kevin Kofler
9:55 p.m.
Am 06.11.2015 um 20:11 schrieb Germano Massullo:
For example, SSE3 instructions set is one of the minimum
requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it
seriously?
with that argumentation Fedora would drop i686 at all
well, i don't have any non x86_64 machien but the argumentation is bous
10:25 p.m.
On 11/07/2015 04:55 AM, Reindl Harald wrote:
Am 06.11.2015 um 20:11 schrieb Germano Massullo:
> For example, SSE3 instructions set is one of the minimum requirements
> and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
> Prescott architecture supports it
seriously?
Probably.
with that argumentation Fedora would drop i686 at all
No.
darktable handles the situation on sse3-less CPUs gracefully at
run-time.
The actually problem is darktable wanting to be compiled with -msse3,
which means being compiled with a Fedora incompatible instruction set,
on both i386 and x86_64.
well, i don't have any non x86_64 machien but the argumentation
is bous
You are right, these days in professional PC-usage, i686ers likely are
rare and hard to find.
But in personal (private) PC-usage, the situation is different. There,
5/6-year old 32bit PCs are still wide spread and will be supported by
Windows for many years. Also consider, people are using Linux on such
machines to extend these machines life time.
Feel free to drop the i386, if you want drop the end-user/desktop market
and to leave this market to Ubuntu, Debian and other distributions.
Ralf
5:17 a.m.
Am 07.11.2015 um 05:25 schrieb Ralf Corsepius:
On 11/07/2015 04:55 AM, Reindl Harald wrote:
>
> Am 06.11.2015 um 20:11 schrieb Germano Massullo:
>> For example, SSE3 instructions set is one of the minimum requirements
>> and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
>> Prescott architecture supports it
>
> seriously?
Probably.
come on and don't tell me 99% of i686 users have machines older than 10
years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
in early 2004 with the Prescott revision of their Pentium 4 CPU"
those machines would not be able to run a recent Fedora due all the
bloat introduced over the years - try a system update with 512 MB and
shake your hands with the OOM-killer
> with that argumentation Fedora would drop i686 at all
No. darktable handles the situation on sse3-less CPUs gracefully at
run-time.
The actually problem is darktable wanting to be compiled with -msse3,
which means being compiled with a Fedora incompatible instruction set,
on both i386 and x86_64.
Fedora incompatible?
many software including the kernel has binary code for AVX and even AVX2
and is using CPU runtime detection - using SSE3 instructions in a
software is not bound to compiler flags and when a upstream developer
don't care about 11 year old hardware you have to suck taht downstrem
> well, i don't have any non x86_64 machien but the
argumentation is bogus
You are right, these days in professional PC-usage, i686ers likely are
rare and hard to find.
But in personal (private) PC-usage, the situation is different. There,
5/6-year old 32bit PCs are still wide spread and will be supported by
Windows for many years. Also consider, people are using Linux on such
machines to extend these machines life time.
there is nothing like a 5 year old 32bit-only machine, but that's not
the point, i explained the OP and package maintainer that he is talking
nonsense in the context of "99% of all 32bit CPUs don't support SSE3"
and have no idea why you need to contradict here
Feel free to drop the i386, if you want drop the end-user/desktop
market
and to leave this market to Ubuntu, Debian and other distributions
see above
7:05 a.m.
Reindl Harald wrote:
come on and don't tell me 99% of i686 users have machines older
than 10
years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
in early 2004 with the Prescott revision of their Pentium 4 CPU"
those machines would not be able to run a recent Fedora due all the
bloat introduced over the years - try a system update with 512 MB and
shake your hands with the OOM-killer
I have a computer without SSE3. It runs Fedora just fine. I initially had 1
GiB of RAM in it, I upgraded it to 3 GiB.
Fedora incompatible?
many software including the kernel has binary code for AVX and even AVX2
and is using CPU runtime detection - using SSE3 instructions in a
software is not bound to compiler flags and when a upstream developer
don't care about 11 year old hardware you have to suck taht downstrem
What he means is that Fedora policies DO NOT allow REQUIRING those
instruction sets. Runtime detection is of course fine.
The problem we are having now is upstream projects that do not support ANY
kind of fallback, not even at compile time. (Those are also inherently non-
portable because they don't work on any other CPU architecture.) Chromium/V8
is another such problem program.
Kevin Kofler
9:01 a.m.
Kevin Kofler composed on 2015-11-07 14:05 (UTC+0100):
Reindl Harald wrote:
> come on and don't tell me 99% of i686 users have machines
older than 10
> years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
> in early 2004 with the Prescott revision of their Pentium 4 CPU"
Any demarcation that is calendar based is purely arbitrary. 64 bit was
introduced far more than 10 years ago. There is plenty of 32 bit hardware
perfectly capable of doing what needs doing regardless of age. Not everyone
needs, or wants, the bloat that newer enables. Not everyone is "speed"
sensitive, while most are sensitive to the security that keeping current
provides.
FWIW, Prescott introduction roughly coincides with PCIe video slots replacing
AGP slots. Any motherboard with AGP likely is incapable of having a 64 bit
Intel CPU installed and supported by its BIOS.
> those machines would not be able to run a recent Fedora due all
the
> bloat introduced over the years - try a system update with 512 MB and
> shake your hands with the OOM-killer
I have a computer without SSE3. It runs Fedora just fine. I initially
had 1
GiB of RAM in it, I upgraded it to 3 GiB.
I have approximately 40 Fedora installations on 32 bit CPUs. About half of
those are on Prescotts. I'm unable to notice that those with more than 1G RAM
run any better than those with more RAM. I am able to notice that the older,
slower ones that do have SSE2 are able to run, but with Plasma 5, those are
very slow. Those do run respectably with lighter WMs/DEs. For those without
SSE2, Plasma 5 is completely unusable, but OK with any of the lightweights.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
9:12 a.m.
Am 07.11.2015 um 16:01 schrieb Felix Miata:
Kevin Kofler composed on 2015-11-07 14:05 (UTC+0100):
> Reindl Harald wrote:
>> come on and don't tell me 99% of i686 users have machines older than 10
>> years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
>> in early 2004 with the Prescott revision of their Pentium 4 CPU"
Any demarcation that is calendar based is purely arbitrary. 64 bit was
introduced far more than 10 years ago. There is plenty of 32 bit hardware
perfectly capable of doing what needs doing regardless of age. Not everyone
needs, or wants, the bloat that newer enables. Not everyone is "speed"
sensitive, while most are sensitive to the security that keeping current
provides
and these are the Fedora relevant users?
that machines are fare better served with CentOS (now there is even a
i686 one while RHEL7 does not exist of 32bit) instead bleeding edge
while i don't see a compelling reason that a bleeding edge distribution
in 2015 ignores SSE3 while in the meantime SSE4.2/AVX/AVX2 where
introduced for a handful of users
"I have approximately 40 Fedora installations on 32 bit CPUs" by one
real computer and put them all inside virtual machines on top of it -
problem solved - the power savings alone wil pay it!
our new DL380 has two Xeon(R) CPU E5-2643 v3 @ 3.40GHz, 128 GB RAM, runs
the whole company 8 with a second node for failover) and consumes 115W
power (average over 24 hours)
9:40 a.m.
Reindl Harald composed on 2015-11-07 16:12 (UTC+0100):
Felix Miata composed:
> Kevin Kofler composed on 2015-11-07 14:05 (UTC+0100):
>> Reindl Harald wrote:
>>> come on and don't tell me 99% of i686 users have
machines older than 10
>>> years https://en.wikipedia.org/wiki/SSE3 because "ntel introduced SSE3
>>> in early 2004 with the Prescott revision of their Pentium 4 CPU"
> Any demarcation that is calendar based is purely arbitrary. 64
bit was
> introduced far more than 10 years ago. There is plenty of 32 bit hardware
> perfectly capable of doing what needs doing regardless of age. Not everyone
> needs, or wants, the bloat that newer enables. Not everyone is "speed"
> sensitive, while most are sensitive to the security that keeping current
> provides
and these are the Fedora relevant users?
Surely there are people who need relativly recent or current versions of
software other than web browsers who aren't concerned with speed or replacing
hardware at an arbitrary chronological age. Photographers using Darktable may
well be among them.
Under any given roof, it makes sense to keep all machines on the same OS when
practical. Who's to say a whole family or business should be using CentOS
because one machine is past its prime?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
9:45 a.m.
Am 07.11.2015 um 16:40 schrieb Felix Miata:
Reindl Harald composed on 2015-11-07 16:12 (UTC+0100):
> Felix Miata composed:
>> Any demarcation that is calendar based is purely arbitrary. 64 bit was
>> introduced far more than 10 years ago. There is plenty of 32 bit hardware
>> perfectly capable of doing what needs doing regardless of age. Not everyone
>> needs, or wants, the bloat that newer enables. Not everyone is "speed"
>> sensitive, while most are sensitive to the security that keeping current
>> provides
> and these are the Fedora relevant users?
Surely there are people who need relativly recent or current versions of
software other than web browsers who aren't concerned with speed or replacing
hardware at an arbitrary chronological age. Photographers using Darktable may
well be among them.
Under any given roof, it makes sense to keep all machines on the same OS when
practical. Who's to say a whole family or business should be using CentOS
because one machine is past its prime?
well, who's to say that we stay forever on a level of CPU
feature-support while there are instruction sets available for a whole
decade which improve performance, save power in case you need fewer
instructions doing the same work?
not that i say Fedora should go ahead and build with -mavx but a
discussion about SSE3 in 2015 is really odd
12:01 p.m.
Reindl Harald wrote:
well, who's to say that we stay forever on a level of CPU
feature-support while there are instruction sets available for a whole
decade which improve performance, save power in case you need fewer
instructions doing the same work?
not that i say Fedora should go ahead and build with -mavx but a
discussion about SSE3 in 2015 is really odd
Sorry, but hardware simply does not get replaced instantly. This is a matter
of both:
* cost – hardware is not free (as in beer),
* ecology – there are huge landfills in China, India and Africa full of
electronic trash from Europe and the USA; that gets mined for
recyclable materials in an extremely polluting way that not only
ruins the environment, but also damages the health of the people
doing the mining (and the most dangerous materials are handled
by children). Materials used for electronic components are
precious, someone has to recycle them or they would run out
pretty soon.
As a developer who writes mathematical software for a living, I'd love being
able to require AVX-512 right now (https://en.wikipedia.org/wiki/AVX-512 –
finally a way to specify the rounding mode per operation
(https://en.wikipedia.org/wiki/EVEX_prefix) rather than through the
extremely expensive stateful fesetround operations that reset the whole
prefetch queue, interval arithmetic should become MUCH faster with that),
but I have to deal with real-world CPUs that are here NOW (so it might make
sense to have runtime detection for AVX-512 only in 1 or 2 years, and
requiring it is simply not possible within the next decade).
Kevin Kofler
12:23 p.m.
Am 07.11.2015 um 19:01 schrieb Kevin Kofler:
Reindl Harald wrote:
> well, who's to say that we stay forever on a level of CPU
> feature-support while there are instruction sets available for a whole
> decade which improve performance, save power in case you need fewer
> instructions doing the same work?
>
> not that i say Fedora should go ahead and build with -mavx but a
> discussion about SSE3 in 2015 is really odd
Sorry, but hardware simply does not get replaced instantly. This is a matter
of both:
* cost – hardware is not free (as in beer)
that *really* depends
these days (and i talk about hardware from 2011) you can virtualize
things fast, easy and efficient and consolidate machines on more or less
cheap hardware
besides it brings new CPU capabilities it saves a lot of energy:
* one machine instead 2,3,4 or 10 machines
* the new hardware needs so much less power
* your UPS (in case you use one) can be cheaper or lasts longer
* cooling is easier, cheaper and not that loud
some numbers in that context:
in early 2010 we planned a UPS systems to last for around 3 hours, with
the current hardware and after consolidation the same UPS lasts 9 hours
now and the air conditioner has lower load and longer lifetime
the same applies to consumer hardware, my 365/7 running homeserver from
2011 is a power beast and the whole IT needs around 50W while the
previous hardware needed 120W - that's money, that's heat on summer
days, that's less noise and hardddisks don't need to replaced that often
because they are cooler
* ecology – there are huge landfills in China, India and Africa full
of
electronic trash from Europe and the USA; that gets mined for
recyclable materials in an extremely polluting way that not only
ruins the environment, but also damages the health of the people
doing the mining (and the most dangerous materials are handled
by children). Materials used for electronic components are
precious, someone has to recycle them or they would run out
pretty soon.
that is true but see above
As a developer who writes mathematical software for a living, I'd
love being
able to require AVX-512 right now (https://en.wikipedia.org/wiki/AVX-512 –
finally a way to specify the rounding mode per operation
(https://en.wikipedia.org/wiki/EVEX_prefix) rather than through the
extremely expensive stateful fesetround operations that reset the whole
prefetch queue, interval arithmetic should become MUCH faster with that),
but I have to deal with real-world CPUs that are here NOW (so it might make
sense to have runtime detection for AVX-512 only in 1 or 2 years, and
requiring it is simply not possible within the next decade)
maybe you did not get "not that i say Fedora should go ahead and build
with -mavx" but we talk about SSE3
talking about a rapid moving distribution like Fedora and at the same
time hestitate to use technology available for a decade is strange - i
guess people plan to run their hardware for 10, 12, 15 years are not
using typically a distribution like Fedora
12:26 p.m.
On Sat, Nov 7, 2015 at 1:23 PM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
Am 07.11.2015 um 19:01 schrieb Kevin Kofler:
> Reindl Harald wrote:
>
>> well, who's to say that we stay forever on a level of CPU
>> feature-support while there are instruction sets available for a whole
>> decade which improve performance, save power in case you need fewer
>> instructions doing the same work?
>>
>> not that i say Fedora should go ahead and build with -mavx but a
>> discussion about SSE3 in 2015 is really odd
>>
>
> Sorry, but hardware simply does not get replaced instantly. This is a
> matter
> of both:
> * cost – hardware is not free (as in beer)
>
that *really* depends
these days (and i talk about hardware from 2011) you can virtualize things
fast, easy and efficient and consolidate machines on more or less cheap
hardware
besides it brings new CPU capabilities it saves a lot of energy:
* one machine instead 2,3,4 or 10 machines
* the new hardware needs so much less power
* your UPS (in case you use one) can be cheaper or lasts longer
* cooling is easier, cheaper and not that loud
some numbers in that context:
in early 2010 we planned a UPS systems to last for around 3 hours, with
the current hardware and after consolidation the same UPS lasts 9 hours now
and the air conditioner has lower load and longer lifetime
the same applies to consumer hardware, my 365/7 running homeserver from
2011 is a power beast and the whole IT needs around 50W while the previous
hardware needed 120W - that's money, that's heat on summer days, that's
less noise and hardddisks don't need to replaced that often because they
are cooler
* ecology – there are huge landfills in China, India and Africa full of
> electronic trash from Europe and the USA; that gets mined for
> recyclable materials in an extremely polluting way that not
> only
> ruins the environment, but also damages the health of the
> people
> doing the mining (and the most dangerous materials are
> handled
> by children). Materials used for electronic components are
> precious, someone has to recycle them or they would run out
> pretty soon.
>
that is true but see above
As a developer who writes mathematical software for a living, I'd love
> being
> able to require AVX-512 right now (https://en.wikipedia.org/wiki/AVX-512
> –
> finally a way to specify the rounding mode per operation
> (https://en.wikipedia.org/wiki/EVEX_prefix) rather than through the
> extremely expensive stateful fesetround operations that reset the whole
> prefetch queue, interval arithmetic should become MUCH faster with that),
> but I have to deal with real-world CPUs that are here NOW (so it might
> make
> sense to have runtime detection for AVX-512 only in 1 or 2 years, and
> requiring it is simply not possible within the next decade)
>
maybe you did not get "not that i say Fedora should go ahead and build
with -mavx" but we talk about SSE3
talking about a rapid moving distribution like Fedora and at the same time
hestitate to use technology available for a decade is strange - i guess
people plan to run their hardware for 10, 12, 15 years are not using
typically a distribution like Fedora
The flip side of it is that Fedora is the foundation for RHEL and other
distributions. Most of the others don't matter so much, but RHEL does, as
that has to support servers and such. But even there, I would suggest to
say that we could say that RHEL 8 shouldn't have a problem bumping up,
since RHEL 7 supports those systems fine and will be supported for 9 more
years.
--
真実はいつも一つ！/ Always, there's only one truth!
12:31 p.m.
Am 07.11.2015 um 19:26 schrieb Neal Gompa:
On Sat, Nov 7, 2015 at 1:23 PM, Reindl Harald
<h.reindl(a)thelounge.net
maybe you did not get "not that i say Fedora should go ahead and
build with -mavx" but we talk about SSE3
talking about a rapid moving distribution like Fedora and at the
same time hestitate to use technology available for a decade is
strange - i guess people plan to run their hardware for 10, 12, 15
years are not using typically a distribution like Fedora
The flip side of it is that Fedora is the foundation for RHEL and other
distributions. Most of the others don't matter so much, but RHEL does,
as that has to support servers and such. But even there, I would suggest
to say that we could say that RHEL 8 shouldn't have a problem bumping
up, since RHEL 7 supports those systems fine and will be supported for 9
more years.
that must be why Redhat dropped i686 completly with RHEL7...
BTW: you converting of plaintext mails to HTML and place a few lines
below a full quote is annoying
真実はいつも一つ！/ Always, there's only one truth!
that's also annoying especially if you place a 1-liner HTML repsonse at
the bottom of a unstripped post, and it's annoying like all sort of
fortune-messages for train bayes-filters with ham
12:27 p.m.
On Sat, Nov 7, 2015 at 7:23 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 07.11.2015 um 19:01 schrieb Kevin Kofler:
>
> Reindl Harald wrote:
>>
>> well, who's to say that we stay forever on a level of CPU
>> feature-support while there are instruction sets available for a whole
>> decade which improve performance, save power in case you need fewer
>> instructions doing the same work?
>>
>> not that i say Fedora should go ahead and build with -mavx but a
>> discussion about SSE3 in 2015 is really odd
>
>
> Sorry, but hardware simply does not get replaced instantly. This is a
> matter
> of both:
> * cost – hardware is not free (as in beer)
that *really* depends
these days (and i talk about hardware from 2011) you can virtualize things
fast, easy and efficient and consolidate machines on more or less cheap
hardware
besides it brings new CPU capabilities it saves a lot of energy:
* one machine instead 2,3,4 or 10 machines
* the new hardware needs so much less power
* your UPS (in case you use one) can be cheaper or lasts longer
* cooling is easier, cheaper and not that loud
some numbers in that context:
in early 2010 we planned a UPS systems to last for around 3 hours, with the
current hardware and after consolidation the same UPS lasts 9 hours now and
the air conditioner has lower load and longer lifetime
the same applies to consumer hardware, my 365/7 running homeserver from 2011
is a power beast and the whole IT needs around 50W while the previous
hardware needed 120W - that's money, that's heat on summer days, that's less
noise and hardddisks don't need to replaced that often because they are
cooler
> * ecology – there are huge landfills in China, India and Africa full of
> electronic trash from Europe and the USA; that gets mined for
> recyclable materials in an extremely polluting way that not
> only
> ruins the environment, but also damages the health of the
> people
> doing the mining (and the most dangerous materials are
> handled
> by children). Materials used for electronic components are
> precious, someone has to recycle them or they would run out
> pretty soon.
that is true but see above
> As a developer who writes mathematical software for a living, I'd love
> being
> able to require AVX-512 right now (https://en.wikipedia.org/wiki/AVX-512 –
> finally a way to specify the rounding mode per operation
> (https://en.wikipedia.org/wiki/EVEX_prefix) rather than through the
> extremely expensive stateful fesetround operations that reset the whole
> prefetch queue, interval arithmetic should become MUCH faster with that),
> but I have to deal with real-world CPUs that are here NOW (so it might
> make
> sense to have runtime detection for AVX-512 only in 1 or 2 years, and
> requiring it is simply not possible within the next decade)
maybe you did not get "not that i say Fedora should go ahead and build with
-mavx" but we talk about SSE3
Compiling everything with sse3 does have a cost (dropping support for
some hardware) but what does it gain us?
Better performance in theory? To convince anyone you have to at least
provide numbers. Otherwise the discussion is a waste of time.
12:40 p.m.
Am 07.11.2015 um 19:27 schrieb drago01:
On Sat, Nov 7, 2015 at 7:23 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> maybe you did not get "not that i say Fedora should go ahead and build with
> -mavx" but we talk about SSE3
Compiling everything with sse3 does have a cost (dropping support for
some hardware) but what does it gain us?
Better performance in theory? To convince anyone you have to at least
provide numbers. Otherwise the discussion is a waste of time
how do you expect to get such numbers?
even if you test whatever application with -msse2 versus -msse3 mosdt
parts of the operating system and the whole libraries are still built
with only SSE2 support
the point is compile a single application with new features won#t gain
that muc 8until you do the same with most libraries used by the
software) but having the whole distribution is a summary with a
completly different behavior than a single test of software xyz
if there would be no difference kernel upstream won't invest that much
time for runtime-cpu-detection (look at the bootlog on different hardware)
here are examples
http://www.phoronix.com/scan.php?page=news_item&px=MTU0MTY
http://www.phoronix.com/scan.php?page=news_item&px=MTI1Njc
1:36 p.m.
On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 07.11.2015 um 19:27 schrieb drago01:
>
> On Sat, Nov 7, 2015 at 7:23 PM, Reindl Harald <h.reindl(a)thelounge.net>
> wrote:
>>
>> maybe you did not get "not that i say Fedora should go ahead and build
>> with
>> -mavx" but we talk about SSE3
>
>
> Compiling everything with sse3 does have a cost (dropping support for
> some hardware) but what does it gain us?
> Better performance in theory? To convince anyone you have to at least
> provide numbers. Otherwise the discussion is a waste of time
how do you expect to get such numbers?
even if you test whatever application with -msse2 versus -msse3 mosdt parts
of the operating system and the whole libraries are still built with only
SSE2 support
the point is compile a single application with new features won#t gain that
muc 8until you do the same with most libraries used by the software) but
having the whole distribution is a summary with a completly different
behavior than a single test of software xyz
Uh no you just have to compile the software any libraries used by the
hot paths of the software you are trying to test.
if there would be no difference kernel upstream won't invest that
much time
for runtime-cpu-detection (look at the bootlog on different hardware)
here are examples http://www.phoronix.com/scan.php?page=news_item&px=MTU0MTY
http://www.phoronix.com/scan.php?page=news_item&px=MTI1Njc
You missed the point completely.
1. AVX != (S)SSE3
There are lots of workloads that would benefit from AVX but SSE3
doesn't add that much (enabling SSE2 on i686 would gain you more for
instance).
2. Runtime detection does not have the cost of dropping support for
specific hardware.
2:24 p.m.
Am 07.11.2015 um 20:36 schrieb drago01:
On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> the point is compile a single application with new features won#t gain that
> muc 8until you do the same with most libraries used by the software) but
> having the whole distribution is a summary with a completly different
> behavior than a single test of software xyz
Uh no you just have to compile the software any libraries used by the
hot paths of the software you are trying to test.
for which one?
that don't show the impact on a complete distribution anyways
> if there would be no difference kernel upstream won't invest
that much time
> for runtime-cpu-detection (look at the bootlog on different hardware)
>
> here are examples http://www.phoronix.com/scan.php?page=news_item&px=MTU0MTY
> http://www.phoronix.com/scan.php?page=news_item&px=MTI1Njc
You missed the point completely.
1. AVX != (S)SSE3
i know that
There are lots of workloads that would benefit from AVX but SSE3
doesn't add that much (enabling SSE2 on i686 would gain you more for
instance).
enable SSE3 don't diable SSE2
so "gain you more" is impossible
2. Runtime detection does not have the cost of dropping support for
specific hardware
runtime detection needs to be implemented in every relevant software at
it's own and hence has a *high cost*
add -msse3 to the default falgs have no costs at all but only an impact
of a unknown amount f *very* outdated hardware which is unlikely running
a bleeding edge distribution
frankly whatever somebody has run on a 10 years old machine can be
easily virtualized and i doubt that many people have a 10 years old
computer as their only device, as far there is something with a core2 or
newer in the house you can virtualize the other machine and save a lot
of energy
6:05 p.m.
Reindl Harald wrote:
frankly whatever somebody has run on a 10 years old machine can be
easily virtualized and i doubt that many people have a 10 years old
computer as their only device, as far there is something with a core2 or
newer in the house you can virtualize the other machine and save a lot
of energy
Virtualization is not a solution for most home users:
* It assumes you have multiple machines to replace with one VM host and VMs.
* Virtualization also does not magically provide you with monitors and
keyboards, which are essential parts of a home system. And the different
seats (where there is more than one computer to begin with) are often in
different rooms. This cannot trivially be replaced by a VM-based setup.
You'd need at least thin clients in addition to the VMs.
As for the "core2 or newer" part: The average Core 2 system is going to run
out of RAM very quickly if you try to run VMs on it. My Core 2 Duo notebook
can do hardware virtualization, and I use that to test live ISOs, but if I
start one Plasma 4 VM in addition to the Plasma 4 host, the RAM (4 GiB) is
already full (and Plasma 5 is reported to be no better and probably worse
there). (I need to allocate 2 GiB for the VM or Plasma will just not work in
it. If you count the same for the host, it's no surprise that the 4 GiB of
RAM end up full.)
You need to think outside of the company scenario you are used to (and even
your home is not a typical home user environment).
Kevin Kofler
6:05 p.m.
Reindl Harald wrote:
frankly whatever somebody has run on a 10 years old machine can be
easily virtualized and i doubt that many people have a 10 years old
computer as their only device, as far there is something with a core2 or
newer in the house you can virtualize the other machine and save a lot
of energy
Virtualization is not a solution for most home users:
* It assumes you have multiple machines to replace with one VM host and VMs.
* Virtualization also does not magically provide you with monitors and
keyboards, which are essential parts of a home system. And the different
seats (where there is more than one computer to begin with) are often in
different rooms. This cannot trivially be replaced by a VM-based setup.
You'd need at least thin clients in addition to the VMs.
As for the "core2 or newer" part: The average Core 2 system is going to run
out of RAM very quickly if you try to run VMs on it. My Core 2 Duo notebook
can do hardware virtualization, and I use that to test live ISOs, but if I
start one Plasma 4 VM in addition to the Plasma 4 host, the RAM (4 GiB) is
already full (and Plasma 5 is reported to be no better and probably worse
there). (I need to allocate 2 GiB for the VM or Plasma will just not work in
it. If you count the same for the host, it's no surprise that the 4 GiB of
RAM end up full.)
You need to think outside of the company scenario you are used to (and even
your home is not a typical home user environment).
Kevin Kofler
2:47 a.m.
On Sat, Nov 7, 2015 at 9:24 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 07.11.2015 um 20:36 schrieb drago01:
>
> On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald <h.reindl(a)thelounge.net>
> wrote:
>>
>> the point is compile a single application with new features won#t gain
>> that
>> muc 8until you do the same with most libraries used by the software) but
>> having the whole distribution is a summary with a completly different
>> behavior than a single test of software xyz
>
>
> Uh no you just have to compile the software any libraries used by the
> hot paths of the software you are trying to test.
for which one?
that don't show the impact on a complete distribution anyways
There is no such thing as "the complete distribution" ... the flags
used to compile libreoffice won't affect http or firefox.
>> if there would be no difference kernel upstream won't
invest that much
>> time
>> for runtime-cpu-detection (look at the bootlog on different hardware)
>>
>> here are examples
>> http://www.phoronix.com/scan.php?page=news_item&px=MTU0MTY
>> http://www.phoronix.com/scan.php?page=news_item&px=MTI1Njc
>
>
> You missed the point completely.
>
> 1. AVX != (S)SSE3
i know that
Then don't cite unrelated links.
> There are lots of workloads that would benefit from AVX but SSE3
> doesn't add that much (enabling SSE2 on i686 would gain you more for
> instance).
enable SSE3 don't diable SSE2
so "gain you more" is impossible
I meant "i686 + SSE2" (which we don't do for the same reason) gains
more than "x86_64 + sse3".
> 2. Runtime detection does not have the cost of dropping support
for
> specific hardware
runtime detection needs to be implemented in every relevant software at it's
own and hence has a *high cost*
Not really its a common practice for software that does matter; even
glibc does it.
add -msse3 to the default falgs have no costs at all but only an
impact of a
unknown amount f *very* outdated hardware which is unlikely running a
bleeding edge distribution
As you just wrote in that very paragraph the cost is dropping support
for a set of hardware.
We have no numbers on how much if at all it would help.
frankly whatever somebody has run on a 10 years old machine can be
easily
virtualized and i doubt that many people have a 10 years old computer as
their only device, as far there is something with a core2 or newer in the
house you can virtualize the other machine and save a lot of energy
Depends on the device. Virtualizing a laptop for instance won't make much sense.
3:35 a.m.
Am 08.11.2015 um 09:47 schrieb drago01:
On Sat, Nov 7, 2015 at 9:24 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> Am 07.11.2015 um 20:36 schrieb drago01:
>>
>> On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald <h.reindl(a)thelounge.net>
>> wrote:
>>>
>>> the point is compile a single application with new features won't gain
>>> that
>>> muc 8until you do the same with most libraries used by the software) but
>>> having the whole distribution is a summary with a completly different
>>> behavior than a single test of software xyz
>>
>>
>> Uh no you just have to compile the software any libraries used by the
>> hot paths of the software you are trying to test.
>
>
> for which one?
> that don't show the impact on a complete distribution anyways
There is no such thing as "the complete distribution" ... the flags
used to compile libreoffice won't affect http or firefox
surely, there is such a thing
on a typical machine is running way more than a single application, you
have (growing) background-noise, currently plasma-desktop eats 25-30% of
a core, X eats some percent and so on
htop shows 7-10% i7-3770 CPU @ 3.40GHz by doing *nothing* expect write
that mail and listen to a MP3 file in the background
the distribution flags are going to be interesting when each of this
pieces is more efficient while you are doing CPU intense tasks also
working more efficient
4:56 a.m.
On Sun, Nov 8, 2015 at 10:35 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 08.11.2015 um 09:47 schrieb drago01:
>
> On Sat, Nov 7, 2015 at 9:24 PM, Reindl Harald <h.reindl(a)thelounge.net>
> wrote:
>>
>> Am 07.11.2015 um 20:36 schrieb drago01:
>>>
>>>
>>> On Sat, Nov 7, 2015 at 7:40 PM, Reindl Harald <h.reindl(a)thelounge.net>
>>> wrote:
>>>>
>>>>
>>>> the point is compile a single application with new features won't
gain
>>>> that
>>>> muc 8until you do the same with most libraries used by the software)
>>>> but
>>>> having the whole distribution is a summary with a completly different
>>>> behavior than a single test of software xyz
>>>
>>>
>>>
>>> Uh no you just have to compile the software any libraries used by the
>>> hot paths of the software you are trying to test.
>>
>>
>>
>> for which one?
>> that don't show the impact on a complete distribution anyways
>
>
> There is no such thing as "the complete distribution" ... the flags
> used to compile libreoffice won't affect http or firefox
surely, there is such a thing
on a typical machine is running way more than a single application, you have
(growing) background-noise, currently plasma-desktop eats 25-30% of a core,
X eats some percent and so on
That sounds like a bug. Throwing in some compiler flags won't fix that.
Fixing that requires 1) finding out what it is doing (profile and/or
get stack traces) 2) fix the code.
htop shows 7-10% i7-3770 CPU @ 3.40GHz by doing *nothing* expect
write that
mail and listen to a MP3 file in the background
The mp3 playback is already making use of SIMD instructions.
5:38 a.m.
Am 08.11.2015 um 11:56 schrieb drago01:
On Sun, Nov 8, 2015 at 10:35 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
>> There is no such thing as "the complete distribution" ... the flags
>> used to compile libreoffice won't affect http or firefox
>
> surely, there is such a thing
>
> on a typical machine is running way more than a single application, you have
> (growing) background-noise, currently plasma-desktop eats 25-30% of a core,
> X eats some percent and so on
That sounds like a bug. Throwing in some compiler flags won't fix that.
Fixing that requires 1) finding out what it is doing (profile and/or
get stack traces) 2) fix the code
software is full of bugs (KDE5 is overwhelmed) all the time and you
missed the point because "used to compile libreoffice won't affect http
or firefox" is simply wrong on a MULTITASKING system sharing one CPU and
so each application will affect others at the end of the day
5:56 p.m.
Reindl Harald wrote:
if there would be no difference kernel upstream won't invest that
much
time for runtime-cpu-detection (look at the bootlog on different hardware)
Exactly BECAUSE performance-critical software normally does runtime
detection (except where upstream is really really lazy), hardcoding a
requirement for newer instruction sets does not buy us anything.
The absence of a portable fallback also makes the software unusable on our
secondary architectures, and in some cases (such as Darktable), even on the
PRIMARY architecture ARM. (Now, whether ARM should be a primary architecture
to begin with is a different matter, but it currently is.)
So I really don't understand those upstreams that provide ONLY platform-
specific vector code with no portable version.
Kevin Kofler
6:01 p.m.
Am 08.11.2015 um 00:56 schrieb Kevin Kofler:
Reindl Harald wrote:
> if there would be no difference kernel upstream won't invest that much
> time for runtime-cpu-detection (look at the bootlog on different hardware)
Exactly BECAUSE performance-critical software normally does runtime
detection (except where upstream is really really lazy), hardcoding a
requirement for newer instruction sets does not buy us anything.
define performance critical
our cms systems got 5 times faster within 6 months by micro-optimizig
each alone would not had any effect
The absence of a portable fallback also makes the software unusable
on our
secondary architectures, and in some cases (such as Darktable), even on the
PRIMARY architecture ARM. (Now, whether ARM should be a primary architecture
to begin with is a different matter, but it currently is.)
So I really don't understand those upstreams that provide ONLY platform-
specific vector code with no portable version
i understand them well - not endless time and write effecient software
without test on dozens of environments older than 10 years - as C
programmer if i would write new code these days i would even go so far
and rely on AVX
yes, that can't be done for a distribution, but i know that all machines
sorrounding me are SandyBridge bases, even the network routers for small
offices and so why would i care about anything else?
3:31 p.m.
On 11/07/2015 10:23 AM, Reindl Harald wrote:
these days (and i talk about hardware from 2011) you can virtualize
things fast, easy and efficient and consolidate machines on more or less
cheap hardware
For servers, sure, but that doesn't work for desktops.
talking about a rapid moving distribution like Fedora and at the
same
time hestitate to use technology available for a decade is strange - i
guess people plan to run their hardware for 10, 12, 15 years are not
using typically a distribution like Fedora
I manage all the IT for a private school. There is a computer lab for
the students to use. They don't have the money to buy new computers,
the computers they have were donated. They are P4 desktops from around
2005 and they have SSE2. I install Fedora on all the computers and
laptops there that I manage. (The older students manage their own
laptops, but even some of them want Fedora installed as well.) I
upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM
they work perfectly for student use.
So yes, I'm using 10 year old hardware with the latest Fedora and it
works great. (I'll update them to F23 next time I'm there.)
4:22 p.m.
Am 09.11.2015 um 22:31 schrieb Samuel Sieb:
On 11/07/2015 10:23 AM, Reindl Harald wrote:
> these days (and i talk about hardware from 2011) you can virtualize
> things fast, easy and efficient and consolidate machines on more or less
> cheap hardware
>
For servers, sure, but that doesn't work for desktops.
how many physical desktops does one use?
> talking about a rapid moving distribution like Fedora and at the
same
> time hestitate to use technology available for a decade is strange - i
> guess people plan to run their hardware for 10, 12, 15 years are not
> using typically a distribution like Fedora
>
I manage all the IT for a private school. There is a computer lab for
the students to use. They don't have the money to buy new computers,
the computers they have were donated. They are P4 desktops from around
2005 and they have SSE2. I install Fedora on all the computers and
laptops there that I manage. (The older students manage their own
laptops, but even some of them want Fedora installed as well.) I
upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM
they work perfectly for student use.
So yes, I'm using 10 year old hardware with the latest Fedora and it
works great. (I'll update them to F23 next time I'm there.)
SSE3 was introduced in 2004
well, i tell you know the same which was told me all the time before the
server spin "maybe you are using the wrong operating system" and frankly
for schools you typically use thin-cients one machine
with the agrumentations of this thread hardware manufactuers could stop
develop new hardware capabilities if we wait 20 years to consider make
them default - in the IT 10 years is virtually forever and *yes* capable
hardware these days is cheap if you don't need that much performance
4:57 p.m.
On 11/09/2015 02:22 PM, Reindl Harald wrote:
Am 09.11.2015 um 22:31 schrieb Samuel Sieb:
> I manage all the IT for a private school. There is a computer lab for
> the students to use. They don't have the money to buy new computers,
> the computers they have were donated. They are P4 desktops from around
> 2005 and they have SSE2. I install Fedora on all the computers and
> laptops there that I manage. (The older students manage their own
> laptops, but even some of them want Fedora installed as well.) I
> upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM
> they work perfectly for student use.
>
> So yes, I'm using 10 year old hardware with the latest Fedora and it
> works great. (I'll update them to F23 next time I'm there.)
well, i tell you know the same which was told me all the time before the
server spin "maybe you are using the wrong operating system" and frankly
for schools you typically use thin-cients one machine
I really wonder where you come from. I have never seen a grade school,
public or private, that uses thin-clients. As for "wrong operating
system", do you have any suggestions for a different distribution that
is as up-to-date as Fedora that would work on these computers?
I've always run Fedora on my servers as well.
with the agrumentations of this thread hardware manufactuers could
stop
develop new hardware capabilities if we wait 20 years to consider make
them default - in the IT 10 years is virtually forever and *yes* capable
hardware these days is cheap if you don't need that much performance
"Cheap"? I might be able to able to build a computer for $300, I
haven't actually checked lately, that's what it was a few years ago.
But for a computer lab? Why would they want to try to come up with that
much money when the existing computers work perfectly?
5:34 p.m.
Am 09.11.2015 um 23:57 schrieb Samuel Sieb:
On 11/09/2015 02:22 PM, Reindl Harald wrote:
> Am 09.11.2015 um 22:31 schrieb Samuel Sieb:
>> So yes, I'm using 10 year old hardware with the latest Fedora and it
>> works great. (I'll update them to F23 next time I'm there.)
>
> well, i tell you know the same which was told me all the time before the
> server spin "maybe you are using the wrong operating system" and frankly
> for schools you typically use thin-cients one machine
>
I really wonder where you come from. I have never seen a grade school,
public or private, that uses thin-clients
http://www8.hp.com/us/en/thin-clients/education.html
As for "wrong operating
system", do you have any suggestions for a different distribution that
is as up-to-date as Fedora that would work on these computers?
i don't get why i need the most up-to-date software when at the same
time i don't care about my hardware and run a P4 heater because that
indicates low requirements
about money: with the energy costs i saved going away from P4 computers
many years ago my current one is already paied
I've always run Fedora on my servers as well
me too
5:52 p.m.
On Tue, Nov 10, 2015 at 1:34 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
about money: with the energy costs i saved going away from P4
computers many
years ago my current one is already paied
Nobody is saying that a newer computer won't save you money on the
power bill. What they have repeatedly stated and for some (first
world, perhaps?) reason you refuse to acknowledge, is that you can't
trade future power use for a new computer; you have to pay up front,
it's a sort of investment, that not everyone is affluent enough to
make. Not every person or institution can afford to get a new Phenom
or Xeon or whatever every year, or even every X years.
What exactly do you suggest these people do? Get LFS, Gentoo or Arch
and clear all incompatible flags? Or should they apply for a loan to
their bank, detailing the ROI from reduced power usage?
2:23 a.m.
Am 10.11.2015 um 00:52 schrieb Alexander Ploumistos:
On Tue, Nov 10, 2015 at 1:34 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> about money: with the energy costs i saved going away from P4 computers many
> years ago my current one is already paied
Nobody is saying that a newer computer won't save you money on the
power bill. What they have repeatedly stated and for some (first
world, perhaps?) reason you refuse to acknowledge, is that you can't
trade future power use for a new computer; you have to pay up front,
it's a sort of investment, that not everyone is affluent enough to
make. Not every person or institution can afford to get a new Phenom
or Xeon or whatever every year, or even every X years.
What exactly do you suggest these people do? Get LFS, Gentoo or Arch
and clear all incompatible flags? Or should they apply for a loan to
their bank, detailing the ROI from reduced power usage?
i would suggest NOT use a fast moving distribution like Fedora for such
antique hardware
why do you ask again when i statet *more than once* that i have zero
understaind for combine more than 10 years old hardware with a
bleeding-edge distribution and then demand the bleeding-edge
distribution to support that hardware the next 20 years instead move forward
6:31 p.m.
On 11/09/2015 03:34 PM, Reindl Harald wrote:
Am 09.11.2015 um 23:57 schrieb Samuel Sieb:
> On 11/09/2015 02:22 PM, Reindl Harald wrote:
>> Am 09.11.2015 um 22:31 schrieb Samuel Sieb:
>>> So yes, I'm using 10 year old hardware with the latest Fedora and it
>>> works great. (I'll update them to F23 next time I'm there.)
>>
>> well, i tell you know the same which was told me all the time before the
>> server spin "maybe you are using the wrong operating system" and
frankly
>> for schools you typically use thin-cients one machine
>>
> I really wonder where you come from. I have never seen a grade school,
> public or private, that uses thin-clients
http://www8.hp.com/us/en/thin-clients/education.html
I didn't say they didn't exist. I've certainly heard of them and seen
them in various places. I said in all the schools I've been in, I've
never seen any actually deployed.
> As for "wrong operating
> system", do you have any suggestions for a different distribution that
> is as up-to-date as Fedora that would work on these computers?
i don't get why i need the most up-to-date software when at the same
time i don't care about my hardware and run a P4 heater because that
indicates low requirements
What does low requirements have to do with up-to-date software? Why
should I have to use an old version of LibreOffice just because I'm
using a 10 year old computer when the latest version works perfectly well?
about money: with the energy costs i saved going away from P4
computers
many years ago my current one is already paied
I would be very surprised if the power savings are really that much. I
will do a power check the next time I'm on site. Besides that,
electricity is cheap here so it would take a very long time to recoup
the cost of new computers.
5:18 p.m.
Reindl Harald composed on 2015-11-09 23:22 (UTC+0100):
*yes* capable hardware these days is cheap if you don't need that
much performance
Unless and until hardware prices drop to zero, there will be users for whom
any cost is an insurmountable hurdle. And, there will remain users content
with existing capability who only wish to upgrade software in order to
maintain security and/or access to software demanded by their needs. Ordinary
users don't care when SSE3 was introduced. They just want to keep using what
ain't broke as long as possible. Many don't see justification for capability
of newer hardware causing software to demand that capability either,
particularly when it breaks arch portability or produces no more than a
modest, or no, detectable performance improvement, among them, me.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
3:20 a.m.
On 2015-11-09, Reindl Harald <h.reindl(a)thelounge.net> wrote:
server spin "maybe you are using the wrong operating
system" and frankly
for schools you typically use thin-cients one machine
Unfortunatelly recent desktop environments require OpenGL. Recent web
pages require hardware-accelareted video decoding. Not so recent widget
toolkits started to use pixmaps instead of X server-side rendering. Users
want to use sound output and USB devices.
This makes thin clients really hard to implement. Especially if all the
network-oriented features Linux deskop had are becoming obsolete.
What could work is a diskless thick client. But these old computers
usually have 100-Mbps NIC. That's 5 times slower than local ATA disk.
This does not matter when everything is loaded, but it hurts when
starting programs. Especially in classes where all students log in and
to the same stuff at the same time.
-- Petr
11:30 a.m.
Felix Miata wrote:
> I have a computer without SSE3. It runs Fedora just fine. I
initially had
> 1 GiB of RAM in it, I upgraded it to 3 GiB.
I have approximately 40 Fedora installations on 32 bit CPUs. About half of
those are on Prescotts. I'm unable to notice that those with more than 1G
RAM run any better than those with more RAM.
There are mainly 2 reasons I had to upgrade the RAM:
1. Akonadi / KMail 2.
2. "Modern" websites with massive abuse of inline images.
Both of those eat lots and lots of RAM.
I am able to notice that the older, slower ones that do have SSE2 are
able
to run, but with Plasma 5, those are very slow. Those do run respectably
with lighter WMs/DEs.
The main limiting factor there is probably not the CPU, but the GPU. If your
GPU does not support OpenGL 2 (OpenGL 1.x is not enough because GLSL shaders
are required), then QML 2 and thus Plasma 5 will fall back to software
rendering through the llvmpipe, which of course on an old CPU is not
impressive speed-wise.
What might help is disabling all the animations that can be disabled.
For those without SSE2, Plasma 5 is completely unusable, but OK with
any
of the lightweights.
Without SSE2, you additionally also lose the QML/JavaScript JIT in QML 2.
(There is no implementation of the JIT for the 387 FPU instructions, only
for the SSE2 ones.) So you also get an interpreter in C++ there. (At least
there IS a fallback, unlike in V8 and thus Chromium/QtWebEngine.) And of
course the llvmpipe will also be slower without SSE2 instructions. And they
will contend the CPU. There is not much Fedora can do about that, it is a
result of the design choices in upstream Qt.
Kevin Kofler
11:47 a.m.
Am 07.11.2015 um 18:30 schrieb Kevin Kofler:
Felix Miata wrote:
>> I have a computer without SSE3. It runs Fedora just fine. I initially had
>> 1 GiB of RAM in it, I upgraded it to 3 GiB.
>
> I have approximately 40 Fedora installations on 32 bit CPUs. About half of
> those are on Prescotts. I'm unable to notice that those with more than 1G
> RAM run any better than those with more RAM.
There are mainly 2 reasons I had to upgrade the RAM:
1. Akonadi / KMail 2.
2. "Modern" websites with massive abuse of inline images.
Both of those eat lots and lots of RAM
not to forget that we now have many cases where GTK2/GTK3/QT4/QT5 are
loaded at the same time, with that memory not so long ago a whole
graphical operating system including applications is working fine
_____________________
below 1.5 GB RAM no way at all
frankly we recently upgraded our server-hardware and changed the
clustermode to sandybridge, all seemed to work fine (except
https://bugzilla.redhat.com/show_bug.cgi?id=1269014 which is a very
interesting bug)
there are tiny backup VM's with 1024 Mb RAM over years for each
production machine running a mysqld-slave and hourly rsync of the
userdata for later offsite-backups from there
day 1 1:16: one of them crashed and got restarted by VMware HA
day 2 1:16: one of them crashed and got restarted by VMware HA
well, the screenshot vmware makes from the VT showed page allocation
errors and finally i realized that the once per day added
--delay-updates rsync param on the new hardware for whatever reason
triggered that errors
increased *any* virtual machine to at least 1.5 GB RAM - no problems for
2 months now
3:17 p.m.
Felix Miata wrote:
For those without
SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh
<nod>.
Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
about pushing the minimum i686 fedora spec to include sse2, but fesco was
against that idea at the time.
-- Rex
3:20 p.m.
Am 08.11.2015 um 22:17 schrieb Rex Dieter:
Felix Miata wrote:
> For those without
> SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh
<nod>.
Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
about pushing the minimum i686 fedora spec to include sse2, but fesco was
against that idea at the time
that was years ago, -msse2 is now the default
that thread is about -msse3 available for a full decade
3:21 p.m.
On Sun, Nov 8, 2015 at 10:20 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 08.11.2015 um 22:17 schrieb Rex Dieter:
>
> Felix Miata wrote:
>
>> For those without
>> SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh
>
>
> <nod>.
>
> Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
> about pushing the minimum i686 fedora spec to include sse2, but fesco was
> against that idea at the time
that was years ago, -msse2 is now the default
No as I said before its not. (Note the "i686").
On x86_64 you don't have to pass -msee2. SSE2 is part of the x86_64 ABI.
3:27 p.m.
Am 08.11.2015 um 22:21 schrieb drago01:
On Sun, Nov 8, 2015 at 10:20 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
>
> Am 08.11.2015 um 22:17 schrieb Rex Dieter:
>>
>> Felix Miata wrote:
>>
>>> For those without
>>> SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh
>>
>> Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
>> about pushing the minimum i686 fedora spec to include sse2, but fesco was
>> against that idea at the time
>
>
> that was years ago, -msse2 is now the default
No as I said before its not. (Note the "i686").
On x86_64 you don't have to pass -msee2. SSE2 is part of the x86_64 ABI
indeed, the defaults even don't contain -msse2 in 2015
ridiculous
[builduser@buildserver64:~]$ cat /usr/lib/rpm/rpmrc | grep i686
optflags: i386 -O2 -g -march=i386 -mtune=i686
3:45 p.m.
On 11/08/2015 10:17 PM, Rex Dieter wrote:
Felix Miata wrote:
> For those without
> SSE2, Plasma 5 is completely unusable, but OK with any of the lightweigh
<nod>.
Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
about pushing the minimum i686 fedora spec to include sse2, but fesco was
against that idea at the time.
I wonder if it might be a good time to bump the i686 minimal
requirements for F24 to include sse2. Not for performance reasons, but
for compatibility: almost all developers are on x86_64 these days and
i686 is pretty much just limping along. If we include sse2 on i686, that
removes another difference between x86_64 and i686 and makes things
easier for us as a downstream.
Apparently quite a few upstreams these days consider sse2 as a minimal
requirement and it seems more and more that Fedora packagers need to
work this around if we don't follow the lead.
I don't think this is worth doing for performance reasons. I don't think
a few percentage of possible gain in micro benchmarks is worth it, but
if it saves some hundreds of hours of developer time for people who are
working on Fedora and don't have to work around missing sse2, I'd say
it's very well worth the cost of losing ancient CPU support.
--
Kalev
8 a.m.
Kalev Lember wrote:
I wonder if it might be a good time to bump the i686 minimal
requirements for F24 to include sse2. Not for performance reasons, but
for compatibility: almost all developers are on x86_64 these days and
i686 is pretty much just limping along. If we include sse2 on i686, that
removes another difference between x86_64 and i686 and makes things
easier for us as a downstream.
I don't think this difference is a real issue.
Apparently quite a few upstreams these days consider sse2 as a
minimal
requirement and it seems more and more that Fedora packagers need to
work this around if we don't follow the lead.
This is more of a problem.
This is only a minor annoyance where a portable fallback exists (we can just
ship the portable C/C++ version in /usr/lib and the SSE2 version in
/usr/lib/sse2, as we are doing with Qt 5 QtDeclarative). The real problem is
software which has no portable fallback at all, such as Chromium/QtWebEngine
or Darktable. This completely screws not only non-SSE2 x86, but also all
secondary architectures, and in some cases such as Darktable, even the
primary architecture ARM. It is unfortunate that the number of such non-
portable software seems increasing lately. Portability to any and all CPU
architectures used to be a big selling point for Free Software. These days,
more and more projects seem happy to sacrifice this on the altar of
performance. :-(
I think dropping support for non-SSE2 in all of Fedora would send entirely
the wrong message to those upstreams and only contribute to the surge of
non-portable software.
That said, we need a formal policy to deal with such software, which IMHO
should be treated just like an ExcludeArch, except that you should not
actually ExcludeArch the package as long as it supports SOME CPUs of that
architecture. It should still be put on the relevant ExcludeArch tracker
though, and if a fix/workaround exists, applying it should be required.
I don't think this is worth doing for performance reasons. I
don't think
a few percentage of possible gain in micro benchmarks is worth it, but
if it saves some hundreds of hours of developer time for people who are
working on Fedora and don't have to work around missing sse2, I'd say
it's very well worth the cost of losing ancient CPU support.
That would unfortunately decrease the usefulness of the i686 distribution a
lot. Given that we want to push users of 64-bit-capable machines to the
x86_64 version, it would leave basically only one generation of x86 machines
for the i686 distribution: the Pentium 4 Northwood generation, including one
or two generation(s) of AMD CPUs from the same time. Add to that some newish
low-end Atoms where they removed x86_64 support "to save power" (actually to
introduce an artificial market segmentation), no idea how popular those are.
Everything else that has SSE2 also has 64-bit.
Unfortunately, that prerogative ("all 64-bit-capable machines should use 64-
bit binaries") is not universally shared by upstreams. For example, Qt sees
the primary target of their 32-binaries as being modern machines that would
also support x86_64, but where the user elected to use 32-bit for whatever
reason, not old 32-bit-only machines as we see it. That is the primary
reason for the different stance on non-SSE2 support. (That said, Qt, outside
of QtWebEngine, does not actually REQUIRE SSE2. They just enable its use by
default.) My argument that the default option ought to be the safe, portable
one (non-SSE2) was rejected on the grounds of performance on what they think
are the vast majority of machines using 32-bit Qt (whereas I argued that it
was only really one generation, but as I wrote above, they have a completely
different conception of the purpose of 32-bit binaries).
Kevin Kofler
1:48 a.m.
An update on this:
Kevin Kofler wrote:
This is only a minor annoyance where a portable fallback exists (we
can
just ship the portable C/C++ version in /usr/lib and the SSE2 version in
/usr/lib/sse2, as we are doing with Qt 5 QtDeclarative). The real problem
is software which has no portable fallback at all, such as
Chromium/QtWebEngine or Darktable. This completely screws not only
non-SSE2 x86, but also all secondary architectures, and in some cases such
as Darktable, even the primary architecture ARM. It is unfortunate that
the number of such non- portable software seems increasing lately.
Portability to any and all CPU architectures used to be a big selling
point for Free Software. These days, more and more projects seem happy to
sacrifice this on the altar of performance. :-(
I think I have what it takes to get QtWebEngine working on non-SSE2 now:
1. https://bugzilla.redhat.com/show_bug.cgi?id=1293190
2. https://bugzilla.redhat.com/show_bug.cgi?id=1244196#c24
Thankfully, V8 actually does support non-SSE2 x86: Shortly after support was
removed from the "ia32" target, it was readded as a separate "x87"
one. So
only Chromium/QtWebEngine needs patching (because they started requiring
SSE2 in their own code).
That said, this only helps 32-bit x86. Most secondary architectures are
still screwed, because V8 does not have portable C/C++ fallback code (unlike
Chromium's own code).
Kevin Kofler
7:19 a.m.
Rex Dieter wrote:
Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig
asked
about pushing the minimum i686 fedora spec to include sse2, but fesco was
against that idea at the time.
For what it's worth, I was against it. Using /usr/lib/sse2 as we do now
works just fine as a solution to this problem. People without SSE2 at least
get a distribution that works for them, and even Qt 5 builds (except the
soon-to-be-packaged QtWebEngine module, sadly, unless/until something
happens at its upstream to fix the V8 non-portability) that work, albeit
slowly. LXQt should even work at an acceptable speed, given that they use
QtWidgets for their UI, which does not need the QML 2 interpreter or JIT (so
you don't get the non-JIT interpreter). And people with SSE2 get SSE2-
optimized .so binaries where it matters.
The only thing the duplication costs is some disk space, but that is the
price of portability.
Kevin Kofler
3:19 a.m.
A few lines of IRC chat, Freenode #darktable. Hanatos is Darktable
project founder.
[09:17] <hanatos_> ``requiring SSE3 is not really allowed ''
[09:17] <hanatos_> so much bundled cluelessness :/
[09:19] <hanatos_> Germano: re 32-bit
[09:19] <hanatos_> the sse thing is one thing
[09:20] <hanatos_> the other is the very limited virtual address space
(2G really)
[09:20] <hanatos_> everybody coding anything half way serious will tell
you the same story
[09:20] <hanatos_> (rawtherapee has the same issues iirc)
[09:20] <hanatos_> our old cache was allocing one big chunk of memory at
startup and maintained it manually
[09:20] <hanatos_> essentially duplicating a poor man's malloc,
specialised for our thumbnail caches
[09:21] <hanatos_> the new cache is much faster and easier to read
[09:21] <hanatos_> but based on malloc/free
[09:21] <hanatos_> which means your virtual address space (not the
physical one mapping to your ram)
[09:21] <hanatos_> will get fragmented and you quickly start addressing
blocks above the 10G range
[09:22] <hanatos_> which may not be a problem, even on systems with only
2G of physical ram, because blocks have been freed in between. it's just
on 32-bit systems you can't address it any more and die
[09:22] <boucman> basically, at this point, DT makes no sense on x86,
except maybe dt-cli
[09:22] <hanatos_> which is a similar argument as the sse3 is.
[09:22] <hanatos_> it's just not a worthwhile experience running this
software on this kind of hardware
[09:22] <hanatos_> boucman: yes, that.
[09:23] <Artefact2> hanatos_: I think jmalloc is also more clever than
glibc malloc wrt fragmentation. that's why blender uses it, afaik
[09:24] <Artefact2> *je
[09:24] <hanatos_> Germano: so i'd like to contradict the `upstream
doesn't care' bit
[09:25] <hanatos_> upstream does care.
[09:25] <hanatos_> just not about random principles and guidelines
[09:25] <hanatos_> but about how well darktable runs
[09:25] <hanatos_> Artefact2: jemalloc you mean
[09:25] <Artefact2> hanatos_: yes
[09:25] <hanatos_> yes, it's mostly multithreaded/
[09:25] <hanatos_> block per thread
[09:25] <hanatos_> might be worthwhile when running many threads for
thumbnail gen
[09:25] <hanatos_> but honestly i doubt it
[09:26] <hanatos_> it speeds up another piece of code i wrote
[09:26] <hanatos_> which uses many 10s of 1000s of malloc calls per second..
[09:26] <hanatos_> we don't do that in dt
[09:26] <hanatos_> (or tcmalloc for that matter)
[09:26] <hanatos_> simple enough to try with an LD_PRELOAD
[09:26] <Artefact2> oh yeah. calling malloc this many times is a bad
idea anyway
[09:32] <hanatos_> the alternative would have been allocate ridiculous
amounts of memory up front
[09:32] <hanatos_> bad idea, too
[09:32] <hanatos_> but if you have a better solution i'd sure like to
hear it :)
[09:32] <hanatos_> the problem is to construct a binary search tree
[09:32] <Artefact2> i'm not a memory guru, sadly :|
[09:32] <hanatos_> in parallel
[09:32] <hanatos_> so you start at the root and push the children as new
jobs (malloc job_t)
[09:32] <hanatos_> and so on
[09:33] <hanatos_> it's millions of nodes total, so you don't want to
allocate them up front
[09:33] <Artefact2> maybe a compromise. allocate a pool that can store,
say 10 jobs at a time
[09:34] <hanatos_> (and yes, i would agree.. calling malloc is almost
always a bad idea, unless you can't avoid it)
[09:34] <hanatos_> but see.. that pool per thread.. that's exactly what
jemalloc/tcmalloc do
[09:34] <Artefact2> this way you reduce the allocator load by a factor
of 10, while still not allocating huge amounts of contiguous memory
[09:35] <Artefact2> maybe the issue is elsewhere. what are you doing
millions of? is it possible to make "bigger" jobs and have less of them?
ie a smaller tree
[09:38] <hanatos_> nope, can't touch the tree
[09:38] <hanatos_> its some spatial acceleration structure for ray tracing
[09:39] <hanatos_> it's been optimised for fast ray tracing for many years
[09:39] <Artefact2> are we still talking about darktable? didn't know it
needed a raytracer
[09:40] <hanatos_> no, different piece of code.. as i said, i don't
think darktable needs thread-cached malloc
[10:11] <hanatos_> Germano: also feel free to refer those guys here to
us if they have questions. seems to me that some direct contact may be
better.
3:49 a.m.
07.11.2015, 12:19, "Germano Massullo" <germano.massullo(a)gmail.com>:
[10:11] <hanatos_> Germano: also feel free to refer those guys
here to
us if they have questions. seems to me that some direct contact may be
better.
What those guys?
The only one who wants to kill off darktable is you, Germano. You almost succeeded last
time and had it removed, before the community stepped in. Why are you trying to repeat it
again?
Seriously. Just let darktable be.
7:38 a.m.
Germano Massullo wrote:
[09:22] <boucman> basically, at this point, DT makes no sense
on x86,
except maybe dt-cli
Well, I think that, in the absence of a real portability fix, building the
package (with SSE3, or in general the minimum instruction set it supports)
is better than ExcludeArch.
The goal of the portability policies is to make our packages useful to an as
wide range of users as possible. If we interpret them as meaning that
ExcludeArch is preferred to shipping a package that requires something like
SSE3, they become counterproductive.
Kevin Kofler
1:36 a.m.
A clear example of the mentioned problems for Darktable 32 bit
http://redmine.darktable.org/issues/10717
3043
days inactive
3088
days old
73 comments
20 participants
participants (20)
-
Alexander Ploumistos -
Branko Grubic -
drago01 -
Felix Miata -
Fred New -
Germano Massullo -
Kalev Lember -
Kevin Kofler -
Luya Tshimbalanga -
Neal Gompa -
Pete Walter -
Petr Pisar -
Przemek Klosowski -
Ralf Corsepius -
Reindl Harald -
Rex Dieter -
Samuel Sieb -
Stephen John Smoogen -
Stuart Gathman -
Tom Hughes