[Tutor] computers

Derrick 'dman' Hudson dman@dman.ddts.net
Thu, 6 Jun 2002 18:10:49 -0500


--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 06, 2002 at 09:47:32AM -0700, Jeff Shannon wrote:
| "Scot W. Stevenson" wrote:
=20
| > (And, concerning another list thread here, wouldn't this be another rea=
son
| > to use Java instead of Python?)
|=20
| In a word, no.  ;)  First of all, on many platforms Java (IIRC)
| emulates threads in a nonthreaded environment ("green" threads),
| with semantics that are similar to Python's GIL (but weaker, because
| the GIL is typically released in extensions).=20

I know for a fact that the Blackdown port of Sun's JDK uses native
threads on linux.  On solaris I know the admin/user has a choice
between native and "green" (user-space) threads.  If you want an
empirical comparision of green and native threads on Solaris/SPARC
configurations look around at java.sun.com.  I once read an article
there on the topic, and it included graphs as well.

Still, there are advantages to java's green threads over python's
threads on a multiproc system.  Java's green threads are User Space
threads -- they consume only a single kernel-level thread.  Thus java
will be (naturally) constrained to a single CPU.  Python uses
kernel-level threads, and you can end up with a multi-threaded python
app hogging both CPUs but not making effective use of both of them.

| Second, and more importantly, efficient use of multiple processors
| (even if Java offered that) is typically a poor reason to choose a
| language to develop in -- as mentioned above, it's probably not
| going to result in a faster program.  And if you really needed that
| efficiency, then you should be coding in C, not Java.
=20
Wholeheartedly agreed on both points.

| The point of using Python is that it's easier/faster to develop
| software with it.  The (hypothetical) advantages that Java offers
| for SMP environments are rarely going to be enough of a benefit to
| override the extra costs of developing in Java.

Right.  If you really need (or just want) to take full adavantage of
SMP hardware you need to use separate processes anyways with some sort
of efficient IPC (or shmem?) between them.  The problem with threads
is=20
    1)  they lead to greater programmer error
            -- not synchronizing when necessary
            -- deadlock
            -- bottlenecks due to locking (and thus blocking other threads)

    2)  they have overhead and must interact in unusual ways.  For one
        thing you can't kill a thread from another thread.  The best
        you can do is ask it to die and hope it behaves well.  There
        is no "SIGKILL" equilvalent for threads because they are part
        of the same process.  With separate processes you can kill an
        external process.

HTH,
-D

--=20

Pleasant words are a honeycomb,
sweet to the soul and healing to the bones.
        Proverbs 16:24
=20
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg


--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjz/6/kACgkQO8l8XBKTpRSd0wCfSry71+SqUdlGn+HqU0rIXcYX
EKEAn1zKn3tzT73iMiANI114ufFzbkFN
=EJ9e
-----END PGP SIGNATURE-----

--ew6BAiZeqk4r7MaW--