[Info-vax] OT: Intel dusts off old supercomputing technology

[Steven M. Schweda]

From: moroney at world.std.spaamtrap.com (Michael Moroney)

> It wasn't a question about numbers (I'm fully aware about the number of PC
> GPUs vs. VMS systems), it was a question on how easy it must be to
> implement a client on VMS vs. GPUs, although the motivation to tap that
> admittedly large supply of CPU horsepower would be rather high.  A PC
> graphics card doesn't exactly come with a run time library suitable to run
> number crunchers, and I'm sure loading an actual program onto, and getting
> results from, a graphics card requires some Windoze hackery.  Meanwhile,
> an OS that was originally designed as a number cruncher in part doesn't
> have a client.

   Knowing nothing, I assume that the graphics gizmo is used for some
specific number-crunching task in the client, not that the whole client
runs on the graphics gizmo.  Thus, it would matter less if the "PC
graphics card doesn't exactly come with a run time library suitable to
run number crunchers".  I suspect that the performance of the graphics
gizmo is sufficient to justify some extra bother.

>   Seti at home was dropped since the newer BOINC code wasn't
> easily ported.

   It may be pretty easily ported to an OS which has a C run-time
library which includes the standard UNIX shared memory functions.

http://www.opengroup.org/onlinepubs/009695399/functions/shmget.html

And, on Alpha, where the C++ run-time support covered IEEE
floating-point.  I last looked at the stuff in 2006, before I had an
IA64 system, so the lack of IEEE floating-point in the Alpha C++ stuff
was pretty fatal, and so I never looked hard at how hard it would be to
(find or) implement the missing shared memory stuff.  (I also heard a
rumor that the missing shared memory stuff might appear someday, so I
decided not to waste much time on it.)

   I suspect that most freeware developers look at the hurdles involved
in porting code to VMS (if they look at VMS at all), and, if they get
past the obvious differences, get discouraged by the missing features. 
It's hard to get excited about implementing the missing infrastructure,
when one is primarily interested in the actual application (which runs
just fine in many other, more popular environments).  (Perhaps they're
more popular for good reasons.)

   There are reasons not to put much effort into RTL enhancements for
which paying customers are not currently clamoring, but one result can
be some lost fun for all.  Just a thought.

------------------------------------------------------------------------

   Steven M. Schweda               sms at antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547