Eduard Bloch <[EMAIL PROTECTED]> writes:
> #include
> * Tobias Wolter [Sun, Nov 09 2003, 04:52:54PM]:
> > On 2003-11-09T16:19:21+0100 (Sunday), Eduard Bloch wrote:
> > > * Tobias Wolter [Sun, Nov 09 2003, 03:47:15PM]:
> > > >> # time bzip2 -9 < out.wav > /dev/null
> > > > [...]
> > > >> # time /
Eduard Bloch <[EMAIL PROTECTED]> writes:
> #include
> * Glenn McGrath [Sun, Nov 09 2003, 09:53:26AM]:
>
> > > We're all very interested in *real* evidence here, because there
> > > hasn't been any in the past. If you don't have any evidence, you can
> > > expect people to call bullshit on this.
On Monday 10 November 2003 23:56, Darren Salt wrote:
> Converting some multiplies to shifts (or shift plus some other arithmetic),
> or arranging that one of the source registers normally contains the lower
> value, can also help. (At least, on ARM...)
Gcc already does do this when appropriate (mu
Glenn McGrath wrote:
A program that is CPU bound will benefit from compiler optimisations.
Define "compiler optimisations".
The teoretical "compiler optimisations" would "run" your programs
faster, but... too much people spoke about optimisation without knowing
what it means.
Do you think -O3 wo
On Tue, 11 Nov 2003, Andrew Suffield wrote:
> On Tue, Nov 11, 2003 at 09:24:35PM +1100, Hamish Moffatt wrote:
> > On Mon, Nov 10, 2003 at 05:08:48PM -0600, Joe Wreschnig wrote:
> > > Of course, I'm far from a compiler and chip design expert (or even
> > > novice); this is what I remember from my cl
On Tue, Nov 11, 2003 at 10:19:58AM +, Will Newton wrote:
> On Monday 10 Nov 2003 19:54, Andrew Suffield wrote:
>
> > We refuse to accept it blindly because it's wrong. There have been
> > cases when architecture-specific optimisations have made programs run
> > slower (recently the instruction
On Tue, Nov 11, 2003 at 09:24:35PM +1100, Hamish Moffatt wrote:
> On Mon, Nov 10, 2003 at 05:08:48PM -0600, Joe Wreschnig wrote:
> > Of course, I'm far from a compiler and chip design expert (or even
> > novice); this is what I remember from my classes last year. :) But it
> > shows how complicated
On Monday 10 Nov 2003 19:54, Andrew Suffield wrote:
> We refuse to accept it blindly because it's wrong. There have been
> cases when architecture-specific optimisations have made programs run
> slower (recently the instruction ordering for that via i686 chip
> comes to mind); GCC gets it wrong fr
On Mon, Nov 10, 2003 at 05:08:48PM -0600, Joe Wreschnig wrote:
> Of course, I'm far from a compiler and chip design expert (or even
> novice); this is what I remember from my classes last year. :) But it
> shows how complicated optimizing compilers can get, and why you can't
> say any optimization
I demand that Adam Heath may or may not have written...
> On Mon, 10 Nov 2003, Joe Wreschnig wrote:
>> A program that is CPU-bound *and* can be encoded more efficiently will
>> benefit from compiler optimizations. Some CPU bound things just aren't
>> going to be helped much by vectorization, instr
On Mon, 2003-11-10 at 16:27, Adam Heath wrote:
> On Mon, 10 Nov 2003, Joe Wreschnig wrote:
>
> > A program that is CPU-bound *and* can be encoded more efficiently will
> > benefit from compiler optimizations. Some CPU bound things just aren't
> > going to be helped much by vectorization, instructi
On Mon, 10 Nov 2003, Joe Wreschnig wrote:
> A program that is CPU-bound *and* can be encoded more efficiently will
> benefit from compiler optimizations. Some CPU bound things just aren't
> going to be helped much by vectorization, instruction reordering, etc. I
> mean, integer multiply is integer
On Mon, 2003-11-10 at 15:46, Glenn McGrath wrote:
> A program that is CPU bound will benefit from compiler optimisations.
A program that is CPU-bound *and* can be encoded more efficiently will
benefit from compiler optimizations. Some CPU bound things just aren't
going to be helped much by vectori
On Tue, Nov 11, 2003 at 08:46:50AM +1100, Glenn McGrath wrote:
> A program that is CPU bound will benefit from compiler optimisations.
It is not wise to make generalizations about the effects of compiler
optimizations, because they vary widely from one chunk of code to the next.
> Other than exp
A program that is CPU bound will benefit from compiler optimisations.
Compiler optimisation wont make any noticable improvment on largely IO
bound applications.
I was deliberatly speaking generally because it is a grey area, there
are very few practical programs that are completely CPU bound or
c
On Monday 10 November 2003 19:54, Andrew Suffield wrote:
> Sometimes it even causes programs to stop functioning entirely
> (athlon and p4, gcc 3.0.0 until sometime in 3.1.x).
Especially on other architechtures (like arm) that have seen some horrific
bugs creep into gcc to do with certain optimis
[If, after reading this mail, you continue to make the same invalid
assertions and broken arguments, then you should not be surprised when
people write you off as a troll].
On Mon, Nov 10, 2003 at 09:01:01AM +1100, Glenn McGrath wrote:
> On Mon, 10 Nov 2003 01:32:44 +0800
> Cameron Patrick <[EMAIL
> On Sat, Nov 08, 2003 at 10:58:03AM +0100, Eduard Bloch wrote:
> > #include
> >
> > * Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:
> > > Optimization is a serious issue too. Unlike most user space
> > > software, using 386 kernel on modern PC will cause serious
> > > performance loose.
On Sat, Nov 08, 2003 at 10:58:03AM +0100, Eduard Bloch wrote:
> #include
> * Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:
> > Optimization is a serious issue too. Unlike most user space software, using
> > 386 kernel on modern PC will cause serious performance loose. Especially if
> > yo
On Mon, 10 Nov 2003 01:32:44 +0800
Cameron Patrick <[EMAIL PROTECTED]> wrote:
> Well, Glenn didn't really put many words around his output from timing
> bzip2, so any claims about what he was trying to prove are
> speculative.
The point i was trying to make is that architecture specific
optimisat
On Sun, 9 Nov 2003 17:39:24 +
Andrew Suffield <[EMAIL PROTECTED]> wrote:
> Apparently you entirely fail to understand then, because that's not
> what I said. Please refrain from commenting on issues in a language
> which you cannot comprehend.
Yes your majesty.
There are none so blind as tho
On Sun, Nov 09, 2003 at 09:18:34AM +1100, Glenn McGrath wrote:
> On Sat, 8 Nov 2003 12:33:15 +
> Andrew Suffield <[EMAIL PROTECTED]> wrote:
>
> > Please provide carefully documented evidence of the performance gains
> > that you are claiming, not handwaving. Evidence of a difference is not
> >
On Sun, Nov 09, 2003 at 05:14:44PM +0100, Eduard Bloch wrote:
| That is not a summary of the thread, that is a summary of YOUR
| interpretation of the thread.
I won't dispute this. :-)
| > Eduard: Optimising kernel code doesn't help as other hardware is the
| > limiting factor.
|
| No. The h
On Sun, Nov 09, 2003 at 09:53:26AM +1100, Glenn McGrath wrote:
> On Sat, 8 Nov 2003 12:33:15 +
> Andrew Suffield <[EMAIL PROTECTED]> wrote:
>
> > We're all very interested in *real* evidence here, because there
> > hasn't been any in the past. If you don't have any evidence, you can
> > expect
#include
* Tobias Wolter [Sun, Nov 09 2003, 04:52:54PM]:
> On 2003-11-09T16:19:21+0100 (Sunday), Eduard Bloch wrote:
> > * Tobias Wolter [Sun, Nov 09 2003, 03:47:15PM]:
> > >> # time bzip2 -9 < out.wav > /dev/null
> > > [...]
> > >> # time /tmp/bzip2-1.0.2/bzip2 -9 < out.wav > /dev/null
> > >> D
#include
* Cameron Patrick [Sun, Nov 09 2003, 11:52:41PM]:
> On Sun, Nov 09, 2003 at 03:37:11PM +0100, Eduard Bloch wrote:
> | #include
> | * Michael Poole [Sun, Nov 09 2003, 09:22:13AM]:
> | > Eduard Bloch writes:
> | >
> | > > Do you see now that 8 of your 10 percent come directly from the
> |
On Sat, Nov 08, 2003 at 06:59:39PM +0100, Mathieu Roy wrote:
> Andrew Suffield <[EMAIL PROTECTED]> a tapoté :
>
> > On Sat, Nov 08, 2003 at 01:58:29PM +0100, Mateusz Papiernik wrote:
> >> Andrew Suffield wrote:
> >> >We're all very interested in *real* evidence here, because there
> >> >hasn't bee
On 2003-11-09T16:19:21+0100 (Sunday), Eduard Bloch wrote:
> * Tobias Wolter [Sun, Nov 09 2003, 03:47:15PM]:
> >> # time bzip2 -9 < out.wav > /dev/null
> > [...]
> >> # time /tmp/bzip2-1.0.2/bzip2 -9 < out.wav > /dev/null
> >> Do you see now that 8 of your 10 percent come directly from the
> >> ap
On Sun, Nov 09, 2003 at 03:37:11PM +0100, Eduard Bloch wrote:
| #include
| * Michael Poole [Sun, Nov 09 2003, 09:22:13AM]:
| > Eduard Bloch writes:
| >
| > > Do you see now that 8 of your 10 percent come directly from the
| > > application code and other two maybe from the optimized libc? There i
#include
* Tobias Wolter [Sun, Nov 09 2003, 03:47:15PM]:
> > # time bzip2 -9 < out.wav > /dev/null
> [...]
> > # time /tmp/bzip2-1.0.2/bzip2 -9 < out.wav > /dev/null
> > Do you see now that 8 of your 10 percent come directly from the
> > application code and other two maybe from the optimized l
On 2003-11-09T14:46:38+0100 (Sunday), Eduard Bloch wrote:
> # time bzip2 -9 < out.wav > /dev/null
[...]
> # time /tmp/bzip2-1.0.2/bzip2 -9 < out.wav > /dev/null
> Do you see now that 8 of your 10 percent come directly from the
> application code and other two maybe from the optimized libc?
You
#include
* Michael Poole [Sun, Nov 09 2003, 09:22:13AM]:
> Eduard Bloch writes:
>
> > Do you see now that 8 of your 10 percent come directly from the
> > application code and other two maybe from the optimized libc? There is
> > not{hing| much} we have won using an optimised kernel. But the place
Eduard Bloch writes:
> Do you see now that 8 of your 10 percent come directly from the
> application code and other two maybe from the optimized libc? There is
> not{hing| much} we have won using an optimised kernel. But the placebo
> effect has been demonstraded once again.
You have not shown wh
On Sun, Nov 09, 2003 at 02:46:38PM +0100, Eduard Bloch wrote:
| Do you see now that 8 of your 10 percent come directly from the
| application code and other two maybe from the optimized libc? There is
| not{hing| much} we have won using an optimised kernel. But the placebo
| effect has been demons
#include
* Glenn McGrath [Sun, Nov 09 2003, 05:09:32PM]:
> > What does that mean? Gentoo uses a heavily patched kernel which goes
> > far beyound of what we dicuss
>
> I was in a debian chroot under a gentoo system hence both tests used the
> same kernel.
But different programs. As said by oth
Mathieu Roy wrote:
> Why do you always assume being facing idiots?
I guess the answer would be experience... No, I'm only guessing,
not knowing...
> People knows all about placebo effect, but do you have any evidence
> that there is nothing more than placebo effect?
If you can't provide evidenc
On Sun, 9 Nov 2003 01:13:09 +0100
Eduard Bloch <[EMAIL PROTECTED]> wrote:
> What does that mean? Gentoo uses a heavily patched kernel which goes
> far beyound of what we dicuss
I was in a debian chroot under a gentoo system hence both tests used the
same kernel.
Its irrelevent, but the kernel i
Eduard Bloch <[EMAIL PROTECTED]> writes:
>> # time bzip2 -9k linux-2.6.0-test5.tar
>>
>> real2m40.974s
>> user2m33.679s
> ...
>> user2m49.316s
>
> Even then, it's about only 10 percent. Let's compare them with vanilla
> kernel, optimised for P4:
What are you trying to measure here?
#include
* Glenn McGrath [Sun, Nov 09 2003, 09:53:26AM]:
> > We're all very interested in *real* evidence here, because there
> > hasn't been any in the past. If you don't have any evidence, you can
> > expect people to call bullshit on this.
>
> Gentoo
What does that mean? Gentoo uses a heavil
On Sat, 8 Nov 2003 12:33:15 +
Andrew Suffield <[EMAIL PROTECTED]> wrote:
> We're all very interested in *real* evidence here, because there
> hasn't been any in the past. If you don't have any evidence, you can
> expect people to call bullshit on this.
Gentoo
# time bzip2 -9k linux-2.6.0-tes
On Sat, 08 Nov 2003, Mathieu Roy wrote:
> People knows all about placebo effect, but do you have any evidence
> that there is nothing more than placebo effect?
It's normal for the person claiming that there are two populations to
provide appropriate data and statistics to back up the claim.[1] By
On Sat, 8 Nov 2003 12:33:15 +
Andrew Suffield <[EMAIL PROTECTED]> wrote:
> Please provide carefully documented evidence of the performance gains
> that you are claiming, not handwaving. Evidence of a difference is not
> the same thing; anybody who has any experience with low-level
> programmin
Andrew Suffield <[EMAIL PROTECTED]> a tapoté :
> On Sat, Nov 08, 2003 at 01:58:29PM +0100, Mateusz Papiernik wrote:
>> Andrew Suffield wrote:
>> >We're all very interested in *real* evidence here, because there
>> >hasn't been any in the past. If you don't have any evidence, you can
>> >expect peo
On Sat, Nov 08, 2003 at 01:58:29PM +0100, Mateusz Papiernik wrote:
> Andrew Suffield wrote:
> >We're all very interested in *real* evidence here, because there
> >hasn't been any in the past. If you don't have any evidence, you can
> >expect people to call bullshit on this.
>
> I can't send any *e
> I'm not removing anything. All I do is providing an alternative. If you
> don't like my alternative, you may keep using the current scheme.
The impression after reaIding the initial discussion was that this ITP
intends to replace the old scheme.
If this is not true, I will stop my complains. Pe
On Sat, Nov 08, 2003 at 06:51:50PM +0300, Nikita V. Youshchenko wrote:
>
> > They won't. Just like Glibc maintainers don't provide optimised
> > packages I don't see why should I provide them.
>
> Note that it is no longer true for current sid packages.
>
> [EMAIL PROTECTED]:~> apt-cache search
Moin Eike!
Eike Sauer schrieb am Saturday, den 08. November 2003:
> Nikita V. Youshchenko schrieb:
> > Seems that someone without any sort of complete knowledge of the problem,
> > decided to maintain one of the most important parts of the system. And the
> > way he chooses is "removing everything
On Sat, Nov 08, 2003 at 03:56:03PM +0300, Nikita V. Youshchenko wrote:
> > I made the package in the way I found most consistent and easy to
> > understand, for users and for developers. You're calling me idiot by
> > saying that, so I'll stop here.
>
> I apologize if the above could be understood
Nikita V. Youshchenko schrieb:
> Seems that someone without any sort of complete knowledge of the problem,
> decided to maintain one of the most important parts of the system. And the
> way he chooses is "removing everything that I don't undestand". This looks
> like a disaster.
If I didn't get it
> > Please please please don't go the Windows way - "let's make it usable
> > for dummies at the price of making it hardly usable by experts"! The
> > saying is: "Create a system that is usable even by idiots, and only
> > idiots will use it".
>
> I made the package in the way I found most consiste
Andrew Suffield wrote:
We're all very interested in *real* evidence here, because there
hasn't been any in the past. If you don't have any evidence, you can
expect people to call bullshit on this.
I can't send any *evidence* here, but I can post my own opinions and
experiences with kernels. And I'
On Sat, Nov 08, 2003 at 01:20:00PM +0300, Nikita V. Youshchenko wrote:
>
> > #include
> >
> > * Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:
> > > Optimization is a serious issue too. Unlike most user space software,
> > > using 386 kernel on modern PC will cause serious performance loos
On Sat, Nov 08, 2003 at 12:39:58PM +0300, Nikita V. Youshchenko wrote:
> Hello.
>
> I've read (a part of) resent kernel ITP flamewar.
You should have kept the Subject and the CC to [EMAIL PROTECTED],
otherwise your message is not properly archived in the discussion.
> The more I read, the more i
> #include
>
> * Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:
> > Optimization is a serious issue too. Unlike most user space software,
> > using 386 kernel on modern PC will cause serious performance loose.
> > Especially if you consider mmx/sse/... and SMP issues. Note also that
> > no
#include
* Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:
> Optimization is a serious issue too. Unlike most user space software, using
> 386 kernel on modern PC will cause serious performance loose. Especially if
> you consider mmx/sse/... and SMP issues. Note also that not all drivers ar
Hello.
I've read (a part of) resent kernel ITP flamewar.
The more I read, the more it frightens me.
Seems that someone without any sort of complete knowledge of the problem,
decided to maintain one of the most important parts of the system. And the
way he chooses is "removing everything that I don
56 matches
Mail list logo
