Hi,
On Wed, 3 Nov 1999, Robert O'Callahan wrote:
> Multiple threads are never a performance win against tuned single-threaded
^^^^^
Of course, maybe I should have been clearer on this. There are many
aspects to this. One thing I usualy promote about multi-threading is that
since the code generally get's cleaner the chances for efficency increase
are there too, this is NOT magic though (as always, some people tend to
think that they can find a "silver-bullet" to solve their problems, I'm
hopefully not like that, MT is NOT a silver-bullet, it's however, when
used in the right way, a good abstraction), you still have to know what
you are doing, and also what the scheduler might be up to :-). You often
even more have to know what you are doing when doing single-threaded
systems since you in a way design your own scheduler there.
Another aspect (more important here) is that since the code is (generally
speaking) cleaner, you might be able to use it in more flexible ways. E.g.
my SCP-implementation was done in a breeze (I put around 10-16 hours on
it), with the background-up/download as a useful additional feature when
the underlying thread-scheduler is "jumpy".
I'm not saying this is "rocket-science" (it's NOT), it's just an example
of a "bonus" you get when doing a (rather) modular protocol-implementation
that is also MT. Not to say that MindTerm is a wonder of optimizations and
awesome solutions, IT'S NOT, it's far from it (I would even say it's a
kludge in places), It's IMHO a somewhat sane implementation though. Also,
I have not checked e.g. TTSSH (which I guess you are speaking of here :-),
and I was not making any implications that MindTerm is in any way better
than these other implementations. I was just defending java in general
since I happen to believe that most people should stay away from languages
like C or C++ (most people should in fact stay very far away from
everything that have to do with programming, this is however sadly not the
case...).
> code which uses non-blocking I/O (unless you're exploiting multiple CPUs).
> Of course they can be an engineering win since that single-threaded code
> can get ugly. Then again, so can threads. Programs that block
> unnecessarily in common situations aren't worth comparing against.
...
> Actually, performance doesn't matter much for this application as long as
> you don't mess up interactive response times (so watch out for
> non-incremental GC).
Agreed (SMP machines are maybe not an issue here since, I don't expect it
(ssh-clients) to be a performance-critical app., the ssh-server might be
though). Though I was speaking more generally about java-apps (in fact
defending them :-) since some people tend to think that they can beat
java-programs any time by just writing them natively and that is FAR from
reality.
GC is not an issue as long as you make a sane implementation (which most
modern JVM's have), you also have to be somewhat aware of it and know how
it works to achieve best results (but then again, you have to know how the
compiler emits it's code when doing e.g. C++ also, otherwise the
end-result might be FAR from optimal... :-). People tend to think that
doing malloc/free new/delete is "for free". For example a few years ago I
wrote a proprietary "heap-implementation" in C for an embedded system
(main concern non-fragmentation), anyway, I must say it's a daunting task
to write good heaps too... (not to trivialize the GC-implemetations since
they are even more hard to get "right" most of the time).
> Most latency problems should be insignificant compared to network
> delays. Perhaps forwarding massive amounts of data could get
> interesting. Java should be OK for that assuming you reuse the same
> allocated buffers over and over and your crypto is in native code,
> although with compression turned on, it could get tricky.
Yeah, I don't have a pool of buffers which are reused (I'm rather lazy
:-). The crypto-algorithms are probably the most crucial thing for
performance here so I must admit that java is probably still mostly "at
loss", though I think MindTerm is good evidence that somewhat efficient
programs CAN be done in java, it's not for "just" writing applets as some
still seems to think (most people don't even compare MindTerm to the other
"native" win32 ssh-clients since it's "just" an applet :-).
> Having said all that, TTSSH contains quite a few pointless and rather
> entertaining optimizations --- lots of tricks in common paths to avoid
> buffer copying, to avoid malloc/free, and to especially to avoid waiting
> for round trips between client and server.
I must check it out. You seem like a reasonable enough person!
> PS, don't use Hotspot, it's far from the fastest VM, especially for AWT.
Well, since AWT is almost all native code, I expect it to be mostly
"constant" across JVM's given the same classes/libs? However the native
calls _might_ have bad effects on other parts of the JVM such as the
optimization-engine and GC, I have not done any "scientific" testing of
this. HotSpot is of course mainly for running server-apps. In fact I have
not even tried MindTerm with HotSpot since I use Linux most of the time.
Another guy at our company have, and he reported it to be quite "snappy"
though.
Cheers,
/Mats
