• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

IBM To Team With Linux Vendors on 'Microsoft-Free' PCs

Started by BigWarpGuy, 2008.08.11, 19:20:28

Previous topic - Next topic

BigWarpGuy

I am hoping eComStation never becomes eGoneStation.  ;D

saborion2

Whooaaahhh....!

Re:

Quote from: BigWarpGuy on 2008.08.15, 03:26:34
I am hoping eComStation never becomes eGoneStation.  ;D

That was cool BigWarpGuy  ;) Are you saying that "eComStation" might become "eGoneStation" without the giving us the 64-bit performance by the time "Windloze 7" arrives in 2010  ???

Quote

Windows 7 details to come in October

In an interview with CNET News in May, Sinofsky did disclose a few details--namely that it would use the same driver model and basic kernel approach as Windows Vista and that the company wanted the whole thing on the market by January 2010, three years after the mainstream release of Windows Vista. Microsoft also showed in May a glimpse at a new multi-touch interface that will be part of Windows 7.....

http://news.cnet.com/8301-13860_3-10017441-56.html?tag=nefd.top


Best regards,

SAB

RobertM

Quote from: saborion2 on 2008.08.15, 04:54:00
Whooaaahhh....!

Re:

Quote from: BigWarpGuy on 2008.08.15, 03:26:34
I am hoping eComStation never becomes eGoneStation.  ;D

That was cool BigWarpGuy  ;) Are you saying that "eComStation" might become "eGoneStation" without the giving us the 64-bit performance by the time "Windloze 7" arrives in 2010  ???

64 bit does not translate into performance in most cases. It translates into more (easily) addressable resources. Heck, 64bit isnt even required to access memory to 64GB (the Intel chipset already supports that on all PII and up using 36bit addressing).

The few places that a speed increase come in are in using 64bit structures (and related instructions)... the CPU only has to do one operation instead of two (to oversimplify). In cases like Windows64, there has been no noticeable speed improvement (there has been a slowdown noted though).

As a high availability, high load server, yes, eCS needs 64bit support (or some pretty intelligent programs to make up for the lack thereof)... for instance, I should be able to have 10,000 concurrent web connections running on a 4way SMP box - but the system can only handle up to 4095 threads, and that many connections would make extensive use of the disks (without me being able to set a cache size high enough).

It might also help in the rendering arena (ie: CGI/3D)... but nothing currently applies for eCS (NeoN has since stopped being made for OS/2 - or maybe entirely? - and Blender has yet to be ported from Linux to OS/2).

For the home user, I doubt it matter.

-Rob


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Saijin_Naib

Not to mention anything other than serving data that would require that ammount of addressable memory would be most surely multimedia or 3d related, and eCS simply is beyond atrophied in those arenas. No hardware graphical acceleration for 3d rendering, no OpenGL, no DirectX, no FireWire, no hardware Overlay, etc etc etc. Robert hit it just right, 64-bit is not really an important thing yet, but it will be soon. Just like SMP is a big buzzword, but few OSs and programs are properly multi threaded to take advantage of SMP.

saborion2

#19
Re:

Quote from: RobertM on 2008.08.15, 20:40:33
Quote from: saborion2 on 2008.08.15, 04:54:00
Whooaaahhh....!

Re:

Quote from: BigWarpGuy on 2008.08.15, 03:26:34
I am hoping eComStation never becomes eGoneStation.  ;D

That was cool BigWarpGuy  ;) Are you saying that "eComStation" might become "eGoneStation" without giving us the 64-bit performance by the time "Windloze 7" arrives in 2010  ???

64 bit does not translate into performance in most cases. It translates into more (easily) addressable resources. Heck, 64bit isnt even required to access memory to 64GB (the Intel chipset already supports that on all PII and up using 36bit addressing).

The few places that a speed increase come in are in using 64bit structures (and related instructions)... the CPU only has to do one operation instead of two (to oversimplify). In cases like Windows64, there has been no noticeable speed improvement (there has been a slowdown noted though).

As a high availability, high load server, yes, eCS needs 64bit support (or some pretty intelligent programs to make up for the lack thereof)... for instance, I should be able to have 10,000 concurrent web connections running on a 4way SMP box - but the system can only handle up to 4095 threads, and that many connections would make extensive use of the disks (without me being able to set a cache size high enough).

It might also help in the rendering arena (ie: CGI/3D)... but nothing currently applies for eCS (NeoN has since stopped being made for OS/2 - or maybe entirely? - and Blender has yet to be ported from Linux to OS/2).

For the home user, I doubt it matter.

-Rob

Just to repeat,

Quote64 bit does not translate into performance in most cases. It translates into more (easily) addressable resources. Heck, 64bit isnt even required to access memory to 64GB (the Intel chipset already supports that on all PII and up using 36bit addressing).

The few places that a speed increase come in are in using 64bit structures (and related instructions)... the CPU only has to do one operation instead of two (to oversimplify). In cases like Windows64, there has been no noticeable speed improvement (there has been a slowdown noted though).

Well, in as much as you are quite entitled to your own views there is also the "Court (School) of Public Opinion"; and, if the following real world examples (and; there can be many more of such):

Quote

1. The Patriot Missile Failure

On February 25, 1991, during the Gulf War, an American Patriot Missile battery in Dharan, Saudi Arabia, failed to track and intercept an incoming Iraqi Scud missile. The Scud struck an American Army barracks, killing 28 soldiers and injuring around 100 other people. Patriot missile A report of the General Accounting office, GAO/IMTEC-92-26, entitled Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia reported on the cause of the failure. It turns out that the cause was an inaccurate calculation of the time since boot due to computer arithmetic errors. Specifically, the time in tenths of second as measured by the system's internal clock was multiplied by 1/10 to produce the time in seconds. This calculation was performed using a 24 bit fixed point register. In particular, the value 1/10, which has a non-terminating binary expansion, was chopped at 24 bits after the radix point. The small chopping error, when multiplied by the large number giving the time in tenths of a second, led to a significant error. Indeed, the Patriot battery had been up around 100 hours, and an easy calculation shows that the resulting time error due to the magnified chopping error was about 0.34 seconds. (The number 1/10 equals 1/24+1/25+1/28+1/29+1/212+1/213+.... In other words, the binary expansion of 1/10 is 0.0001100110011001100110011001100.... Now the 24 bit register in the Patriot stored instead 0.00011001100110011001100 introducing an error of 0.0000000000000000000000011001100... binary, or about 0.000000095 decimal. Multiplying by the number of tenths of a second in 100 hours gives 0.000000095×100×60×60×10=0.34.) A Scud travels at about 1,676 meters per second, and so travels more than half a kilometer in this time. This was far enough that the incoming Scud was outside the "range gate" that the Patriot tracked. Ironically, the fact that the bad time calculation had been improved in some parts of the code, but not all, contributed to the problem, since it meant that the inaccuracies did not cancel....

http://www.ima.umn.edu/~arnold/disasters/patriot.html

2. The Explosion of the Ariane 5

On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after its lift-off from Kourou, French Guiana. Ariane explosion The rocket was on its first voyage, after a decade of development costing $7 billion. The destroyed rocket and its cargo were valued at $500 million. A board of inquiry investigated the causes of the explosion and in two weeks issued a report. It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed....

http://www.ima.umn.edu/~arnold/disasters/ariane.html


serves to convince others and not you so much so that when the "international standards" in relation to the issues of "INTEGER OVERFLOW" (as were pointed out in the above examples) are established then this action at the international level would have demonstrated the recognized need for the "64-bit capabilities" being talked about; and, that which will undoubtedly "inform the judgment" of folks like myself.

To repeat an old adage - "Out Of One - Many; and, Out Of Many - One"!  8)

Regards,

SAB

RobertM

SAB:

That's a programming error - not a need for 64bit CPUs. If such were the case, JFS would not work as it does with OS/2. You cannot use an programming error as justification for such a need...

Well, you can... but just like the "court of public opinion" it is entirely irrelevant. So... now that you know that, you can stop citing that same missile failure (which is programming error - oversimplified to something else) as you now hopefully understand the difference. 32bit CPUs have been handling 64bit values for quite some time - they just do it in more than one stage. And as JFS proves, there doesnt have to be a performance decrease in doing so.

Robert



|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


saborion2

Hi RobertM,

Re:

Quote from: RobertM on 2008.08.17, 20:32:56
SAB:

That's a programming error - not a need for 64bit CPUs. If such were the case, JFS would not work as it does with OS/2. You cannot use an programming error as justification for such a need...

Well, you can... but just like the "court of public opinion" it is entirely irrelevant. So... now that you know that, you can stop citing that same missile failure (which is programming error - oversimplified to something else) as you now hopefully understand the difference. 32bit CPUs have been handling 64bit values for quite some time - they just do it in more than one stage. And as JFS proves, there doesnt have to be a performance decrease in doing so.

Robert


Mindful of the "subject heading"... I am somewhat obliged to make a review of earlier posts concerned with this thread; but, in order to respond to your
QuoteWell, you can... but just like the "court of public opinion" it is entirely irrelevant. So... now that you know that, you can stop citing that same missile failure (which is programming error - oversimplified to something else) as you now hopefully understand the difference.
So, given the tendencies for people to forget somethings sometimes only to experience "disaster"... :( ; therefore, I may not at this time find it possible to be in agreement with you that the cases cited are rather oversimplified examples; but, as I had earlier mentioned there can me many more examples.

Re:

Quote

64-bit Programming and Optimization

There are several CPUs and operating systems on the market natively supporting 64-bit operations and adressing. This mode is especially beneficial for scientific and engineering applications dealing with big amounts of data. Probably the major advantage of the 64-bit mode is that huge address space is becoming available. Program can allocate twice more memory; easily maintain large database files, etc. There are also certain performance optimization advantages. Most of the articles on 64-bits computing concentrate on ability to address more than 4GB of memory. Current edition of BM  library does not address memory issue, but rather concentrates of performance aspects. The ability of 64-bit CPUs to perform bitwise operations 64 bits at a time can and must be exploited.

http://bmagic.sourceforge.net/bm64opt.html

64-Bit CPUs: What You Need to Know

Branches: Going Out On a Limb

The longer the pipeline, the bigger the train wreck if the processor mispredicts a branch. And Itanium has a fairly long pipeline, so the potential for performance-robbing disaster looms ever large. Predicting branches takes on paramount importance and to that end, IA-64 has a number of tricks to help it avoid the dreaded mispredicted branch.

http://www.extremetech.com/article2/0,2845,1155604,00.asp


and, I for one would like to err on the side of "the court of public opinion" and "caution" and avoid "disasters" like the ones mentioned above.

Good luck to you.

SAB

RobertM

Quote from: saborion2 on 2008.08.17, 21:54:50
Hi RobertM,

Re:

Quote from: RobertM on 2008.08.17, 20:32:56
SAB:

That's a programming error - not a need for 64bit CPUs. If such were the case, JFS would not work as it does with OS/2. You cannot use an programming error as justification for such a need...

Well, you can... but just like the "court of public opinion" it is entirely irrelevant. So... now that you know that, you can stop citing that same missile failure (which is programming error - oversimplified to something else) as you now hopefully understand the difference. 32bit CPUs have been handling 64bit values for quite some time - they just do it in more than one stage. And as JFS proves, there doesnt have to be a performance decrease in doing so.

Robert


Mindful of the "subject heading"... I am somewhat obliged to make a review of earlier posts concerned with this thread; but, in order to respond to your
QuoteWell, you can... but just like the "court of public opinion" it is entirely irrelevant. So... now that you know that, you can stop citing that same missile failure (which is programming error - oversimplified to something else) as you now hopefully understand the difference.
So, given the tendencies for people to forget somethings sometimes only to experience "disaster"... :( ; therefore, I may not at this time find it possible to be in agreement with you that the cases cited are rather oversimplified examples; but, as I had earlier mentioned there can me many more examples.

32bit CPUs and operating systems, have, for the longest time, handled 64bit data structures (or larger). Period. And done it well. Period. The issue you listed is poor programming. Period. What you or anyone else thinks is irrelevant. Reality does not care what you or anyone else thinks. Reality just is. And that (in teal above) is reality.

The "court of public opinion" truly doesnt matter. Think what you will. The Earth is not flat - no matter how much of the populace ("court of public opinion") thought it was.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


saborion2

#23
Hi RobertM,

For convenience I thought that I would quote the initial comment on this thread by BigWarpGuy which reads as follows:

Quote from: BigWarpGuy on 2008.08.11, 19:20:28
http://www.google.com/products?hl=en&q=rear%20view%20camera&um=1&ie=UTF-8&sa=N&tab=wf
"IBM and name-brand Linux operating system distributors Red Hat, Novell and Canonical/Ubuntu have disclosed their intentions to join forces with their hardware partners to create what they are calling "Microsoft-free personal computing choices."  "

I wish this 'Microsoft-free personal computing choices' would include OS/2-eCS.  8)

Hence my views for enhancements (including the development of 64-bit capabilities for the OS/2 Warp Server and Client Operating Systems to match those of the Linux, Windows... environments.

While in you latest comment you have said;

Quote from: RobertM on 2008.08.18, 00:01:03

32bit CPUs and operating systems, have, for the longest time, handled 64bit data structures (or larger). Period. And done it well. Period. The issue you listed is poor programming. Period. What you or anyone else thinks is irrelevant. Reality does not care what you or anyone else thinks. Reality just is. And that (in teal above) is reality.

The "court of public opinion" truly doesnt matter. Think what you will. The Earth is not flat - no matter how much of the populace ("court of public opinion") thought it was.

As can be clearly read from the attached information
Quote64-bit CPUs have existed in supercomputers since the 1960s and in RISC-based workstations and servers since the early 1990s. In 2003 they were introduced to the (previously 32-bit) mainstream personal computer arena, in the form of the x86-64 and 64-bit PowerPC processor architectures....

Pros and cons

A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GB of memory. This is not entirely true:

    * Some operating systems reserve portions of process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and userland OS components are mapped into each process's address space, leaving only 2 to 3.8 GB (depending on the settings) address space available, even if the computer has 4 GB of RAM. This restriction is not present in 64-bit operating systems.
    * Memory-mapped files are becoming less useful with 32-bit architectures, especially with the introduction of relatively cheap recordable DVD technology. A 4 GB file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures; only a region of the file can be mapped into the address space, and to access such a file by memory mapping, those regions will have to be mapped into and out of the address space as needed. This is a problem, as memory mapping remains one of the most efficient disk-to-memory methods, when properly implemented by the OS.
    * Some programs such as data encryption software can benefit greatly from 64-bit registers (if the software is 64-bit compiled) and effectively execute 3 to 5 times faster on 64-bit than on 32-bit.


http://en.wikipedia.org/wiki/64-bit


In any case just why the apparent argument against the development of 64-bit capabilities for OS/2 when "64-bit PowerPC processor architectures" are already here.

BTW, in addition to the above quoted Pros and cons I will find it questionable not to want to "surf the "64-bit waves" just like the other surfers do"; and, as BigWarpGuy said in his opening comment - I would wish that my "64-bit skies" are OS/2-eComStation branded ones while surfing in the sea/ocean of "'Microsoft-Free' PCs".  8)

Quote

http://www.cnet.com/topic/64-bit-cpu.html


Best regards,

SAB

Saijin_Naib

It's just not feasible for OS/2. We don't have the source to the kernel! How can you not grasp this?

RobertM

Hi SAB:

You have just quoted more common misconceptions. First, WinXP32 (and earlier) can address up to 64GB of RAM... not up to 4GB. They are artificially limited there by Microsoft - you just need to add the /PAE switch to the kernel which uses the Intel's 36bit memory addressing (oops, it isnt 32bit is it? It hasnt been for a long time - even in their older "fully" 32bit CPUs).

Heck, even OS/2 can address up to 64GB of memory - IBM just never implemented that support in the APIs or made it available in the kernel (without difficulty from a programming perspective) which pretty much once again makes people think that it too can only address 4GB.

The problem arises from a few things. One, MS doesnt enable it by default (maybe it is even buggier than their 32bit memory accessing APIs?). Two, 99% of people ("court of public opinion") dont know that Windows 32bit is capable of it on all but the most ancient (Pentium One) computers.


Oddly, one thing that you will notice is that OS/2 runs with far more free memory on the same 4GB system, while using 32bit memory addressing mode... Vista is limited to about 3GB (the rest being assigned - supposedly - to other hardware's addresses), while OS/2 seems to make virtually the entire 4GB available (at least it does on my Netfinity).

So once again, it's just another misperception. Check out the EDM/2 articles on the kernel design, or look up /PAE NT kernel for confirmation.

So, my argument stands - regardless of the "court of public opinion's" beliefs.

Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Saijin_Naib

But OS/2 runs out of shared memory regardless of how much free RAM you have, and that's an annoyance I should never have to bear. You may call XP buggy, but that's an issue I've never had there, even with my paltry 2gb of RAM.

But yes, XP can address 64gb of RAM as Robert described, and it's also not a huge deal. Yes, 64-bit can improve performance as it is basically 2 32bit instructions per clock, but it really isn't necessary on a platform like OS/2 that just doesn't support the apps that would benefit it.

Hell, if you want 128bit processing, grab yourself a Dreamcast and load up linux and fly away on its 200mhz CPU :P

Actually, I wonder if eCS can boot on a dreamcast? Hrmm...

saborion2

#27
Hi Saijin_Naib,

Re:

Quote from: Saijin_Naib on 2008.08.18, 05:20:52
It's just not feasible for OS/2. We don't have the source to the kernel! How can you not grasp this?

One might suppose that it all depends how the situation could be approached and since

QuoteOS/2 PPC was a hybrid halfway between Warp 3 and Warp 4. The user interface looked like Warp 3, but many of the features of OS/2 PPC later showed in Warp 4 on Intel. One of them was the not very popular Feature Installer:

http://pages.prodigy.net/michaln/history/os2ppc/index.html

In 2003, BAE SYSTEMS Platform Solutions delivers the Vehicle-Management Computer for the F-35 fighter jet. This platform consists of dual PowerPCs made by Freescale in a triple redundant setup



http://en.wikipedia.org/wiki/PowerPC


and this;

Quote

OS/2 Meets 64-bit Opteron

Performance

So what about performance? Well, here are some comparisons running the same OS/2 software on an Athlon XP 1700+ system and the Opteron system.

Rendering the POVRAY v3.5 demo on Virtual PC 5.1 required 5.5 seconds on the Opteron 240 versus 7.9 seconds on the Athlon XP 1700+. The StarOffice desktop loaded in about 7 seconds versus 11 seconds on the XP 1700 system. Launching the Win-OS2 desktop required 3.8 seconds on the Opteron 240 versus 5.5 seconds on the Athlon XP 1700. Generally speaking, the Opteron performance was very good. The OS/2 desktop was particularly snappy and responsive in the 1280 x 1024 mode with 16M colors which may have been a benefit of the dual-channel DDR memory of the system or the video card or both.

The bottom line for the Opteron system is that OS/2 will run very well on it with no apparent compatibility issues other than the memory issue for DOSCALL1. I have been using the system for nearly a month and it has been a very stable and smooth performer. So why purchase a 64-bit system rather than a 32-bit system? Well, the biggest reason is that 64-bit stuff is likely to become available sometime during the expected 3-year life of the machine so the machine will be more useful during its life if it has the capability to run in 64-bit mode. It is even possible that 64-bit OS/2 plugins might become available at some point or even...(hey we can hope, can't we?), a 64-bit OS/2 kernel. Also, AMD is moving to having all of their processors be X86-64 so it is likely that at some point you will be buying one of these if you buy an AMD processor. If so, it appears that you can be confident that it will run OS/2 with very nice performance and compatibility.

http://www.os2ezine.com/20030916/page_6.html


"Never say never"!  8)

Regards,

SAB

RobertM

Quote from: Saijin_Naib on 2008.08.18, 06:02:15
But OS/2 runs out of shared memory regardless of how much free RAM you have, and that's an annoyance I should never have to bear. You may call XP buggy, but that's an issue I've never had there, even with my paltry 2gb of RAM.

Ah yes, but shared memory arena is something else entirely... which has been addressed to some extent via using the VIRTUALADDRESSLIMIT statement in OS/2. And of course, keep in mind, Vista's exhorbitant memory footprint makes 32bit memory access an even worse joke. I'm still trying to find out whether Vista still supports /PAE addressing. Everything I have found so far points to XP and earlier.


Quote from: Saijin_Naib on 2008.08.18, 06:02:15
But yes, XP can address 64gb of RAM as Robert described, and it's also not a huge deal. Yes, 64-bit can improve performance as it is basically 2 32bit instructions per clock, but it really isn't necessary on a platform like OS/2 that just doesn't support the apps that would benefit it.

Ah... but there's the other misconception... a 64bit CPU running a 64bit OS can only run two 32bit instructions if the OS is designed to handle such (and, in the case of XP, Vista, etc; the app as well). So instead, a 64bit CPU with a 64bit OS (such as XP 64, Vista 64) actually run slightly slower when using 32bit apps.

A 64bit app on it could theoretically run faster - but that happens if the 32bit version was making use of 64bit data structures... instead of more than one 32bit instruction (or cycle) on the 32bit OS, the instruction now gets done in a single 64bit one.

Quote from: Saijin_Naib on 2008.08.18, 06:02:15
Hell, if you want 128bit processing, grab yourself a Dreamcast and load up linux and fly away on its 200mhz CPU :P

Actually, I wonder if eCS can boot on a dreamcast? Hrmm...

It would be nice...  :D


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

"It is even possible that 64-bit OS/2 plugins might become available at some point or even..."

Hmmm... my favorite one is called JFS...  ;)


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|