>> On the other hand, how do you make your word processor go faster?
>
> Is your word processor really not fast enough?

Sometimes. (Depending on which one I'm using.)

>> *can* you make your word processor go faster?
>
> Spell check in one thread, layout of pages you haven't looked at in
> another thread, etc. I think they're already making it faster, if you
> actually watch Word or Reader open a big document, for example.

I wonder if anybody has fixed that thing where closing the CD drive 
causes the entire Windows OS to lock up for 30 seconds yet?

>> From what I've seen, the thing
>> that usually slows these down is I/O latency
>
> I find that's almost all of the slow-down, actually.

I'm just bitter because our document management system requires you to 
open a Word document that lives on a Windows share at HQ. Of course, for 
all the people at HQ, that's just a subnet away. But for everyone 
else... SMB over a WAN is not fast. 5 Mbit/sec bandwidth and 105 ms 
latency is not fun with such a chatty protocol.

> Have you seen the
> video of the SSD RAID array? Where they open all four office programs
> with documents in about half a second? Where they open every program
> installed on the computer in about 10 seconds?

I do remember configuring my Amiga 1200 to boot from a RAM disk. Jesus, 
that was fast...

>> OOC, how many problems can you name for which there is no known optimal
>> algorithm? How many problems provably cannot be solved optimally?
>
> Certainly all the problems that can't be solved can't be solved
> optimally. Otherwise, you can always brute force all possible answers
> and pick out the optimal one, assuming you have a way of generating
> answers and evaluating their relative merits. I think your question is
> too ill-specified to be answered clearly, tho.

OK, so a problem would be provably impossible to solve if the search 
space is infinite or if there's no way to enumerate all possible solutions?

>> Even for programs which do run faster in parallel, due to Amdahl's law,
>> there's usually a point at which adding more cores does not improve
>> performance.
>
> Certainly having more cores than the number of instructions the program
> executes is going to be pointless, so mathematically speaking, the law
> *always* applies, even if it's silly in practice to take it to that
> exaggeration.

Sure. My point was that for some programs, adding more cores yields more 
speed, at least until you reach ridiculous limits. For other programs, 
adding just one or two cores means you already reach that point.

> GC is definitely one of the harder problems out there. :-) One of those
> "in theory it's easy, in practice getting good performance is really hard."

I think the fundamental thing is that GC wants to traverse pointers 
backwards, but the heap structure only allows you to traverse them forwards.

Other than that, we keep getting processors with more and more cores, 
but exactly the same amount of memory bandwidth. This seems very 
unsustainable.

Post a reply to this message