Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > Linux And Feature Creep

Reply
Thread Tools

Linux And Feature Creep

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-05-2010
Phoronix has done some benchmarking on five years’ worth of Linux kernels,
and found that in most areas, performance has remained constant
<http://www.zdnet.com/blog/hardware/adding-new-features-to-linux-has-not-affected-core-performance/10245>.

Open-source developers know how to add new features without losing
performance.
 
Reply With Quote
 
 
 
 
Sweetpea
Guest
Posts: n/a
 
      11-05-2010
On Fri, 05 Nov 2010 23:00:10 +1300, Lawrence D'Oliveiro wrote:

> Phoronix has done some benchmarking on five years’ worth of Linux
> kernels, and found that in most areas, performance has remained constant
> <http://www.zdnet.com/blog/hardware/a...-to-linux-has-

not-affected-core-performance/10245>.

That's to be expected.

If adding functionality to a piece of software results in reduced
performance of existing features or reduced efficiency in any way then
that is poor software development.


--
"Filtering the Internet is like trying to boil the ocean"
 
Reply With Quote
 
 
 
 
Enkidu
Guest
Posts: n/a
 
      11-06-2010
On 06/11/10 07:11, Sweetpea wrote:
> On Fri, 05 Nov 2010 23:00:10 +1300, Lawrence D'Oliveiro wrote:
>
>> Phoronix has done some benchmarking on five years’ worth of Linux
>> kernels, and found that in most areas, performance has remained constant
>> <http://www.zdnet.com/blog/hardware/a...-to-linux-has-

> not-affected-core-performance/10245>.
>
> That's to be expected.
>
> If adding functionality to a piece of software results in reduced
> performance of existing features or reduced efficiency in any way then
> that is poor software development.
>

That's a swinging claim, Lennier. What if your client want you to add a
feature that you know will slow things down, like dynamically flanging
the gizmots instead of statically flanging them. Would you refuse to
make such a change?

Cheers,

Cliff

--

The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

The end excuses any evil - Sophocles
 
Reply With Quote
 
Sweetpea
Guest
Posts: n/a
 
      11-06-2010
On Sat, 06 Nov 2010 14:47:56 +1300, Enkidu wrote:

> That's a swinging claim, Lennier. What if your client want you to add a
> feature that you know will slow things down, like dynamically flanging
> the gizmots instead of statically flanging them. Would you refuse to
> make such a change?


My point is that _adding_ a feature should not impact on the performance
of the other functions of that piece of software.

In your example, assuming that there are other features in that software
other than "flanging the gizmots", a deliberate change from statically to
dynamically "flanging the gizmots" shouldn't affect the performance of
the part of the application that "compresses the whatzits".


--
"Filtering the Internet is like trying to boil the ocean"
 
Reply With Quote
 
Enkidu
Guest
Posts: n/a
 
      11-06-2010
On 06/11/10 17:19, Sweetpea wrote:
> On Sat, 06 Nov 2010 14:47:56 +1300, Enkidu wrote:
>
>> That's a swinging claim, Lennier. What if your client want you to add a
>> feature that you know will slow things down, like dynamically flanging
>> the gizmots instead of statically flanging them. Would you refuse to
>> make such a change?

>
> My point is that _adding_ a feature should not impact on the performance
> of the other functions of that piece of software.
>
> In your example, assuming that there are other features in that software
> other than "flanging the gizmots", a deliberate change from statically to
> dynamically "flanging the gizmots" shouldn't affect the performance of
> the part of the application that "compresses the whatzits".
>

Sigh! You've never developed software, have you? Changing what you call
a feature is almost certainly going to affect another feature. For
instance "compressing the whatzits" might require "flanging the
gizmots(*)" in which case a change to the flanging process will affect
the performance of other parts. It's a fact of life of software development.

(* I realised after I posted that 'gizmots' is mis-spelled. I meant
common or garden 'gizmos', not some exotic French variety.)

Cheers,

Cliff

--

The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

The end excuses any evil - Sophocles
 
Reply With Quote
 
Sweetpea
Guest
Posts: n/a
 
      11-06-2010
On Sat, 06 Nov 2010 22:15:13 +1300, Enkidu wrote:

>> My point is that _adding_ a feature should not impact on the
>> performance of the other functions of that piece of software.
>>
>> In your example, assuming that there are other features in that
>> software other than "flanging the gizmots", a deliberate change from
>> statically to dynamically "flanging the gizmots" shouldn't affect the
>> performance of the part of the application that "compresses the
>> whatzits".
>>

> Sigh! You've never developed software, have you? Changing what you call
> a feature is almost certainly going to affect another feature. For
> instance "compressing the whatzits" might require "flanging the
> gizmots(*)" in which case a change to the flanging process will affect
> the performance of other parts. It's a fact of life of software
> development.


If you believe that adding new features is impossible without negatively
impacting existing features, would you care to explain how the vast
majority of new features in the Linux kernel have not impacted at all
with the performance of existing features?


--
"Filtering the Internet is like trying to boil the ocean"
 
Reply With Quote
 
Enkidu
Guest
Posts: n/a
 
      11-06-2010
On 07/11/10 12:16, Sweetpea wrote:
> On Sat, 06 Nov 2010 22:15:13 +1300, Enkidu wrote:
>
>>> My point is that _adding_ a feature should not impact on the
>>> performance of the other functions of that piece of software.
>>>
>>> In your example, assuming that there are other features in that
>>> software other than "flanging the gizmots", a deliberate change from
>>> statically to dynamically "flanging the gizmots" shouldn't affect the
>>> performance of the part of the application that "compresses the
>>> whatzits".
>>>

>> Sigh! You've never developed software, have you? Changing what you call
>> a feature is almost certainly going to affect another feature. For
>> instance "compressing the whatzits" might require "flanging the
>> gizmots(*)" in which case a change to the flanging process will affect
>> the performance of other parts. It's a fact of life of software
>> development.

>
> If you believe that adding new features is impossible without negatively
> impacting existing features, would you care to explain how the vast
> majority of new features in the Linux kernel have not impacted at all
> with the performance of existing features?
>

You don't know that. All you know is that a) new features have been
added and b) performance has not noticeably changed in the same period.

It is likely that a) new features would normally have impacted
performance b) this has been offset by other unrelated improvements that
have been made to kernel performance.

Improvements and changes *have* on occasion made the kernel
significantly slower, but this has been worked on and fixed in later
releases. I don't remember the kernel versions involved.

Cheers,

Cliff

--

The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

The end excuses any evil - Sophocles
 
Reply With Quote
 
Sweetpea
Guest
Posts: n/a
 
      11-06-2010
On Sun, 07 Nov 2010 12:28:48 +1300, Enkidu wrote:

>> If you believe that adding new features is impossible without
>> negatively impacting existing features, would you care to explain how
>> the vast majority of new features in the Linux kernel have not impacted
>> at all with the performance of existing features?
>>

> You don't know that. All you know is that a) new features have been
> added and b) performance has not noticeably changed in the same period.


FACT: The vast majority of new features added to the Linux kernel have
not resulted in a release having poorer performance of existing kernel
features.


> It is likely that a) new features would normally have impacted
> performance b) this has been offset by other unrelated improvements that
> have been made to kernel performance.


Demonstrably unlikely - as the history of all kernel releases over the
last 5 years demonstrates that virtually all existing features for
virtually all releases were not impacted negatively by features added
into any new release.


> Improvements and changes *have* on occasion made the kernel
> significantly slower, but this has been worked on and fixed in later
> releases. I don't remember the kernel versions involved.


Demonstrably not true for almost all features in all kernel releases over
the last 5 years.


--
"Filtering the Internet is like trying to boil the ocean"
 
Reply With Quote
 
Enkidu
Guest
Posts: n/a
 
      11-07-2010
On 07/11/10 12:36, Sweetpea wrote:
> On Sun, 07 Nov 2010 12:28:48 +1300, Enkidu wrote:
>
>>> If you believe that adding new features is impossible without
>>> negatively impacting existing features, would you care to explain how
>>> the vast majority of new features in the Linux kernel have not impacted
>>> at all with the performance of existing features?
>>>

>> You don't know that. All you know is that a) new features have been
>> added and b) performance has not noticeably changed in the same period.

>
> FACT: The vast majority of new features added to the Linux kernel have
> not resulted in a release having poorer performance of existing kernel
> features.
>

FACT: You don't know that that isn't because improvements in the kernel
have offset any performance hits because of new features.
>
>> It is likely that a) new features would normally have impacted
>> performance b) this has been offset by other unrelated improvements that
>> have been made to kernel performance.

>
> Demonstrably unlikely - as the history of all kernel releases over the
> last 5 years demonstrates that virtually all existing features for
> virtually all releases were not impacted negatively by features added
> into any new release.
>

Nope, the figures do not show that.
>
>> Improvements and changes *have* on occasion made the kernel
>> significantly slower, but this has been worked on and fixed in later
>> releases. I don't remember the kernel versions involved.

>
> Demonstrably not true for almost all features in all kernel releases over
> the last 5 years.
>

Demonstrably true according to the graphs here:
http://kernel-perf.sourceforge.net/r...&options=.html

Cheers,

Cliff



--

The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

The end excuses any evil - Sophocles
 
Reply With Quote
 
Sweetpea
Guest
Posts: n/a
 
      11-07-2010
On Sun, 07 Nov 2010 18:53:41 +1300, Enkidu wrote:

>>> You don't know that. All you know is that a) new features have been
>>> added and b) performance has not noticeably changed in the same
>>> period.

>>
>> FACT: The vast majority of new features added to the Linux kernel have
>> not resulted in a release having poorer performance of existing kernel
>> features.
>>

> FACT: You don't know that that isn't because improvements in the kernel
> have offset any performance hits because of new features.


FACT: the performance of features in the kernel has not changed over the
last 5 years as new features are introduced - as measured from one
release to another.


--
"Filtering the Internet is like trying to boil the ocean"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Intel "Creep Ahead" Rich DVD Video 1 01-04-2006 11:15 AM
Can the whole lot of you spam this creep! nospam Computer Information 5 12-26-2005 03:27 AM
DLLHOST and memory creep mjkahn ASP General 0 05-12-2005 11:06 PM
XP PRO slows to creep. sligo Computer Support 13 05-10-2005 04:47 PM
Exception feature creep! (was: re-entering in the normal flow after an exception is raised) Lonnie Princehouse Python 8 10-02-2004 09:16 PM



Advertisments