[Info-vax] BASIC compiler in the hobbyist distribution

[seasoned_geek]

On Friday, May 29, 2015 at 7:37:53 AM UTC-5, Bill Gunshannon wrote:
> 
> That is the crux of the matter.  Beyond existing customers their market
> is likely totaly new systems, not canabalizing customers from other
> companies.

http://www-03.ibm.com/press/us/en/pressrelease/41684.wss
====
As part of their initial collaboration within the consortium, NVIDIA and IBM will work together to integrate the CUDA GPU and POWER ecosystems. 
====

Even the BOINC community is going fully CUDA now because the x86 is completely worthless and they've finally figured it out.

It's rather stunning that a group pushing for a port to ARM, a processor targeted for low power embedded systems, would turn its back on a CPU design which will dwarf the computational capability of all x86 systems. I have video cards in each of my desktops here containing 384 CUDA core each. Support for it on an x86 is a 8^(*&^(*&^ing hack. It __still__ manages to trim days off Einstein, Cosmology and other projects I participate in. You can't even participate in GPUGRID without CUDA. My machines are all AMD, but because the CPUs must maintain x86 compatibility CUDA is not fully integrated. Driver has to be hacked into the kernel.

http://www.nvidia.com/object/what-is-gpu-computing.html

I didn't read the full explaination, but the description basically seems to fit the connection machine. Hundreds or thousands of CUDAs slaved to a master. While the drivers currently seem to let it be dynamic, current integration sucks.

Fully integrated CUDA with a __real__ data path, not just what we had for video, will create a desktop computer which has the numerical processing power of 5-7 of IBMs current zOS boxes. Hopefully the consortium will reach back into the original AS/400 CISC CPU specification and bring back those 128-bit registers. Preferrably expanding them to 256-bit or 512-bit. Depending on how they bank the CUDA though, really need a few 1024-bit registers. At least one per CPU. Something I read a while back about 1024 being a magic number for grouping CUDA. That may, however, only be due to the current worthless x86 and the hack to support CUDA because the data has to move to the shared video memory instead of the CUDA existing directly in the CPU ecosystems and able to directly address every byte of RAM the master CPU can.

Like it or not, once again AMD kicked INTEL's ass all over town. CUDA, not x86, is the way forward. I have said it before, but it appears few listened. I'm not a fan of IBM, but even they read the writing on the wall. Once again, just like they did for 64-bit, INTEL will show up long after the party is over. Even a much older and slower 4-core PowerPC will run rings around today's 16-core x86 boxes when placed on a board which fully integrates CUDA.

> 
> Not to mention the fact that they will fall on the floor laughing at
> the "24x7 up-time measured in decades" comment.  And i certainly don't
> know in what alternate reality he came up with "End Of Life for your
> current platform".  IBM isn't EOLing AIX or iSystems.

Then please allow me to address your lack of knowledge.

http://www-03.ibm.com/services/supline/products/ExtendedSupport/iSeries.pdf

http://compgroups.net/comp.os.vms/uptime-for-openvms/531171

====
There's a well known story about an Irish Railway cluster that stayed   up for 17 years and kept the application available 24 x 365.23 x 17.

There's a less known story about a MicroVAX in an establishment that had other requirements leading to a really good UPS, and 14 year uptime all on it's own.  It came down the day they moved the office to a different building.
====

While there has not been the determination of the exact criteria for evaluation everyone should know that there will be an "Availability Award" presented at this year's Connect OpenVMS Boot Camp at the Sheraton Needham in September.  Sue Skonetski is working with the HP OpenVMS organization to define the criteria.  Once it is defined we will make sure to publish so people can submit their sites for consideration.
====

Perhaps Sue or someone else can weigh in with the winners of those awards?

>  
> VMS has a lot in its favor.  Sadly, this light has been hidden under a
> bushel for a very long time.  Maybe (hopefully) a revival of marketing
> can expand its market share.  Only time will tell.  But I honestly
> believe that until it is available on the x86-64 architecture its only
> market is going to remain existing customers.  In order to win new
> customers it is going to have to be and be able to market itself as
> something new, not a legacy dating back to the VAX.  Perception Is
> Reality.  If you want neew customers you need to demonstrate (and market)
> to them that this is not the same legacy OS that was ignored by its
> owners for so many decades.  Anything is possible.
> 

Ported to the x86 it will have 15 minutes of market life.

Porting to ARM will make everyone wax nostalgic for the throughput of the PDP-11/70.

Porting to the connection machine which will result from the NVIDIA( AMD) and IBM consortium will be the only realistic path forward. Keep in mind the first cut of this doesn't need to significantly change either the CPU or the CUDA. The first cut is simply to develop an integrated ecosystem which allows the CUDA to directly address all RAM the CPU can and integrate the CUDA controller to that same ecosystem. This eliminates kluny video drivers, the transfer to video memory, and the transfer back, thus, dramatically improving performance.

Later iterations can address register size, external IO bandwidth, etc. While it is certainly not as easy as making a peanut butter sandwich, they aren't trying to invent an as-of-yet undiscovered element to increase chip speed while reducing heat. Right now this is just a plumbing job.

Hmmm.... Just how many video cards are in those rack mounted x86 servers or those blade cabinets? Must not be getting a lot of CUDA boost.

With respect to the x86.

The last manufacturer of buggy whips made the best damned buggy whip you ever saw!