Slashdot Mirror
First OpenVMS Boot On IA64
vaxzilla writes "At 3:31pm EST on Friday, January 31st, 2003,
OpenVMS for the Intel IA64
architecture
successfully booted and ran a DIR command.
The Intel Itanium family of processors is the third architecture supported
by OpenVMS in its
25 year
history. Originally it ran on Digital Equipment Corporation VAX
systems; in the early 1990s, support was added for the DEC Alpha
processors. Following the acquisition of DEC by Compaq, and more recently
Compaq by HP, the Itanium and Itanium2 port of OpenVMS is now being
undertaken by HP. Congratulations on a job well done to the folks at
ZK03 in Nashua, NH!"
thank god for that!
An itanium based platform can produce a listing of files!!!!
This is truly a breakthrough. Intel is waay ahead in computing than companies like Nike or Coca Cola.
If only my toaster was powered by Itanium!
Notice they don't actually show you the directory listing in question?
Because it was PR0N.
I know it's present in some legacy systems, and supported by Compaq for that reason. But why would we want VMS on new hardware? What new stuff runs on VMS these days?
--
There is no hatred more pure and true than that expressed by children.
OpenVMS is in the process of porting to the Itanium® processor...Hence, we are opening a 'guess the boot date' contest. This boot contest is a fun way for you to forecast the exact time that OpenVMS will first boot on the Itanium processor (boot is considered when OpenVMS boots; a user logs in and does a directory command without crashing the system).
I used OpenVMS a bit at my universty, and I have to say I never really got into it - getting my solaris account was a great day! I can understand people wanting to maintain legacy apps (big purchasing systems maybe?) but is OpenVMS really good for anything _new_ today? Does it have any real particular advantages that mean you would want to use it for reasons other that "we've already got a stack of Alphas this high on it and gonna keep using it until forever"?
I'll be the first to say it. MHz don't mean jack.
i might actually care about this if the software is open source and not just another proprietary unixy OS.
yeah, server companies benefit, but so do engineering and scientific institutions. some of my code runs faster on a 500 MHz Alpha than a 1.5 GHz Pentium 4 (with rambus memory)
I hold a patent on sigs...
I am curious as to what sense that OpenVMS is open?
> 64 bit does not mean a thing. 99.99999999999999% of software today does NOT run on it, and the performance difference in mhz between 32 bit and 64 bit processors (especially in the north bridge) makes any performance gained by using 64 bit architecture negligible.
> As usual, great tool for the server companies, crap for everyone else in the world.
Also good for scientists who want to do lots of 64-bit FP math. Possibly others; let's make a list.
Would it help with graphics applications? RGBA x 16 bits each would be 64 BPP.
Sheesh, evil *and* a jerk. -- Jade
OpenVMS is used heavily in the financial industry, primarly due to security and stability.
I had an OpenVMS machine at home at one point, but the power supply crapped out...
Now, get off the stick & build the Alpha EV8+
Time flies like an arrow, fruit flies like a banana.
4GB is still a lot by any standard, but the problem is that the kernel, for example, needs to have some of its structures appear in the process's address space. Shared libraries also need to be in each process's address space, even if it's in memory only once. Even better, you need to leave room for the heap to grow as well as for user-loaded entities (like dlopen()'ed shared objects). In practice, I understand the default restriction for Linux is somewhere in the neighborhood of 1.5GB per process, though you can increase that to 3GB with some libc tweaks. There are a few kernel patches to raise that limit further to 3.5GB, but that's the absolute ceiling (and you are sacrificing what may be important things, like SysV shared memory segments).
Even now, it's not uncommon to see gaming machines with 1GB RAM or more. Even small servers will often have 4GB RAM. In a few years, the number of "high-memory" systems is only going to increase as advances in technology continue to drive down the cost of RAM and drive up the requirements of software. This is especially the case as databases become more important and commonplace in the business world. Everyone uses them now, but we can expect to see them used more often, and in more diverse places, than in the past.
There is also a hope among many of us that Intel and AMD will use this opportunity to create good chips, not just cheap ones. They have the opportunity to fix a lot of the stupid design decisions Intel made 20 years ago and put together a modern, clean system. Unfortunately, it doesn't look like this is going to happen (I don't think anyone at AMD has had an original idea in their entire lives, and Itanium is being designed by committee), but this is the hope. In short, we may not see any immediate performance gains, but in the long term, the design of the chips would enable faster improvements than we're getting with IA32s right now.
Would it help with graphics applications?
No, graphics would use vector operations, which use 64-bit vectors but are not called "64-bit" operations. A "64-bit" operation is typically defined as one that uses a 64-bit number or a 64-bit pointer, not a vector of four 16-bit numbers. Current 32-bit processors are perfectly capable of performing operations on vectors of 16-bit numbers through such instruction set extensions as 3DNow! and AltiVec.
Will I retire or break 10K?
Commodore One successfully executes LOAD FROGGER,8,1!
THIS CHANGES EVERYTHING!!!
No, wait... what the hell does this matter? We're shutting the few remaining vaxes at work off soon...isn't everyone?
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I grew up on VAX/VMS at school after a highschool exposure to (and part-time job thru the college years using) PDP-11s.
Compared to the various dialects of unix, the VMS environment was so much friendlier and forgiving... I'm only now realizing how much my hands were in mittens using it. I'd still prefer a system that wasn't so case-sensitive.
The chief engineers behind VMS then went to work at Micro$oft to develop NT, so some of the legacy is still there: expensive process starts, but a nice memory model to work with.
Strengths:
Linkers in the early 80s that were easy to cross languages in a single project
A powerful set of run-time libraries, including some excellent flatfile databases
A scripting language that had access to a nice library of "lexical" functions.
But like I said, I wish I still cared. While we still have Alphas around running openVMS at the office, I haven't logged onto one for about three years. Somewhere, I have a huge library of shell routines, login scripts, and ancient forms-oriented code.
Design for Use, not Construction!
I talk form personal exp on vax/vms druing my stint at Purdue University during 1990s..
Considering that VAX/VMS sucks when compared to unix..why?
Remember the architecture person for both VAX/VMS and winNT is the same damn idiot....
Don't Tread on OpenSource
Pfffft... AFAIK, an OS has only arrived when Doom gets ported to it...
I can believe that. My father has some planetary simulation program that can simulate a spacecraft flying between n-bodies. Its all numerical integration. He has a 166Mhz 21064 (AXP-PCI 133; ie oem alpha motherboard) with 64MB of ram (33Mhz). He also has a 850Mhz Duron with 256MB of DDR-266. The program runs at about 1/3 the speed of the duron on the alpha -- but that's with GCC which doesn't generate overly optimal code for the Alpha processor.
Its says a lot for that old Alpha machine. I bet those new Alphas which I'm assuming operate at least at 1Ghz, would be able to leave a P4 3Ghz in the dust for floating-point operations.
I thought it was Linux 2.2 that had the 4Gb memory limit? - I think it was 2Gb plus 2Gb actually, or 3 + 1. anyway, I'm pretty sure I've seen 64Gb as a compile option for 2.4 kernels, back when I used to use it (I got scared off around 2.4.11 and went onto FreeBSD 4.x)
"Linux lives on"
:o(
So does Windows
Congratulations????
More like, way to sell out. The Alpha platform is much older and is actually more powerful than the Itanic. There is nothing to be happy about here, it is just the end of the line for the DEC tradition of excellence that began with the PDP-10.
Welcome to the end of DEC excellence. The sooner HP dies the better. HP has done nothing innovative for computing in the last decade. Instead of spending money porting OpenVMS to Itanic, they should be out getting Apple to run on Alpha and get EV8 out the door. Then go back to Microsoft and re-open DEC West. HP kow-towing to Intel, instead of commercializing a superior architecture.
Stop talking about who's to blame when all that counts is how to change --"Born of Frustration" - James
Too late they realized that they had forgotten to implement a shutdown command or even a copy command and the filesystem was corrupted when they turned the power off.
--
But then again I thought VCR+ was a stupid idea and would die a quick death--so what do I know?
What's that got to do with 32/64 bit? It just means that the DEC fortran compiler generates fast, optimized code and g77 doesn't.
...wearing a skin-tight topless leather jumpsuit, with cutaway buttocks and transparent crotch panel.
Your first iteration was amazing. Your second version was equally amazing. AMD's own successes with the K7 architecture are owed mostly to you. Your latest golden baby was thrown in the garbage because it scared the other babies. Even though no one wants to know, your EV7 is *STILL* the premiere big iron architecture in this day and age. What would have been your crowning jewel was aborted and your womb replaced by something Intel Inside. EV8, you would've been an engineering and design marvel, something that would've taken YEARS to beat. And now, poor DEC Alpha team, where are you? Fragments of your EV7/6 team are higher-ups at AMD, giving the desktop underdog a chance, and the rest of you is at work at Intel/HP, genetically engineering something something truly EPIC, that sadly, only even a mother could love...assuming the mother eventually gives birth to acceptably talented offspring. Oh, whither art thou, Alpha?
------- "From bored to fanboy in 3.8 asian girls" ----------
I must disagree with you.
64 bit does not mean a thing.
It means something important to anybody who ever has to receive a CAT scan or a nMRI scan... VMS/VAX systems run nMRI and CAT scanners... They use 64 bit architecture during Fourier analysis...
99.99999999999999% of software today does NOT run on it
probably because 99% of software today is used for text and graphics processing; not for mission critical apps. that's kind of like saying that 99% of all driving accidents happen within 25 miles of home... well, geeze, 99% of all driving period occurs within 25 miles of home...
performance difference in mhz between 32 bit and 64 bit processors (especially in the north bridge) makes any performance gained by using 64 bit architecture negligible
I disagree with you. The difference between being able to handle 2^32 and 2^64 is worlds apart in performance. I suggest that you compare 16 bit computers, which didn't support true-color, full motion multimedia, and compare to 32 bit computers. They both support text editing; however, one supports WYSIWYG better than the other...
FYI, my day job involves running MRI scans on a VMS/VAX Gyroscan Intera workstation... This 64 bit architecture is the hottest stuff around, for somebody who works with a VMS/VAX workstation... here's why: MRI scanners work just like any other printer/scanner device, in terms of device drivers, and general operation. The difficulty is, because MRI looks at differential angular momentum of hydrogen atoms to obtain it's pictures, it's got to calculate a Fourier wave analysis on each atom it vibrates. Being able to run an algorithm with 64 bits means less data manipulation, higher resolution, faster scan times, and increased diagnostic imaging power to the medical doctors.
Anyhow, for those interested, there currently seems to be a big migration from VMS/VAX/Alpha solutions to Windows/Intel compatibility (for obvious reasons). Philips has introduced an InteraNT product into their Intera Gyroscan line, which runs the MRI scanner on a Windows NT platform, instead of the traditional VMS/VAX platform which they've been using for some time...
As usual, great tool for the server companies, crap for everyone else in the world.
This is slashdot... they cover stuff which is great for server companies, hospital radiology departments, nuclear power facilities, astronautical engineering groups, etc. etc. That's why we love it...
automatic file versioning!
if you have foo.txt and you save another foo.txt in the same directory, you get foo.txt;2 !
damn, i wish Windows had that.
-c
I have discovered a truly remarkable proof which this margin is too small to contain.
Yes you're correct with IA32 you're limited to 4GB per process. I wouldn't call it a "kludge"; basically you have 36 bits to specify a physical address in each PTE, but are still limited to 32 bit linear addressing. This means you can have 2^36 bytes of RAM, and processes can be spread out throughout that whole address space. I'd only consider it to be a kludge if there were "windows" or "partitions" and you could access 4GB of consecutive at once.
Note that this is completely transparent to the process. The OS is responsible for setting up paging. Note also that on a server you typically run a whole lot of processes anyways (e.g. a whole bunch of web server processes) so for most server applications I don't see it as a major limitation (big databases may be one problem)
Note also that theoretically that you could have system where the process could access more than 4GB of linear address space, if you set aside some region of linear address space for this purpose, and had a system call to update where this was going to. This is an ugly, ugly kludge, requires OS modification, and reminds of DOS style memory management but could be done (and would probably be cheaper than moving off of X86...)
What exactly about OpenVMS makes it "open?" Is it a marketing slogan or is there more to it?
Yes, but can you play solitaire on it?
The university I attend still uses VMS on one of its main servers(an old DEC I think.) It seems that the only free COBOL compiler that actually runs right only runs on that system. If they got rid of VMS, they would have to buy a comercial version of a COBOL compiler which they don't want to do. It also turns out VMS's systems are more secure than UNIX systems since people have been looking for holes in UNIX for decades. No one in their right mind wants to use VMS let alone hack into a system running it so VMS systems have remained safe.
There's a growing sense that even if The Future comes,
most of us won't be able to afford it.
-- Lemmy
Congratulations on a job well done to the folks at ZK03 in Nashua, NH!"
HOLY CRAP!!! I lived in NH for 16 years, and I was positive that I was the only person in the whole state that had a computer!!
This space for rent, inquire within.
64 bit does not mean a thing. 99.99999999999999% of software today does NOT run on it.
Guess what, 100% of Alpha VMS software runs on 64-bit hardware. Because Alpha has been 64 bit for about ten years. 64-bittness is nothing new here...
)9TSS
I've been told that Cutler & Co ported OpenVMS
to a 386 PC and showed it to Ken Olsen, who then
banished him (and his team) to Portlan OR, which
was way too close to Redmond.
I was also told that DEC was able to force M$ to
deliver NT for Alphas at the same time (if not
before) it was available for the x86 simply because
it seems some VMS internal logic was part of NT.
I dunno. But the story-teller seemed to have a
good grasp of the DEC line-up and had worked
there. (The stories of sniffing the dry-erase
markers were way too believable.)
We're shutting the few remaining vaxes at work off soon...isn't everyone?
We still have lots of systems running VMS, one is a VAX, and a bunch are alphas. We have no plans to stop in the foreseeable (I know, I can't spell) future. They run some important apps that we don't have on other operating systems.
~Jon
This space for rent, inquire within.
VMS is the worst operating system I have ever encountered, period.
It might have decent preemptive multitasking, but the entire premise of the OS was to deny users as many privileges as possible, thus ensuring systems people full-time employment.
I can still remember having to go and beg to have my disk allocation increased to 2 MB. VMS is one of the reasons PCs took off so quickly; at least with a PC, you don't have to go on your knees and beg for indulgence from a prick every couple of weeks to be able to be able to get anything done on your computer.
Actually, I think that Alphas aren't near 1GHz yet. The fastest I've seen (I know that they make faster ones than this) is a 566 MHz I believe.
This space for rent, inquire within.
I remember working with Open VMS on Vaxen & later on Alphas. We wrote control systems that ran on them, gas, water, electricity distribution control systems.
Great I/O facilities built into the OS, gotta love that QIO system call.
By why use OpenVMS ? Well its as solid as they come, easy to secure, great documentation.
Its a shame DEC/Compaq/HP/Whoever owns it this week won't take on M$ in the server arena with it.
...wearing a skin-tight topless leather jumpsuit, with cutaway buttocks and transparent crotch panel.
...is for Itanium to run on FreeVMS!
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
a punch in the eye is better than a kick in the nuts.
what's your point?
But it's not sourcecode.google.com, it's some other thing. I'm confused.
Warning!!! Goatse links in the above post!!!
If it's not open source, it's crap.
If your MRI software was GNU-licensed, thousands of biomedical engineers could review the code and fix the problems in it!
Regarding your claim that VMS is optimized for Fourier wave analysis, I can't believe that this is unique today. The main impetus behind VAX BSD was ARPA's desire to have a Unix system that would handle the memory demands of computer graphics. We made use of various Unix systems at Pixar and Pixar's predecessors, where there were similar sorts of problems (texture rendering rather than FFT) and Linux is now the darling of those places.
This is a VM and cache issue, not really rocket science these days.
Thanks
Bruce
Bruce Perens.
that should read LOAD "FROGGER",8,1
oh god, I actually remember that...
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
At university, I only came near VMS under threat of force, because I have an invariant habit of typing 'ls' in any new login, screen, or xterm I see. This is fine in Unix, but in VMS it invokes Kafka's own editor, which has no known method of termination, not even convoluted emacs or vi compatability.
Man, can't Itanium get a break? First, the overpriced, lackluster performance. Now, VMS.
I guess some people must like it, but I never saw the appeal. My roomate in college once used a boot disk to rename all the files in my home directory from xxx yyy to XXX;2 YYY;5. I had an immediate, horrible reaction.
I installed Win98SE on his machine the next day.
set def sys$firstpost
or
set def $_first:[post]
Who knows the name of the DEC engineer who cleaned up after Dave Cutler's messes?
One of the questions that comes up all the time is: How enthusiastic is our support for UNIX? Unix was written on our machines and for our machines many years ago. Today, much of UNIX being done is done on our machines. Ten percent of our VAXs are going for UNIX use. UNIX is a simple language, easy to understand, easy to get started with. It's great for students, great for somewhat casual users, and it's great for interchanging programs between different machines. And so, because of its popularity in these markets, we support it. We have good UNIX on VAX and good UNIX on PDP-11s. It is our belief, however, that serious professional users will run out of things they can do with UNIX. They'll want a real system and will end up doing VMS when they get to be serious about programming. With UNIX, if you're looking for something, you can easily and quickly check that small manual and find out that it's not there. With VMS, no matter what you look for -- it's literally a five-foot shelf of documentation -- if you look long enough it's there. That's the difference - - the beauty of UNIX is it's simple; and the beauty of VMS is that it's all there.
Ken Olsen, Chmn&CEO, DEC, 1984
Just because your toy OS linux is designed for a 386 doesn't mean the rest of the world is.
Goodbye, Alpha. It was nice knowing you.
WINNT51.BAS!!!!
You can't judge a book by the way it wears its hair.
Anyone know a web page that compares modern Unix to modern VMS? I already know the commands differ, but what really separates them? I know VMS is very stable and works quite well at what it does (whatever that is). My Debian boxes are extremely stable, too. Sorry for the newbie question, but the VAX was before my time.
This will be damned good. I'll be able to hobble together a system and put a stable OS on it. Sure, it won't have a pretty interface and be able to run all the pretty bloated applications, but it also won't crash all the time and programming for VMS is a breeze (ok, stay away from C & C++, but everything else is cool).
Now if can just hold my breath for a few years until IA64 and VMS are released...
We have 666MHz ES40s at work and we could upgrade the processor boards in them to run at 866 (well, 800-something; can't remember just now) MHz. I believe that the newest Alphas (EV7) are coming out in 1GHz -- or faster -- versions. And I hear they blow anything else out of the water.
CUR ALLOC 20195.....5804M
Really? What was your first clue? Was it the huge ascii representation of the goatse.cx guy? Or /. reporting that the link was to a goatse.cx domain? Or are you actually the biggest moron in the world and you clicked the link?
This could make VMS the longest living computer viral lifeform...
bbh
The "64GB" options in the kernel just enable the page address extension (PAE), which is a way of addressing up to 64GB for the entire OS. So you can have 16 processes using 4GB each, and you'll be using all 64GB, but you can't have 8 processes using 8GB each.
It's not impossible to write an OS which lets each process access up to 64GB RAM, but it would be nontrivial. It would require many different segments and probably a lot of page faults. And it would be a lot of work, unless I'm missing something very obvious.
I uses/run a public OpenVMS cluster. There are still somethings that the Unix community could learn from OpenVMS. Cluster, and the security model come to mind. The stablity cannot be beat. It's good stuff. And, yes.. You can run OpenVMS on your little Intel boxes.. Check out.. http://simh.trailing-edge.com/ .. Cool stuff.
Run's great. If you're really interested in OpenVMS, there's a couple of "free access" servers out there. For example:
http://deathrow.vistech.net .... One uVAX, and
Alpha online for public use. We're about to add a SIMH (Intel) box running OpenVMS into the cluster as well.
OK, here's the story:
The 386 processor lets you refer to memory with a 32-bit address. This is good and useful and lets you specify any byte in a 4 GB range. This is continued up through the latest Xeon. This is known as a flat memory model in that you only have one address for each memory byte. The alternative, used in the 8086 / 186 / 286 "real mode" and many other (mostly older) CPU designs, is segmented addresses, where each memory location is addressed by a segment and an offset within the segment. In some cases you can optimise out the segment address by assuming it is the same as your "current" segment, however that may be defined. Segmented memory addressing is seen nowadays as needlessly complex for general computing.
So as to flat addressing: when you refer to a (in our case 32-bit) memory address, this address is usually not the physical address but a virtual address, which is looked up by the CPU automatically via page tables. These page tables and other associated machinery are set up and managed by the OS.
Now, note that when Intel added 64 GB support to the Pentium III, they didn't use classic "segmented addressing", because that would be really inconvenient for application programmers (and compiler writers) who are accustomed to the assumption that you can hold a memory pointer in a single CPU register - and general-purpose registers on x86 are all 32-bit. Instead, they instituted a 36-bit address space through page tables - the OS basically sets up a new type of page table scheme, so 32-bit virtual addresses in an application can refer to anything in a 64-GB range of physical memory.
So from the application standpoint, it still has a maximum of 4 GB of address space, less a certain amount of overhead for the OS. More than 4 GB at a time would require larger than 32-bit addresses, which would be a major compatibility hurdle.
So how is it useful to have 64 GB of memory if an application still only gets 4 GB at a time? Because if you have multiple processes, they can each have their own page tables which don't necessarily overlap. Indeed, the OS always keeps page tables separate between processes - that's how memory protection works, and why you can't access another process's memory without explicit arrangement.
If your application needs more than 4 GB of memory, but you don't want to invest in a real 64-bit CPU, you basically have to break up your app into multiple processes each of which can allocate its own pool of non-overlapping memory, and have the processes communicate as necessary via shared memory, message passing, the filesystem, or similar.
The other way to do it is to have the application do its own overlay management. The idea here is that the app knows it needs to access memory not in the current page table setup, so it issues a call to the OS to "swap out" the page tables regarding a particular region of its virtual address space in favor of another swath of physical memory. I believe this alternative is not currently implemented in Linux, but it may be soon. I say this on the basis of Jeff Dike's proposed extensions to support multiple address spaces per process - he wants this for User-Mode Linux, but I think it could potentially be useful for overlays as well.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Is this for real? Hey, it's your day job, not mine, but I thought the VAX was strictly 32-bit. Are you sure you're not confusing the VAX with the Alpha? They both run VMS, you know.
Yeah, but isn't this stuff done in floating point? Floating point is 64-bit or better on most of platforms, including the much-maligned 387. Which is not to say Alpha isn't a great platform for floating point math - that's its strongest point, actually - but that has little to do with its overall 64-bitness.
(Apologies if MRI processing is done in integer math. In that case, a 64-bit CPU is indeed better suited to the task than a 32-bit CPU.)
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
I was there back in October for a short visit (couple of hours actually). I didn't sign any NDA and I didn't get a good look at anything that would require one, so I guess it's ok if I tell you. :-)
That's gotta be one of the coolest places I've ever been to. It totally tops Six Flags. *Any* Six Flags. It's a very big building, and one of the wings contains _the_ lab. 20 meters wide, 60+ meters long, and *full* of equipement. One of the most impressive pieces were the several _operational_ VAXen there. As a student, I worked with VMS and a couple of VAXStations so I learned some respect for the architecture. Even if the machines are tiny by today's standards, it was absolutely amazing to see them just run and run and run 24x7. The PCs and Sun workstations on the same lab crashed every now and then. The VAXen just kept crunching numbers. So, when I saw the array of VAXen at ZK03, my jaw just dropped.
The other reason I was impressed is how neatly organized everything is at the place. You will be hard pressed to find cable spaghetti. There was some, but I you take into account the density at the place (conservative guess: 5 machines/sq m), it's just clean. And of course, all the surrounding stuff. Just neat.
But perhaps the most impressive: DEC, Digital, Compaq and HP logos all over the place. You can feel the peace. It's not as if HP went and took over and threw everything away, but intead they got there and became part of a team.
Made me think about applying for a job there.
--
nah, lieber nicht.
Announcement on GNAT for ia64/OpenVMS on 14Mar2002
This is great and it's the right thing to do!
Laurent
No, the original replies are quite right. You're a fucking dumbass who knows nothing about VMS and probably very little about Unix.
Still, as you have apparently pissed yourself at the idea of having to actually pay money to try out VMS, maybe you should take a look at FreeVMS Yeah, see how far OSS has gotten with trying to clone VMS.
There are reasons that some things are not Open Source. Get over it and grow up.
I visited local HP on Jan 28 when they had a new AlphaServer showcase (nice machines if you really need more than two CPUs I suppose) and the guy told me that the folks at HP were betting when OpenVMS would boot on IA64 and they considered it would be "real soon now." I didn't think it would be this soon... ;>
...I'd just like to point out that the Hurd first booted in April 1994 and how far has it come since then?
Precisely.
In fact, it is pretty much the same solitaire as
windows. However, there has been free software
collected in the DECUS library and the VMS SIG
tapes (which have been CDs for many years now) freely distributed twice a year from the spring of 1979 to the present. The Fall 2002 collection has just been frozen and will be distributed within days to the volunteers who make it available. It is a very full CD. These originated from contributions at DECUS symposia, but have become more net based. The total thus far is around 25 full CDs of code...not inconsiderable.
Then you think wrong.
You can buy 1250MHz Alpha machines right now.
They were launched August 2002.
~~~
The EV68 is available at just over 1.2ghz, and at this speed is roughly 40% faster than a 2.8ghz p4 on the specfp benchmarks, The EV7 starts at 1ghz and presumeably faster versions will come later.. the ev7 should also quite comfortably beat the ev68 at the same clock
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Which is why the Alpha at about 1Ghz tops benchmark figures over other processors. Hz means some but the number of instructions that get executed is the other significant part.
I thought DEC had VMS running on MIPS processors at one point, but never brought it to market... (I might be wrong, it's been a whole lotta years!)
I've only used it a wee bit, but friends who had to do major projects on VMS called it the Vomit Making System.
I agree that there are some big advantages to having 64-bit integer registers. Floating point operations are usually not one of them.
The nice thing about null-terminated strings on big-endian 64-bit architectures is that you can sort strings 8 bytes at a time. (You can also do this on little-endian 64-bit systems like ia64 as long as you reverse the strings in memory including putting the nulls first. Depending n your application, you may also need to pad the string with nulls.)
Wonder how long it took to list the directory. Probably two seconds less than the five minutes it would take with the last VAX model.
Went right over your head.
The fact that this person felt inclined to list the managers involved in bringing this about first made me suspect her of being a bit wacked. That last sentence sort of confirms it...
Why not give the engineers credit? How many bytes would that take up? Err... okay, who wants to explain "bytes" to Sue Skonetski?
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
And how many seconds? C'mon, you wrote down the minutes as if this is a milestone that should be recorded in a museum or book or other historical document, so you must record the seconds. Imagine 100 years in the future, on 31 Jan 2103, legions of people will do a dir on legacy hardware, much as aviation enthusiasts are preparing for the centennial of the Wright Bros first flight. Those legions will certainly not be satisfied with just the minute.
Clue: outside your parents' basement there's a whole wide world of wonders...
None of that would happen in real life.
--
But then again I thought VCR+ was a stupid idea and would die a quick death--so what do I know?
linkpack itanium2 vs alpha ev68
This is the performance for ev68 equipped es45's with 1.25 and 1.0 ghz processors respectively.
LINPACK 1000 x 1000 6,847 (4 CPUs) 5,522 (4 CPUs)
Link to above
I work with large scale alpha clusters, and was just in maryland earlier last month learning how to support the itanium boxes so I looked a few things up while there.
Granted linkpack isn't the only benchmark, but the processor/memory and io bandwidth looks impressive from the specs I've seen.
*drool*
I really need an ev7 then. =)
This space for rent, inquire within.
the 64 bit Alpha port of Linux was one of the 1st
ports & Torvalds himself worked on it. So, maybe
Linux is a toy OS, but it's a toy OS that's had a
64 bit implementation for awhile.
Everybody, get your CAT scan, scan your dog, too, and support OpenVMS, the best there is.
BTW, I used more than 32 bit address space for some scientific research program. Glad that I had OpenVMS/Alpha available. Students, researchers: wake up, there is more than just linux in the world.