Any Questions about or Suggestions for the next release?

[Agents]

Steve,

Why don't you give up?  I was the poster, I was very clear on what I wanted accomplished and why that was.  You have 
managed to ridicule and misconstrue the request because you do not see the need for this improvement on your system.  
My request, however, has been backed up by other posters and I think you should respect that.

I have been a member of this list for a couple of months and I have to say that your comments are most disappointing -- you 
are frequently arrogant, you never admit to being wrong and you can never admit that other people have valid points.  This 
has to stop.

Hakan

On Thu, 2 Sep 1999 05:20:47 -0700, Steve Lamb wrote:

>Wednesday, September 01, 1999, 9:05:55 PM, Darin wrote:
>>>    The bottom line is that he wasn't clear.
>
>> To you, or to Bob&Ike?  Which matters more?
>
>    I've already addressed this.  Here it is again.  Bob and Ike are not on
>this list.  You cannot say they would or would not have understood it.  The
>point stands that he was not clear in what he said because he didn't say to
>get responsiveness back.  He only said to throw threads at it if the time was
>slow.
>
>> Um, no.  Well, maybe if you have IDE.  The disk will make one read
>> operation out of it, send all of the data to be processed in parallel,
>> and still speed it up.
>
>    Uhm, no.  There is an absolute limit of how fast that disk is going to
>operate.  I don't care if it is IDE, SCSI, a RAID, or Darin's Magical Wild
>Ride Hard Drive.  Formatting a drive is not going to get faster as you
>throw CPU power at it because it is the drive you have to wait on, no matter
>what, not the CPU.  Copying 30,000 messages from one location to the next will
>get no faster by throwing CPU power at it because you're not waiting on the CPU.
>
>> But you're throwing red herrings all over the place, and I can't keep up.
>
>    No, I'm pointing out very valid problems in what was said.  You want me to
>stop, be precise.
>
>> First, we started with "use another thread" for a specific item (0.1s
>> response time in PMMail). You made that into a generalization.
>
>    No, I did not make it into a generalization.  I pointed out, rightfully,
>that throwing threads at a process does not make the process faster.  The
>original poster was unclear on what he wanted and the wording he used strongly
>suggested that he equated threads to an absolute speed, not the responsiveness
>of the system.  The mere fact that you and he had to return and take pains to
>clarify that point proves that he was quite unclear in the first place.
>
>> I answered the generalization with a generalization (qualifying that it
>> didn't apply to our specific example). You answered that with a specific
>> example. Are we generalizing, or are we talking about this specific example?
>
>    I was giving a specific example where multithreading does no good to
>reinforce my assertation that multithreading is not the end all, be all of
>speeding things up.  What you wrote was patently false and I corrected you on
>that.
>
>> In this case, throwing an extra thread at it *WILL* improve performance
>> (negligably) and improve responsiveness (significantly).
>
>    It did not start on responsiveness, now did it?
>
>> In general, parallelisable tasks (of which we only really have two - the UI
>> and the listbox update) get tremendous speed boosts from multithreading,
>> especially on SMP machines. This generalization only applies, in this case,
>> for our two tasks.
>
>    Bravo, you're now understanding how to be clear in what you're saying.
>If you had said this in the first place instead of...
>
>> [Technically, it's also accurate if you anticipate users having SMP.
>> But I doubt too many users who have PMMail/PMINews have OS/2 Warp
>> Server SMP or OS/2 Warp Server for e-business on an SMP box... :-)]
>
>    ...I would have agreed with you.
>
>-- 
>         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
>         ICQ: 5107343          | main connection to the switchboard of souls.
>-------------------------------+---------------------------------------------
>
>
>
>
>
>