RE: [Nolug] Go

From: John Souvestre <>
Date: Thu, 19 Dec 2013 19:12:41 -0600
Message-ID: <021301cefd20$9638d1d0$c2aa7570$>

Hi Jimmy.


>>> For highly parallel processing; we are probably already there, with GPU
computing and CUDA; that allows you to run C++ code on the video boards, as
long as your computation is suitable.


"Suitable" being the limiting factor. Most code isn't and that which is
generally requires a good bit of additional work to get it in an acceptable
parallel form.


>>> With video cards that can do over 1 billion MD5 hashes per second;

all the weak password hashing algorithms will be giving way shortly.


Will be? I imagine the NSA can do them in nearly real time by now. J It's
unfortunate that while computer/software technology advances so quickly,
industry takes a long time to retrofit.


>>> Processor performances that increase sequential processing (speed) are
much more beneficial for ordinary applications than mere multiplication of
cores, but increasing speed beyond a point becomes much harder and
exponentially more expensive.


Yes, this took place over 5 years ago.


>>> Most applications will not have great benefits beyond a few cores, even
if programmed concurrently; your operating system can easily sabotage your
efforts to take effective advantage of more than 3 or 4 cores.


Yes, hence my interest in doing some of those tests. I've seen languages
shifting to the single OS thread model where they manage the concurrency (on
one core) themselves. This lightens the load considerably.


Go and Haskell both do this, for example, and they both manage to operate over
multiple cores without giving up too much (about 15% when using 4 cores).
Also, moving data across cores is even more costly, of course, but using some
form of shared memory (where it makes sense) minimizes it I think.


I'm interested in finding out about well other languages perform in this
regard. Perhaps Brett will run some tests on D? J


>>> You really need to have less than 1% "sequential overhead", for ideal
parallelism; which means no data dependencies.


Yes, hence my interest in Haskell. You can do some things functionally in
lots of languages, but few have the tools to do everything functionally - or
at least be forced to isolate what isn't.



    John Souvestre - New Orleans LA - (504) 454-0899


Nolug mailing list

Received on 12/19/13

This archive was generated by hypermail 2.2.0 : 12/20/13 EST