Java, the "Dot-Com" Language?
2 + 2
overpriced software projects that promise the world but deliver very little?
Sun is, no doubt, taking a big hit to its bottom line.
Perhaps Dell, which has be same profit level as Sun BEFORE the downturn,
will buy Sun for it's midline server hardware business, which it would
promptly convert to Linux, an OS that delivers on its promises.
Dell could become a dominent Linux server vendor.
Dell would sell off the Sunsoft division that include Java, etc. Then that
division could concentrate on becoming a software company in competition
with Microsoft.
That would be good for the industry. Java wouldn't be captive to the mission
of selling overpriced Sun servers.
McNealy could be farmed out to a separate spin off of the chip business. Of
course, Scott could still be heard railing against the elements like Captain
Ahab, except the White Whale would be Intel.
We wouldn't want an industry without the Scott to badmouth the competition.
2 + 2
Stephen S. Edwards II
8<SNIP>8
: Perhaps Dell, which has be same profit level as Sun BEFORE the downturn,
: will buy Sun for it's midline server hardware business, which it would
: promptly convert to Linux, an OS that delivers on its promises.
Linux is not an OS. Linux is a kernel. GNU/Linux is an OS
comprised of GNU software and the Linux kernel.
Just a pedantic detail that peeves me from time to time. :-)
J Perry Fecteau
do it with their own intel servers! they're the only pc company their
size that won't suffer from cannibalization by adopting linux.. but
michael dell refuses to remove his lips from bill gates' cock two
seconds to at least think about it!
as far as sun dying... DREAM ON!!
J Perry Fecteau
Former 6-time Mr. Internet
http://perry.fecteau.com/
Wodger
>
> 2 + 2 <2...@web.com> writes:
>
> 8<SNIP>8
>
> : Perhaps Dell, which has be same profit level as Sun BEFORE the downturn,
> : will buy Sun for it's midline server hardware business, which it would
> : promptly convert to Linux, an OS that delivers on its promises.
Really? Which promises does Linux deliver on that Solaris on Sun
hardware doesn't?
Roedy Green
wrote or quoted :
>
>as far as sun dying... DREAM ON!!
Giving out a website is now more common that giving an address or
phone number. I exchange email addresses just as commonly as phone
numbers now. Look how slow most webservers are. There is PLENTY of
market for new high performance servers out there. The brick and iron
companies are just bringing their presence to the web. They have only
begun. The failure of the silly .coms will be just a blip.
The success of Google with its Linux server farm shows that the future
may well be in massive farms of mass produced clones. I think though
that there will be plenty of business for a wide range of server sizes
for the foreseeable future.
-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/jgloss.html or http://209.153.246.39/jgloss.html
If you don't see what you were looking for, complain!
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963
2 + 2
J Perry Fecteau wrote in message <3ac525e5....@enews.newsguy.com>...
>i actually said the linux thing about dell a while back... they could
>do it with their own intel servers! they're the only pc company their
>size that won't suffer from cannibalization by adopting linux.. but
>michael dell refuses to remove his lips from bill gates' cock two
>seconds to at least think about it!
As I've stated, Dell sells its $1000- entry level server on Red Hat Linux at
no extra cost, while Windows 2000 costs about a $1000 more.
I'm talking about the midrange server that Dell is looking to conquer.
Dell has far superior state-of-the-art OEM assembly factories. Also, great
integration of its web site for selling, with customized pages for each
approved-for-purchasing model for each big customer.
Sun would provide good brand ambiance.
>as far as sun dying... DREAM ON!!
Who said dying? Sun would live on as a software company like Microsoft.
Before the downturn, Sun had only about $2 billion annual profits, the same
as Dell.
After the downturn, who knows what Sun will report. The stock is sinking
through the floor due to investor profit worries.
Sun has to do a better job of selling enterprise software based on the Java
platform, where it has the inside advantage.
This is A VAST MARKET of countless billions (the top 500 software companies
share $200 billion). Sun is already in the top ten of that software market.
(Enterprise software is assuredly not free)
Success means huge profit margins.
There no question that Sun is being mismanaged based on its history as a
hardware vendor.
Sun has the name cachet to attract the best software talent in the industry.
In the corresponding time of the last 5-6 years, Microsoft has gone from
having NO PRESENCE in the enterprise software market, to having built an
infrastructure AND server products that is a rapidly growing sub-segment of
the company ($5 billion annually last quarter).
I predict that Microsoft will have more profit from this segment this
quarter than Sun has profits overall. Likewise, I bet a very substantial
part of Sun profits this quarter will be from software. The hardware segment
has tanked.
And this is BEFORE the .NET platform goes to manufacturing.
People complain about HailStorm for various reasons, but fail to see that
this is an infrastructure being pieced together focusing on the DEVICE
market, the very market that Java was originally developed for.
The economy JITer, the PC tablet, HailStorm and who knows what will be
coming out. But it will be part of a strategy to provide infrastructure for
the device market. This will be based largely on business needs.
2 + 2
pete@-
>
>And this is BEFORE the .NET platform goes to manufacturing.
and Oracle and IBM and everyother company and technology out there
and it is not out yet!
what an amazing thing it must be.
you must be so brain dead, and the most idiot who ever posted anything
anywhere.
how much is billy paying you to come say all of this?
Aaron R. Kulkis
>
> As we see the dot-com meltdown, how do we access all the money wasted on
> overpriced software projects that promise the world but deliver very little?
You neglected to mention that the cost overruns are disproportionately on
Mafia$oft platforms.
> Sun is, no doubt, taking a big hit to its bottom line.
You're joking, right?
>
> Perhaps Dell, which has be same profit level as Sun BEFORE the downturn,
> will buy Sun for it's midline server hardware business, which it would
> promptly convert to Linux, an OS that delivers on its promises.
>
> Dell could become a dominent Linux server vendor.
>
> Dell would sell off the Sunsoft division that include Java, etc. Then that
> division could concentrate on becoming a software company in competition
> with Microsoft.
>
> That would be good for the industry. Java wouldn't be captive to the mission
> of selling overpriced Sun servers.
>
> McNealy could be farmed out to a separate spin off of the chip business. Of
> course, Scott could still be heard railing against the elements like Captain
> Ahab, except the White Whale would be Intel.
>
> We wouldn't want an industry without the Scott to badmouth the competition.
>
> 2 + 2
--
Aaron R. Kulkis
Unix Systems Engineer
DNRC Minister of all I survey
ICQ # 3056642
K: Truth in advertising:
Left Wing Extremists Charles Schumer and Donna Shelala,
Black Seperatist Anti-Semite Louis Farrakan,
Special Interest Sierra Club,
Anarchist Members of the ACLU
Left Wing Corporate Extremist Ted Turner
The Drunken Woman Killer Ted Kennedy
Grass Roots Pro-Gun movement,
J: Other knee_jerk reactionaries: billh, david casey, redc1c4,
The retarded sisters: Raunchy (rauni) and Anencephielle (Enielle),
also known as old hags who've hit the wall....
I: Loren Petrich's 2-week stubborn refusal to respond to the
challenge to describe even one philosophical difference
between himself and the communists demonstrates that, in fact,
Loren Petrich is a COMMUNIST ***hole
H: "Having found not one single carbon monoxide leak on the entire
premises, it is my belief, and Willard concurs, that the reason
you folks feel listless and disoriented is simply because
you are lazy, stupid people"
G: Knackos...you're a retard.
F: Unit_4's "Kook hunt" reminds me of "Jimmy Baker's" harangues against
adultery while concurrently committing adultery with Tammy Hahn.
E: Jet is not worthy of the time to compose a response until
her behavior improves.
D: Jet Silverman now follows me from newgroup to newsgroup
...despite (C) above.
C: Jet Silverman claims to have killfiled me.
B: Jet Silverman plays the fool and spews out nonsense as a
method of sidetracking discussions which are headed in a
direction that she doesn't like.
A: The wise man is mocked by fools.
GreyCloud
From what I'm seeing of Sun the last two weeks they've held pretty solid
on the market.
Sun hasn't been resting on their laurels. They have introduced the sun
blade 100. 64-bit processing for $950. 500 Mhz sparc IIe with 128Mb ram
upto 2Gb. I highly doubt Sun will disappear from the market place, but
will instead keep growing. It'll be awhile before MS comes out with
their 64-bit O/S, which isn't available now. Also the itantium
processor from intel is still having problems. It was supposed to be
out last August, but its still in very limited quantities. Linux has
IA-64 version ready for it, and HP has reportedly developed a UNIX
version for it. The bad part of the Pentium IV right now is its heat
dissipation... 54 watts. Yet the sparc chip doesn't dissipate that much
power. With the rolling black outs and the political push to conserve
power, intels going to have a temporary image problem.
--
V
Frank
"pete@-" <pete_...@newsguy.com> wrote in message
news:9a42r...@drn.newsguy.com...
Agent
> > >Former 6-time Mr. Internet
> > >http://perry.fecteau.com/
>
> From what I'm seeing of Sun the last two weeks they've held pretty solid
> on the market.
> Sun hasn't been resting on their laurels. They have introduced the sun
> blade 100. 64-bit processing for $950. 500 Mhz sparc IIe with 128Mb ram
> upto 2Gb. I highly doubt Sun will disappear from the market place, but
> will instead keep growing. It'll be awhile before MS comes out with
> their 64-bit O/S, which isn't available now. Also the itantium
> processor from intel is still having problems. It was supposed to be
> out last August, but its still in very limited quantities. Linux has
> IA-64 version ready for it, and HP has reportedly developed a UNIX
> version for it. The bad part of the Pentium IV right now is its heat
> dissipation... 54 watts. Yet the sparc chip doesn't dissipate that much
> power. With the rolling black outs and the political push to conserve
> power, intels going to have a temporary image problem.
First, Sun Sparc is basically a RISC Architecture and Intel is a CISC
Architecture (eventhough both have barrowed others Ideas..!) CISC puts lots
of functions(like mupltiply,divide) into one CHIP (complex) and frees up
Compiler & higher level writing. and RISC does the opposite. With that RISC
can multiply Hardware wise very fast with less heat dissipation. That's why
you can have Sparc with 50-100 processors easily. But, writing a compiler is
very complex for RISC.
As a crude comparison, a 4-processor 64 bit RISC (1) is roughly equals to
single processor 64-bit CISC (2) !! Now for a given unit of work, both (1) &
(2) will take the same time !
The advantages of RISC is it has an excellent Pipeline Architecture
(parallel processing) which if the upper level compiler & language can take
advantage(they call Scale-up). This is very good for high-end complex
processing, but has a single point of failure(E-bay !!)
CISC Achieves the same by Parallel systems (Scale-out). This is (many
systems in cluster form) very complex to manage, but as the S/W field
advances, this becomes less burdun.
So, a RISC 64-bit OS with Clock speed cannot be compared to a CISC 64-bit
with the same clock speed.
varadhg
Aaron R. Kulkis
Hate to burst your bubble, but modern "RISC-based" CPUs are indistinguishable
from modern "CISC-based" CPUs.
> As a crude comparison, a 4-processor 64 bit RISC (1) is roughly equals to
> single processor 64-bit CISC (2) !! Now for a given unit of work, both (1) &
> (2) will take the same time !
>
> The advantages of RISC is it has an excellent Pipeline Architecture
> (parallel processing) which if the upper level compiler & language can take
> advantage(they call Scale-up). This is very good for high-end complex
> processing, but has a single point of failure(E-bay !!)
>
> CISC Achieves the same by Parallel systems (Scale-out). This is (many
> systems in cluster form) very complex to manage, but as the S/W field
> advances, this becomes less burdun.
>
> So, a RISC 64-bit OS with Clock speed cannot be compared to a CISC 64-bit
> with the same clock speed.
>
> varadhg
Chad Myers
"2 + 2" <2...@web.com> wrote in message
news:9a3om1$6li$1...@slb5.atl.mindspring.net...
>
> J Perry Fecteau wrote in message <3ac525e5....@enews.newsguy.com>...
> >i actually said the linux thing about dell a while back... they could
> >do it with their own intel servers! they're the only pc company their
> >size that won't suffer from cannibalization by adopting linux.. but
> >michael dell refuses to remove his lips from bill gates' cock two
> >seconds to at least think about it!
>
> As I've stated, Dell sells its $1000- entry level server on Red Hat Linux at
> no extra cost, while Windows 2000 costs about a $1000 more.
>
> I'm talking about the midrange server that Dell is looking to conquer.
>
> Dell has far superior state-of-the-art OEM assembly factories. Also, great
> integration of its web site for selling, with customized pages for each
> approved-for-purchasing model for each big customer.
>
> Sun would provide good brand ambiance.
>
> >as far as sun dying... DREAM ON!!
>
> Who said dying? Sun would live on as a software company like Microsoft.
> Before the downturn, Sun had only about $2 billion annual profits, the same
> as Dell.
>
> After the downturn, who knows what Sun will report. The stock is sinking
> through the floor due to investor profit worries.
>
> Sun has to do a better job of selling enterprise software based on the Java
> platform, where it has the inside advantage.
If they can quickly evolve the EJB standard so it's not a cobbled-together
mess of hacks (although EJB 2.0 is slightly better) perhaps they will
have a chance. With EJB 1.1 and mostly with EJB 2.0, this will never happen
because it's just too poor of a spec.
-c
2 + 2
GreyCloud
Only have to do the compiler design and make it a finished product.
After that the programmer using say C or C++ doesn't get his nose dirty
in the RISC stuff. Yes, it is somewhat more complex to write the
compiler and libraries, but after that its a downhill ride.
> As a crude comparison, a 4-processor 64 bit RISC (1) is roughly equals to
> single processor 64-bit CISC (2) !! Now for a given unit of work, both (1) &
> (2) will take the same time !
>
Currently the Alpha will blow the doors off the Pentium IV. But Compaq
has deemed that you should pay a high price for it when its not
necessary. The RISC cheaps are easier to make and cost less.
> The advantages of RISC is it has an excellent Pipeline Architecture
> (parallel processing) which if the upper level compiler & language can take
> advantage(they call Scale-up). This is very good for high-end complex
> processing, but has a single point of failure(E-bay !!)
>
> CISC Achieves the same by Parallel systems (Scale-out). This is (many
> systems in cluster form) very complex to manage, but as the S/W field
> advances, this becomes less burdun.
>
> So, a RISC 64-bit OS with Clock speed cannot be compared to a CISC 64-bit
> with the same clock speed.
>
> varadhg
If you take and break down these CISC instructions and rewrite them
using RISC instructions, you can make the program run faster.
Universities have researched this, and also an article appeared in the
early 80's about RISC instruction sets vs. CISC.
What you assert has already been proven false. The IBM/Motorola venture
and produced the PPC chip. The 500 Mhz chip (PPC) in an Apple is
equivalent to a 1 Ghz. or 1.5 Ghz Pentium when an actual application is
running. Even the Apple cube doesn't require a cooling fan.
There are many RISC processors out there, HP PA-RISC, IBM 603-604 series
RISC, MIPS, Sparc, Alpha and a few others I can't recall. Intel is the
only one I know of still clinging to CISC ideas.
The list goes on. Why do you think so many computer companies have
favored RISC then?
--
V
Mats Olsson
Aaron R. Kulkis <aku...@yahoo.com> wrote:
>Agent wrote:
>> First, Sun Sparc is basically a RISC Architecture and Intel is a CISC
>> Architecture (eventhough both have barrowed others Ideas..!) CISC puts lots
>> of functions(like mupltiply,divide) into one CHIP (complex) and frees up
>> Compiler & higher level writing. and RISC does the opposite. With that RISC
>> can multiply Hardware wise very fast with less heat dissipation. That's why
>> you can have Sparc with 50-100 processors easily. But, writing a compiler is
>> very complex for RISC.
>>
>
>Hate to burst your bubble, but modern "RISC-based" CPUs are indistinguishable
>from modern "CISC-based" CPUs.
Almost indistinguishable. The "CISC" ones have a CISC->RISC translation
stage when code is loaded from memory. Costs a bit, but nowadays more than
offset by being on the leading edge process wise.
/Mats
Roedy Green
wrote or quoted :
>The advantages of RISC is it has an excellent Pipeline Architecture
>(parallel processing) which if the upper level compiler & language can take
>advantage(they call Scale-up). This is very good for high-end complex
>processing, but has a single point of failure(E-bay !!)
What do you mean by "single point of failure"? Don't all CPUs have
zero redundancy now?
Roedy Green
wrote or quoted :
> The IBM/Motorola venture
>and produced the PPC chip.
Not quite fair. The Power PC is a pretty CISCy RISC chip.
The Pentium instruction set is badly constrained by having only a tiny
handful of registers. If someone were designing a CISCy instruction
set today, it would have a whacking huge sliding register window.
I don't know to what extent Intel fixed that when they added the 64
bit mode.
The Power PC also is designed for multi cpu synchronisation. With the
Pentiums it was an afterthought.
You are tarring all CISC designs with the problems of legacy.
spam
Yea, you're a real enterprise and java expert and I'd forgotten how
everyone in these forums respects your technical savy.
----
Glenn Davies
Stephen Fuld
news:9a5cl7$mlu$1...@nyheter.chalmers.se...
> In article <3AC5DC45...@yahoo.com>,
> Aaron R. Kulkis <aku...@yahoo.com> wrote:
> >Agent wrote:
> >> First, Sun Sparc is basically a RISC Architecture and Intel is a CISC
> >> Architecture (eventhough both have barrowed others Ideas..!) CISC puts
lots
> >> of functions(like mupltiply,divide) into one CHIP (complex) and frees
up
> >> Compiler & higher level writing. and RISC does the opposite. With that
RISC
> >> can multiply Hardware wise very fast with less heat dissipation. That's
why
> >> you can have Sparc with 50-100 processors easily. But, writing a
compiler is
> >> very complex for RISC.
> >>
> >
> >Hate to burst your bubble, but modern "RISC-based" CPUs are
indistinguishable
> >from modern "CISC-based" CPUs.
>
> Almost indistinguishable. The "CISC" ones have a CISC->RISC
translation
> stage when code is loaded from memory.
I think that is only true if CISC = x86. AFAIK, the IBM mainframe S/390, or
Z series, or whatever they are calling it this year (arguably the other
major CISC architecture) does no CISC to RISC translation.
Actually, I think that some of the "off brand" x86 chips (like the one VIA
just picked up) do not do the conversion.
--
- Stephen Fuld
gbp
>Really? Which promises does Linux deliver on that Solaris on Sun
>hardware doesn't?
>
Its very good and its cheaper!!
There is NO license fee. This may not be a big deal for your
organization but for many thats a great advantage.
Lets make up an example. Say your a retail chain and you need a
custom point-of-sale program. If you have about 1000 stores and 3
CPUs at each store thats 3000 machines that need licenses. Now if
you save $100 a box thats $ 300,000!! Thats enough to hire a
systems admin for 5 years.
gbp
>In the corresponding time of the last 5-6 years, Microsoft has gone
from
>having NO PRESENCE in the enterprise software market, to having
built an
>infrastructure AND server products that is a rapidly growing
sub-segment of
>the company ($5 billion annually last quarter).
>
>I predict that Microsoft will have more profit from this segment
this
>quarter than Sun has profits overall. Likewise, I bet a very
substantial
>part of Sun profits this quarter will be from software. The
hardware segment
>has tanked.
>
I have serious reservations about microsoft. I don't believe they
will be able to expand into mid and high end markets like they want
too.
Simply put. In my experience many admins just don't like Microsoft.
They may use MS desktops and servers but generally consider them
toys compared to their Unix servers. They don't trust MS enough
to commit to their products and they don't believe the company
produces high quality software.
In addition Unix admins get paid more than NT admins and I don't
think they are going to line up for a pay cut just because windows
2000 has feature x y and z....
gbp
>First, Sun Sparc is basically a RISC Architecture and Intel is a
CISC
>Architecture (eventhough both have barrowed others Ideas..!) CISC
puts lots
>of functions(like mupltiply,divide) into one CHIP (complex) and
frees up
>Compiler & higher level writing. and RISC does the opposite. With
that RISC
>can multiply Hardware wise very fast with less heat dissipation.
That's why
>you can have Sparc with 50-100 processors easily. But, writing a
compiler is
>very complex for RISC.
You have this reversed. In general writing compilers is more easy
for RISC because the instruction set is simpler. This is a major
reason why Apple and most (all?) unix vendors went RISC. Because
they knew that they would have to write compilers if their machines
were to be of any use.
gbp
>There are many RISC processors out there, HP PA-RISC, IBM 603-604
series
>RISC, MIPS, Sparc, Alpha and a few others I can't recall. Intel is
the
>only one I know of still clinging to CISC ideas.
>The list goes on. Why do you think so many computer companies have
>favored RISC then?
Its my understanding that intel considers itself to be essentially
_stuck_ with CISC since existing PC software depends on the CISC
intruction set of the 386+. So since they already were firmly in
the CISC camp their designers added even more (a lot more!)
instructions to the chips to try to improve them that way.
These improvements assume that compilers will take advantage of all
these instructions. In their case it seems like a fairly safe bet.
gbp
>Sun is, no doubt, taking a big hit to its bottom line.
>
>Perhaps Dell, which has be same profit level as Sun BEFORE the
downturn,
>will buy Sun for it's midline server hardware business, which it
would
>promptly convert to Linux, an OS that delivers on its promises.
Since this thread is already WAYYY off topic I'd like to add my
view...
Most of the good IT companies, read IBM, Oracle, SUN. Are trading
about at the same point or higher than two years ago when this media
fueled internet bubble started.
People shouldn't be so suprised that pets.com etc etc didn't make
it. Is it really that much harder to get dog food at the
supermarket?
I think a lot of good came out of this. There are all kinds of
development tools that weren't around 2-3 years ago, esp. in
relation to server side web programming. A lot of people learned a
lot of cool stuff even if the projects they worked on were financial
failures.
I think that its unfortunate that so many people are in the stock
market that don't use common sense or take the time to read up on
what they are doing with their own money. A lot of people get their
financial advise from TV and thats just sad.
I'd like to see the government take a more active role in directing
the IT industry towards some more productive things. Needly to say
the talent to do this hasn't been around for a long time. You have
Gore who pretty much alienated the whole IT industry with his pompus
attitude (you think he had 10 years of programming experience from
the way he talks). And Bush is pretty much on the other extreme. He
doesn't pretend to know anything about IT and he doesn't even
pretend to care-- at least he's honest.
I'd like to see the government contribute tools to help the US keep
its lead in the software industry. If they can send someone to the
moon why can't they write a decent OS or JVM.
Linux has gotten pretty far without anyone getting paid to write it
(well almost no one). I think that a lot of people would be will to
work on the government pay scale for a while if they were involved
in a really interesting and usefull project. When the project is
done the license could be free in the US and fee-based for other
countries.
OK sorry, way off topic. To sum up: java is better than c++ :)
GreyCloud
Thats a good point. I'd much prefer a compiler thats been time tested
without having the cpu vendor keep adding on more instructions that will
eventually obsolete my compiler. The down side to CISC is the amount of
silicon real-estate needed for all these instructions, ending up instead
with a space heater. Remember the 6502? Most of its instructions
completed in 1 or 2 clock cycles and a few in 3. The apple II doing
graphics did a fair job at 1Mhz in those days. I think Intel is the
only cpu vendor left using CISC.
Aaron R. Kulkis
Actually, I liked the VAX-11 instructions set, becuase a good portion
of the standard C library functions could each be implemented as a single
line of assembly language...meaning that all of these things (like
strchr()) were executed at the microcode level.
The problem is, no compiler writer ever took advantage of this, which
is truly a pity.
Shane Phelps
A little out-of-date , aren't we?
Sun stopped charging Solaris licence fees on the smaller systems
(< 8 CPUs) last year, so that one's old hat.
The Netra X1 is a nice 1U system which costs about the same as a
mid-range
PC ($1K official price), but is IDE based. The Netra T1 is a very
good rack-mount SCSI-based system, but probably costs more than the
equivalent Dell. It *does* fit in a standard 19" comms rack, though.
Linux *is* very good; so is Solaris. Linux isn't cheaper any more.
Solaris also has the advantage of better scalability on bigger boxes,
though the 2.4 kernel may have caught up.
...and there are also the various BSD variants to consider.
BTW, I consider 3 CPUs per retail outlet to be vast overkill!
Chad Everett
IBM head honcho when discussing IBM's big investment in Linux recently
stated that even the 2.4.x kernel has trouble scaling well to greater
than 4 CPUs. I'm a linux advocate and was disappointed to hear this.
The great thing about Linux though, is that this is likely to change
a lot faster than any closed source based OS could hope to do.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Cat
Hash: SHA1
Unless it's a very profitable one owned by a company that can easily afford to invest
unlimited money until it's killed it's opponents.
Cat
http://www.ratrobot.com/sport/sport.htm NEW THIS MONTH Would you cheat in a $100 million
dollar lottery if you knew they wouldn't catch you? This is the problem with drugs in sport.
How do we solve it?
http://www.ratrobot.com/java/ratrobot_help.jar FREE APPLETS JARS EDITORS CHOICE
www.ratrobot.com Articles that challenge your ideas about yourself and the world you live in.
"Chad Everett" <ch...@linuxsupreme.homeip.net> wrote in message
news:slrn9ch0o...@linuxsupreme.homeip.net...
- -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBOsgFCih0Y2LcENUAEQJSEwCeKAD3mOcffSg0bZAKdvcwfzIJcZEAoNvY
9goEqXitVDzy/hCQ3jbDHgOz
=VVla
-----END PGP SIGNATURE-----
gbp
Shane Phelps wrote in message <3AC87120...@acay.com.au>...
>A little out-of-date , aren't we?
>
>Sun stopped charging Solaris licence fees on the smaller systems
>(< 8 CPUs) last year, so that one's old hat.
>The Netra X1 is a nice 1U system which costs about the same as a
>mid-range
Wow thats actually pretty cool :) Didn't know that. Don't you
think they did that is response to Linux?
>Linux *is* very good; so is Solaris. Linux isn't cheaper any more.
>Solaris also has the advantage of better scalability on bigger
boxes,
>though the 2.4 kernel may have caught up.
The 2.4 kernal has several features that are of interest to mid and
high end users. Does that license free version of Solaris include
all the features that the pay versions have?
You may very well be right but I think that you would agree that
people should at least look into linux. For example, isn't it
possible that you could at least buy the linux hardware cheaper?
>BTW, I consider 3 CPUs per retail outlet to be vast overkill!
That was an example of an actual chain-- Radio Shack. I used to
work there when I was in college. I think you'll find that must
cash registers used in large stores are actually PCs of some kind.
Some may be thin client.
gbp
>IBM head honcho when discussing IBM's big investment in Linux
recently
>stated that even the 2.4.x kernel has trouble scaling well to
greater
>than 4 CPUs. I'm a linux advocate and was disappointed to hear
this.
>The great thing about Linux though, is that this is likely to
change
>a lot faster than any closed source based OS could hope to do.
>
It may or may not be true I don't know. IBM makes big money on
multi CPU servers so I wouldn't take that at face value.
To be fair I used an IBM mid-range (2-4 CPU F40) and it was great.
It had some features that Linux doesn't have and the thing didn't
crash once that I remember. Their administration tool, smit, was
ten times better than anything available for Linux. We also had a
great emergency replacement policy from them. Of course it cost
about $10,000.... :)
cjt & trefoil
>
> GreyCloud wrote in message ...
>
> >I highly doubt Sun will disappear from the market place, but
> >will instead keep growing. It'll be awhile before MS comes out with
> >their 64-bit O/S, which isn't available now. Also the itantium
> >processor from intel is still having problems. It was supposed to be
> >out last August, but its still in very limited quantities. Linux has
> >IA-64 version ready for it, and HP has reportedly developed a UNIX
> >version for it. The bad part of the Pentium IV right now is its heat
> >dissipation... 54 watts. Yet the sparc chip doesn't dissipate that much
> >power. With the rolling black outs and the political push to conserve
> >power, intels going to have a temporary image problem.
>
> Intel has countless billions in profits to invest in making it work. No one
> in the computer industry has the profit margins and profits of Intel. In an
> historic downturn like this, the name of the game is available resources.
>
> Once it does work, then Intel has the resources to create fabrication plants
> to build in economical quatities.
>
> As far as the CA power situation, Intel was the only one to drop out of
> those who advocated the power deregulation fiasco.
>
> 2 + 2
>
> >
> > V
Itel's strength is simultaneously its weakness. All that legacy code.
They have to keep it working. But its existence drives their market.
IMHO.
none
>
>Shane Phelps wrote in message <3AC87120...@acay.com.au>...
>
>>A little out-of-date , aren't we?
>>
>>Sun stopped charging Solaris licence fees on the smaller systems
>>(< 8 CPUs) last year, so that one's old hat.
>>The Netra X1 is a nice 1U system which costs about the same as a
>>mid-range
>
>Wow thats actually pretty cool :) Didn't know that. Don't you
>think they did that is response to Linux?
>
>>Linux *is* very good; so is Solaris. Linux isn't cheaper any more.
>>Solaris also has the advantage of better scalability on bigger
>boxes,
>>though the 2.4 kernel may have caught up.
>
>
>The 2.4 kernal has several features that are of interest to mid and
>high end users. Does that license free version of Solaris include
>all the features that the pay versions have?
>You may very well be right but I think that you would agree that
>people should at least look into linux. For example, isn't it
>possible that you could at least buy the linux hardware cheaper?
Doesn't Solaris run on Intel? Why would the hardware be cheaper? Low
system requirements? Miniscule, if even true.
>
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
With Seven Servers In California And Texas - The Worlds Uncensored News Source
Jonathan Thornburg
Aaron R. Kulkis <aku...@yahoo.com> wrote:
>modern "RISC-based" CPUs are indistinguishable
>from modern "CISC-based" CPUs.
In article <9a5cl7$mlu$1...@nyheter.chalmers.se>,
Mats Olsson <ma...@dtek.chalmers.se> pointed out that
> Almost indistinguishable. The "CISC" ones have a CISC->RISC translation
>stage when code is loaded from memory. Costs a bit, but nowadays more than
>offset by being on the leading edge process wise.
The article
http://www.realworldtech.com/insider/RISC-vs-CISC-1.cfm
"RISC vs. CISC Still Matters"
By Paul DeMone, Feb 13, 2000
gives a nice introduction to this.
--
-- Jonathan Thornburg <jth...@thp.univie.ac.at>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Q: Only 6 countries have the death penalty for children. Which are they?
A: Congo, Iran, Nigeria, (Pakistan[*]), Saudi Arabia, United States, Yemen
[*] Pakistan reportedly ended it in July 2000. -- Amnesty International
http://www.web.amnesty.org/ai.nsf/index/AMR511392000
2 + 2
Jonathan Thornburg wrote in message <9ad4u3$v9g$1...@mach.thp.univie.ac.at>...
>In article <3AC5DC45...@yahoo.com>,
>Aaron R. Kulkis <aku...@yahoo.com> wrote:
>>modern "RISC-based" CPUs are indistinguishable
>>from modern "CISC-based" CPUs.
>
>In article <9a5cl7$mlu$1...@nyheter.chalmers.se>,
>Mats Olsson <ma...@dtek.chalmers.se> pointed out that
>> Almost indistinguishable. The "CISC" ones have a CISC->RISC
translation
>>stage when code is loaded from memory. Costs a bit, but nowadays more than
>>offset by being on the leading edge process wise.
>
>The article
> http://www.realworldtech.com/insider/RISC-vs-CISC-1.cfm
> "RISC vs. CISC Still Matters"
> By Paul DeMone, Feb 13, 2000
>gives a nice introduction to this.
Interesting article.
Try this link
http://www.realworldtech.com/page.cfm?ArticleID=RWT021300000000
"The heated competition between Intel and AMD for the lucrative and high
volume PC marketplace has pushed x86 CISC ISA-based microprocessors into
0.18 um CMOS processes well ahead of any RISC ISA-based processor. Besides
higher clock rates, 0.18 um CMOS also permits the integration of large (256
Kbyte) and highly associative, low latency L2 caches within the processor.
As a result, x86 processors have temporarily eclipsed the integer
performance of virtually every RISC processor. However, as always, x86
processors are hopelessly behind nearly every non-embedded control RISC
processor family in floating point performance.
There is no doubt about the power and influence of the x86 processor market
within the semiconductor industry. Last year over 100 million x86 processors
were sold bringing in well over $20 billion in revenue and $ billions in
profit. Contrast that to, say, the Compaq Alpha processor, which might sell
in the several hundred thousand devices per year range and bring in several
hundred millions of dollars of revenue to Compaq's semiconductor partners.
This is why new x86 cores come to market at a much faster pace than high-end
RISC processors and transition to newer and better semiconductor processes
with less delay."
Can Sun battle Intel in chips, IBM in the high end market and Microsoft in
the software platforms areas all at one time with profits in the Dell range
in a DOWNTURN?
2 + 2
Roedy Green
quoted :
>competition between Intel and AMD
That battle has even reached the late night informercials. AMD is
winning the PR battle and may have already taken the yellow jersey
away from Intel in the public's imagination.
Ayende Rahien
"Jonathan Thornburg" <jth...@mach.thp.univie.ac.at> wrote in message
news:9ad4u3$v9g$1...@mach.thp.univie.ac.at...
> In article <3AC5DC45...@yahoo.com>,
> Aaron R. Kulkis <aku...@yahoo.com> wrote:
> >modern "RISC-based" CPUs are indistinguishable
> >from modern "CISC-based" CPUs.
>
> In article <9a5cl7$mlu$1...@nyheter.chalmers.se>,
> Mats Olsson <ma...@dtek.chalmers.se> pointed out that
> > Almost indistinguishable. The "CISC" ones have a CISC->RISC
translation
> >stage when code is loaded from memory. Costs a bit, but nowadays more
than
> >offset by being on the leading edge process wise.
>
> The article
> http://www.realworldtech.com/insider/RISC-vs-CISC-1.cfm
> "RISC vs. CISC Still Matters"
> By Paul DeMone, Feb 13, 2000
> gives a nice introduction to this.
404 message, sorry.
2 + 2
Roedy Green wrote in message ...
>On Tue, 3 Apr 2001 15:20:57 -0400, "2 + 2" <2...@web.com> wrote or
>quoted :
>
>>competition between Intel and AMD
>
>That battle has even reached the late night informercials. AMD is
>winning the PR battle and may have already taken the yellow jersey
>away from Intel in the public's imagination.
AMD brings great competition. However, the big story is in the server chip
competition that the Intel McKinley brings to the market. Add considerations
of how this impacts the hardware abstraction layers of .NET and Java and it
is very big. And this is a topic about which it is hard to get good info on.
My view is that Sun is doing very little in chips that others couldn't do.
However, it is important to the computer industry that Sun do well with the
Java Platform.
2 + 2
Jonathan Thornburg
>> The article
>> http://www.realworldtech.com/insider/RISC-vs-CISC-1.cfm
>> "RISC vs. CISC Still Matters"
>> By Paul DeMone, Feb 13, 2000
>> gives a nice introduction to this.
Oops, my apologies, it's been pointed out that that URL is broken.
It should be
http://www.realworldtech.com/page.cfm?ArticleID=RWT021300000000
I've just checked, and that URL is alive and well...
J Perry Fecteau
"2 + 2" <2...@web.com> wrote in message
news:9ad7pl$50$1...@slb0.atl.mindspring.net...
> Can Sun battle Intel in chips, IBM in the high end market and Microsoft in
> the software platforms areas all at one time with profits in the Dell
range
> in a DOWNTURN?
i'm betting my bank on it!
cjt & trefoil
>
<snip>
>
> Can Sun battle Intel in chips, IBM in the high end market and Microsoft in
> the software platforms areas all at one time with profits in the Dell range
> in a DOWNTURN?
>
They have been for some time, quite effectively IMHO.
Hugh Bonney
: Can Sun battle Intel in chips, IBM in the high end market and Microsoft in
: the software platforms areas all at one time with profits in the Dell range
: in a DOWNTURN?
Well, the retreating tide lowers all the boats...
Unless Intel can generate enough FUD to cause disinvestment in other
architectures, why would anyone think IA-64 that much of a threat?
They did seem to be trying to do that before it appeared. Now they
are busy telling us to not pay attention to the man behind the
curtain,
H.---
cjt & trefoil
Roedy Green
<hfbo...@bolt.sonic.net> wrote or quoted :
> IA-64
How different is this architecture from the 486? Did they make it
more RISC-like? Did they add more registers? Does it have any
features that would make it better suited for writing fast
interpreters?
Roedy Green
wrote or quoted :
>How different is this architecture from the 486? Did they make it
>more RISC-like? Did they add more registers? Does it have any
>features that would make it better suited for writing fast
>interpreters?
I did some poking around on the Intel site reading up on the Itanium
Here is what I discovered in a nutshell.
Intel's new line of 64 bit cpu chips, formerly known as Merced. There
are future chips coded named McKinley, Deerfield and Madison. It has a
10-stage pipeline and 128 integer and 128 floating point registers.
Instructions are 41 bits, packed 3 together into 128 bit bundles, with
a 5 bit template that encodes the instruction types in each slot. It
is a CISC design, though quite different from the Pentium. The
instruction formats are quite complex, but not quite as complex as the
Pentium. It has many instructions for bit fiddling and interleaving.
It has instructions for the compiler to give it performance hints.
Register instructions typically use two operands and a destination.
There are a number of parallel instructions that do two sets of
operands at once.
Larry Kilgallen
> In comp.arch 2 + 2 <2...@web.com> wrote:
> : Can Sun battle Intel in chips, IBM in the high end market and Microsoft in
> : the software platforms areas all at one time with profits in the Dell range
> : in a DOWNTURN?
>
> Well, the retreating tide lowers all the boats...
Except those that are already aground.
==============================================================================
Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters
==============================================================================
Peter da Silva
cjt & trefoil <chel...@prodigy.net> wrote:
> At what point does Intel just throw in the towel on IA-64?
I dunno. I've had the Alpha "yawning cheetah" ad[1] up on our corporate
notice board for over a year now, and IA64 seems no closer to reality.
[1] Caption something like "Come on Intel, we're still waiting."
--
`-_-' In hoc signo hack, Peter da Silva.
'U` "A well-rounded geek should be able to geek about anything."
-- nic...@esperi.org
Disclaimer: WWFD?
Nick Maclaren
In article <9af0u5$u...@web.nmti.com>, pe...@abbnm.com (Peter da Silva) writes:
|> In article <3ACAC40A...@prodigy.net>,
|> cjt & trefoil <chel...@prodigy.net> wrote:
|> > At what point does Intel just throw in the towel on IA-64?
|>
|> I dunno. I've had the Alpha "yawning cheetah" ad[1] up on our corporate
|> notice board for over a year now, and IA64 seems no closer to reality.
|>
|> [1] Caption something like "Come on Intel, we're still waiting."
It would be nice, however, if that wasn't so horribly accurate.
Pretty well all the Alpha does seem to have done in the past two
years is to wait complacently for Intel to catch up :-(
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Roedy Green
quoted :
>[1] Caption something like "Come on Intel, we're still waiting."
They have produced SOME. What's the hold up?
-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/jgloss.html or http://209.153.246.39/jgloss.html
If you don't see what you were looking for, complain!
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963
Ready to take on new work.
Craig Kelley
> In article <3ACAC40A...@prodigy.net>,
> cjt & trefoil <chel...@prodigy.net> wrote:
> > At what point does Intel just throw in the towel on IA-64?
>
> I dunno. I've had the Alpha "yawning cheetah" ad[1] up on our corporate
> notice board for over a year now, and IA64 seems no closer to reality.
>
> [1] Caption something like "Come on Intel, we're still waiting."
Too bad IA32 chips run faster than Alphas now. :)
--
It won't be long before the CPU is a card in a slot on your ATX videoboard
Craig Kelley -- kell...@isu.edu
http://www.isu.edu/~kellcrai finger i...@inconnu.isu.edu for PGP block
Alexis Cousein
> Too bad IA32 chips run faster than Alphas now. :)
Too bad they're IA*32*, though, and can't address more than 4GB.
--
Alexis Cousein Senior Systems Engineer
SGI Belgium and Luxemburg a...@brussels.sgi.com
Ben L. Titzer
> Craig Kelley wrote:
>
> > Too bad IA32 chips run faster than Alphas now. :)
>
> Too bad they're IA*32*, though, and can't address more than 4GB.
>
Well, the physical address bus is 36 bits these days, which means 64gb,
but the virtual address space for processes is still 32 bits or 4gb. The
physical address extensions (PAE) were introduced in the Pentium Pro
series, and AMD included support for them in the Athlon (K7). These
extensions require modifications to the page tables and thus, OS support.
Alexis Cousein
> On Wed, 4 Apr 2001, Alexis Cousein wrote:
>
>
>> Craig Kelley wrote:
>>
>>
>>> Too bad IA32 chips run faster than Alphas now. :)
>>
>> Too bad they're IA*32*, though, and can't address more than 4GB.
>>
>
>
> Well, the physical address bus is 36 bits these days, which means 64gb,
> but the virtual address space for processes is still 32 bits or 4gb. The
> physical address extensions (PAE) were introduced in the Pentium Pro
> series, and AMD included support for them in the Athlon (K7). These
> extensions require modifications to the page tables and thus, OS support.
>
While arguably you could use these to support a kernel that handles more
than 4GB, I doubt many *applications* would actually be able to use more
than 2 or 4GB, at least not without another ILP model than that normally
used (ILP32).
mth...@cix.compulink.co.uk
<Pine.GSO.3.96.101040...@expert.cc.purdue.edu>,
> > Craig Kelley wrote:
> >
> > > Too bad IA32 chips run faster than Alphas now. :)
> >
> > Too bad they're IA*32*, though, and can't address more than 4GB.
> >
>
> Well, the physical address bus is 36 bits these days, which means 64gb,
> but the virtual address space for processes is still 32 bits or 4gb. The
> physical address extensions (PAE) were introduced in the Pentium Pro
> series, and AMD included support for them in the Athlon (K7). These
> extensions require modifications to the page tables and thus, OS
> support.
Of course the 4GB limit only applies if you insist on a flat address space
for processes. IA32 has always supported a larger segmented address space.
Admittedly the number of OS which support user processes with large
(segmented) address spaces is very small.
Mark Thornton
mth...@cix.compulink.co.uk
(Alexis Cousein) wrote:
> >
> >
> > Well, the physical address bus is 36 bits these days, which means
> > 64gb,
> > but the virtual address space for processes is still 32 bits or 4gb.
> > The
> > physical address extensions (PAE) were introduced in the Pentium Pro
> > series, and AMD included support for them in the Athlon (K7). These
> > extensions require modifications to the page tables and thus, OS
> > support.
> >
>
> While arguably you could use these to support a kernel that handles
> more than 4GB, I doubt many *applications* would actually be able to
> use more than 2 or 4GB, at least not without another ILP model than
> that normally used (ILP32).
Writing a Java VM that used the IA32 segmented memory model wouldn't be
much more difficult than an ordinary VM. Java applications would run as
normal in such a JVM.
Mark Thornton
Peter da Silva
Alexis Cousein <a...@brussels.sgi.com> wrote:
> >>> Too bad IA32 chips run faster than Alphas now. :)
IA32 has occasionally jumped ahead of RISC for integer, but IIRC they're
still way back in FP.
> > Well, the physical address bus is 36 bits these days, which means 64gb,
> > but the virtual address space for processes is still 32 bits or 4gb. The
> > physical address extensions (PAE) were introduced in the Pentium Pro
> > series, and AMD included support for them in the Athlon (K7). These
> > extensions require modifications to the page tables and thus, OS support.
There's a special hotrodded version of Windows NT that has support for it
but IIRC only one version of Oracle actually uses it.
> While arguably you could use these to support a kernel that handles more
> than 4GB, I doubt many *applications* would actually be able to use more
> than 2 or 4GB, at least not without another ILP model than that normally
> used (ILP32).
What they do is play with the page tables. It's very much like the original
QEMM and LIM hacks to get more than 1M in 80x86 real mode under DOS: you
make system calls to overlay bits of high (>2G) memory in your 2G address
range.
I don't see how it'd be any faster than memory mapping the database and moving
the offset, unless the Win32 memory mapping is particularly inefficient.
Paul Repacholi
> pe...@abbnm.com (Peter da Silva) writes:
>
> > In article <3ACAC40A...@prodigy.net>,
> > cjt & trefoil <chel...@prodigy.net> wrote:
> > > At what point does Intel just throw in the towel on IA-64?
> >
> > I dunno. I've had the Alpha "yawning cheetah" ad[1] up on our corporate
> > notice board for over a year now, and IA64 seems no closer to reality.
> >
> > [1] Caption something like "Come on Intel, we're still waiting."
>
> Too bad IA32 chips run faster than Alphas now. :)
Oh, care to point to the numbers?
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
Jan Ingvoldstad
said:
> Craig Kelley <i...@inconnu.isu.edu> writes:
>> Too bad IA32 chips run faster than Alphas now. :)
> Oh, care to point to the numbers?
Intel isn't _quite_ there yet, but pretty darn close to be able to
claim the crown.
SPEC CPU2000:
CINT2000:
Pentium 4 @1.5 GHz:
http://www.specbench.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00332.html
Alpha 21264B @833 MHz:
http://www.specbench.org/osg/cpu2000/results/res2000q4/cpu2000-20001023-00277.html
CFP2000:
Pentium 4 @1.5 GHz:
http://www.specbench.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00336.html
Alpha 21264B @833 MHz:
http://www.specbench.org/osg/cpu2000/results/res2000q4/cpu2000-20001023-00274.html
STREAM:
Web pages currently unavailable, but try
http://www.cs.virginia.edu/stream/ later on.
IIRC, the P4 turned in relatively impressive results.
--
In the beginning was the Bit, and the Bit was Zero. Then Someone
said, Let there be One, and there was One. And Someone blessed them,
and Someone said unto them, Be fruitful, and multiply, and replenish
the Word and subdue it: and have dominion over every thing that is.
Brig Campbell
"Peter da Silva" <pe...@abbnm.com> wrote in message
news:9afkup$c...@web.nmti.com...
> In article <3ACB4A26...@brussels.sgi.com>,
> Alexis Cousein <a...@brussels.sgi.com> wrote:
> > >>> Too bad IA32 chips run faster than Alphas now. :)
>
> IA32 has occasionally jumped ahead of RISC for integer, but IIRC they're
> still way back in FP.
>
> > > Well, the physical address bus is 36 bits these days, which means
64gb,
> > > but the virtual address space for processes is still 32 bits or 4gb.
The
> > > physical address extensions (PAE) were introduced in the Pentium Pro
> > > series, and AMD included support for them in the Athlon (K7). These
> > > extensions require modifications to the page tables and thus, OS
support.
>
> There's a special hotrodded version of Windows NT that has support for it
> but IIRC only one version of Oracle actually uses it.
>
It's supported in Windows 2000 along with the API for applications.
Page Address Extension
http://www.microsoft.com/WINDOWS2000/en/datacenter/help/paex86_2.htm
Address Windowing Extensions
http://www.microsoft.com/WINDOWS2000/en/datacenter/help/address_windowing_ex
tensions.htm
-brig
Rick C. Hodgin
>than 4GB, I doubt many *applications* would actually be able to use more
>than 2 or 4GB, at least not without another ILP model than that normally
>used (ILP32).
I doubt there are any kernels that would need more than 4GB. But as
far as accessing more than 4GB in an application, that is very easy.
Most "data warehouses" (I hate that term) are much larger than 4GB.
They could benefit from the speed enhancements over a strictly hard
drive system.
Does anyone know of an IA-32 motherboard that allows more than 4GB of
memory to be installed? Or is this functionality reserved for special
equipment?
- Rick C. Hodgin
Ben L. Titzer
> >> Well, the physical address bus is 36 bits these days, which means 64gb,
> >While arguably you could use these to support a kernel that handles more
> >than 4GB, I doubt many *applications* would actually be able to use more
> >than 2 or 4GB, at least not without another ILP model than that normally
> >used (ILP32).
>
> I doubt there are any kernels that would need more than 4GB. But as
> far as accessing more than 4GB in an application, that is very easy.
> Most "data warehouses" (I hate that term) are much larger than 4GB.
> They could benefit from the speed enhancements over a strictly hard
> drive system.
>
Compaq has several Xeon based servers (4x, 8x, and even more) that have up
to 32 and 64gb of physical RAM. Any kernel running on those machines
wouldn't "need" that much memory; it would of course, have to manage it,
though, for user applications. Versions of Windows 2000 server have
support for these large memory spaces, and I *think* there may be Linux
support. Plus whatever OSes companies like Compaq and HP have running on
their "big-iron" Intel boxes probably have PAE support as well.
> Does anyone know of an IA-32 motherboard that allows more than 4GB of
> memory to be installed? Or is this functionality reserved for special
> equipment?
>
No, I don't believe there are any such motherboards available to end
users. Usually those large address spaces are reserved for the
multiprocessor (4x or more) systems, which generally aren't available
directly to consumers. Dell, HP, and Compaq all have several Intel based
solutions that have address spaces larger than 4gb.
> - Rick C. Hodgin
>
>
>
Robert Harley
Really? You should let SPEC know that, because they're under the
impression that an 833 MHz Alpha peaks at 544 versus 539 for a 1.33
GHz Athlon and 536 for a 1.5 GHz Pentium 4 on CINT2000. And it's 658
versus 445 or 558 on CFP2000.
Bye,
Rob.
.-. Robert...@polytechnique.org .-.
/ \ .-. .-. / \
/ \ / \ .-. _ .-. / \ / \
/ \ / \ / \ / \ / \ / \ / \
/ \ / \ / `-' `-' \ / \ / \
\ / `-' `-' \ /
`-' http://www.xent.com/~harley/Top.html `-'
Andi Kleen
> Compaq has several Xeon based servers (4x, 8x, and even more) that have up
> to 32 and 64gb of physical RAM. Any kernel running on those machines
> wouldn't "need" that much memory; it would of course, have to manage it,
Actually it would -- for program/data cache if your application doesn't cache
itself
(pretty much anything except for databases)
> though, for user applications. Versions of Windows 2000 server have
> support for these large memory spaces, and I *think* there may be Linux
> support. Plus whatever OSes companies like Compaq and HP have running on
> their "big-iron" Intel boxes probably have PAE support as well.
Linux 2.4 supports PAE, but has no support for "address window extensions"
or other such horrible things. It also needs bounce buffers for high IO.
-Andi
Bruce Hoult
<har...@corton.inria.fr> wrote:
> Craig Kelley <i...@inconnu.isu.edu> writes:
> > Too bad IA32 chips run faster than Alphas now. :)
>
> Really? You should let SPEC know that, because they're under the
> impression that an 833 MHz Alpha peaks at 544 versus 539 for a 1.33
> GHz Athlon and 536 for a 1.5 GHz Pentium 4 on CINT2000. And it's 658
> versus 445 or 558 on CFP2000.
Didn't know it was *that* close!
That means that next week, or next month, or next quarter, the x86
*will* be faster :-(
On a slightly different track, are there any numbers yet for the 733 MHz
PowerPC G4+?
-- Bruce
Ben L. Titzer
> "Ben L. Titzer" <tit...@expert.cc.purdue.edu> writes:
>
>
> > Compaq has several Xeon based servers (4x, 8x, and even more) that have up
> > to 32 and 64gb of physical RAM. Any kernel running on those machines
> > wouldn't "need" that much memory; it would of course, have to manage it,
>
> Actually it would -- for program/data cache if your application doesn't cache
> itself
> (pretty much anything except for databases)
>
I'm not exactly sure what you mean by this. The OS has to *manage* all of
physical memory pages and portion them out to processes as usual. It's not
particularly tricky, even with more than 4gb worth of physical pages. Each
application still only has 4gb of virtual address space. Each process would
have to have more complicated scheme to manage more than 4gb memory
(handle based probably), but that wasn't what I was talking about.
PAE support in the kernel is really a trivial addition, it only
requires modifications to the page tables (3 levels instead of 2) in order
to allow applications to be mapped into physical memory pages above 4gb.
Where it gets complicated is the whole handle-based memory allocation
schemes in order to let a process play with more memory. Each application
(and hell, even the OS(1)) can only address 4gb of memory at one time.
(1) Most OSes don't have to directly address all of physical memory in
order to manage it. Instead it keeps track of pages of physical
memory indirectly and maps them into the address space as needed. Also,
most OSes actually run in a reserved portion of the virtual address spaces
of all processes that remains common across all processes. This is so that
an address space switch doesn't need to occur (expensive computationally
for the processor) in order for the OS to take control.
> > though, for user applications. Versions of Windows 2000 server have
> > support for these large memory spaces, and I *think* there may be Linux
> > support. Plus whatever OSes companies like Compaq and HP have running on
> > their "big-iron" Intel boxes probably have PAE support as well.
>
> Linux 2.4 supports PAE, but has no support for "address window extensions"
> or other such horrible things. It also needs bounce buffers for high IO.
>
That's what I figured about Linux. I'm not too sure about other OSes like
Solaris and HP-UX.
-Ben
_________________________________________________
Close Windows and Open Doors - www.redpants.org
Roedy Green
<foxm...@voyager.net> wrote or quoted :
>Does anyone know of an IA-32 motherboard that allows more than 4GB of
>memory to be installed? Or is this functionality reserved for special
>equipment?
It boggles the mind. It seems just yesterday I was working on 4K, 8K
and 16K machines.
We always seem to underestimate how fast we will run out of addressing
bits. What is the guess on how long 64 bits will be enough?
-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/jgloss.html or http://209.153.246.39/jgloss.html
If you don't see what you were looking for, complain!
or send your contribution for the glossary.
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963.
Almost ready to take on new work.
Eric Smith
> Too bad IA32 chips run faster than Alphas now. :)
Alexis Cousein <a...@brussels.sgi.com> writes:
> Too bad they're IA*32*, though, and can't address more than 4GB.
Only a per-process virtual memory limit. And it might be possible
to circumvent that. Remeber how on the PDP-11 big programs used separate
I&D space (64 Kbytes each)? Well, IIRC on the x86 (x>=3) you can have
multiple segments that are up to 4G each. So you could easily have
a 4G instruction segment and a 4G data segment, without requiring
nastiness in C code like near and far pointers.
Probably not enough of a win to be worthwhile, though. Personally, I have
yet to encounter an executable bigger than 1.5G.
Ben L. Titzer
> Craig Kelley wrote:
> > Too bad IA32 chips run faster than Alphas now. :)
>
> Alexis Cousein <a...@brussels.sgi.com> writes:
> > Too bad they're IA*32*, though, and can't address more than 4GB.
>
> Only a per-process virtual memory limit. And it might be possible
> to circumvent that. Remeber how on the PDP-11 big programs used separate
> I&D space (64 Kbytes each)? Well, IIRC on the x86 (x>=3) you can have
> multiple segments that are up to 4G each. So you could easily have
> a 4G instruction segment and a 4G data segment, without requiring
> nastiness in C code like near and far pointers.
>
No, segmentation is on top of paging, so that the segments must live
within the 4gb virtual address space. I suppose its conceivable to alter
the hardware to let each segment have its own address space, but it would
totally fsck the operation of most OSes...
Andi Kleen
> > Actually it would -- for program/data cache if your application doesn't cache
> > itself
> > (pretty much anything except for databases)
> >
>
> I'm not exactly sure what you mean by this. The OS has to *manage* all of
> physical memory pages and portion them out to processes as usual. It's not
> particularly tricky, even with more than 4gb worth of physical pages. Each
> application still only has 4gb of virtual address space. Each process would
> have to have more complicated scheme to manage more than 4gb memory
> (handle based probably), but that wasn't what I was talking about.
On many boxes most/a lot memory is needed for caching file data. It's (usually)
the OS' job to cache file data. For that it may need more than 4GB of memory,
which may be not mapped to user processes. The processes can easily use
that additional memory by using normal IO calls.
For that you better either have IO devices that can address all your memory
though or have an IO-MMU in the chipset, which can be quite complicated,
e.g. the Sun ones are very fancy and can manage thousands of mappings at a
time.
To get back on topic for comp.arch: does anybody have any thoughts on the
design of IO-MMUs ? Should they contain few parallel mappings or many
(which implies a cache and a memory backed table) ?
-Andi
cjt & trefoil
Ben L. Titzer
> Is Intel doing anything to up the clock on the Alpha?
:D
I think they are, indirectly, but wouldn't you agree that's more of
Compaq's problem? :)
Casper H.S. Dik - Network Security Engineer
"Ben L. Titzer" <tit...@expert.cc.purdue.edu> writes:
>That's what I figured about Linux. I'm not too sure about other OSes like
>Solaris and HP-UX.
Solaris support PAE. It can use all of memory as a filesystem
cache and additionally supports a "memory filesystem", xmemfs,
that can be used to access large memory-resident amounts of
data.
(If you want windowing, you could implement it using mmap on
xmemfs files)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Jan Vorbrueggen
> [...] an 833 MHz Alpha peaks at 544 versus 539 for a 1.33
> GHz Athlon and 536 for a 1.5 GHz Pentium 4 on CINT2000.
This is really within measurement error - see the variability of the results
for equivalent Pentium IV systems, which is in that range.
Jan
Terje Mathisen
>
> Craig Kelley wrote:
> > Too bad IA32 chips run faster than Alphas now. :)
>
> Alexis Cousein <a...@brussels.sgi.com> writes:
> > Too bad they're IA*32*, though, and can't address more than 4GB.
>
> Only a per-process virtual memory limit. And it might be possible
> to circumvent that. Remeber how on the PDP-11 big programs used separate
> I&D space (64 Kbytes each)? Well, IIRC on the x86 (x>=3) you can have
> multiple segments that are up to 4G each. So you could easily have
> a 4G instruction segment and a 4G data segment, without requiring
> nastiness in C code like near and far pointers.
As seen from user mode, any x86 should allow simultaneous access to at
least 16 or 20 GB of ram, by using segment overrides (and 48-bit
addresses!) to access extra 4GB segments.
These areas would then be addressed with the ES, FS and GS segment
segisters, you could also split out CS and SS from the base DS segment,
for a theoretical limit of 6*4 = 24 GB of directly addressable RAM.
This would effectively be the same as the old 'large mode' apps in the
16-bit days.
However, afaik, these segment regs all have to point into the same 4GB
region, so both the hw and os must be modified to allow such a hack. :-(
Terje
--
- <Terje.M...@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
Andreas Krall
Bruce Hoult <br...@hoult.org> writes:
>
> On a slightly different track, are there any numbers yet for the 733 MHz
> PowerPC G4+?
>
Only estimated spec95 numbers (MPC7450):
SPECint95 32.1 SPECfp 23.9
Estimated numbers for the 667MHz 750CXe (G3 with 256Kb on chip L2):
SPECint95 27.8 SPECfp 17.1
--
an...@complang.tuwien.ac.at Andreas Krall
http://www.complang.tuwien.ac.at/andi/ Inst. f. Computersprachen, TU Wien
tel: (+431) 58801/18511 Argentinierstr. 8/4/1851
fax: (+431) 58801/18598 A-1040 Wien AUSTRIA EUROPE
Peter da Silva
Eric Smith <eric-no-s...@brouhaha.com> wrote:
> Only a per-process virtual memory limit. And it might be possible
> to circumvent that. Remeber how on the PDP-11 big programs used separate
> I&D space (64 Kbytes each)? Well, IIRC on the x86 (x>=3) you can have
> multiple segments that are up to 4G each. So you could easily have
> a 4G instruction segment and a 4G data segment, without requiring
> nastiness in C code like near and far pointers.
Now this is what really ticks me off. For over a decade we had to deal with
the nastiness of 64k segments, and now when 4G segments would actually be
useful Intel and Microsoft come up with a bizzarre windowing scheme to address
memory beyond the 4G limit instead.
I agree, though, split I&D isn't likely to buy you much here... if you need
more than a couple of gigabytes you need it in the data segment.
Oleg Krivosheev
PAE is supported in some way in UNixware 7.x
> I'm not too sure about other OSes like
> Solaris and HP-UX.
have no idea aboutSolaris but HP-UX doesn't work on IA32 IMHO
>
> -Ben
>
> _________________________________________________
> Close Windows and Open Doors - www.redpants.org
OK
Ermine Todd III
systems for some private development. The key is that this is first version
of the IA-64 architecture and like the early Pentium Pro's, was slower at
some old stuff. The next version of Windows (XP) does have a native 64bit
version that runs on the chip. The real chip that people are looking for is
McKinley.
--ET--
Good Sense is Seldom "Common"
"Roedy Green" <ro...@mindprod.com> wrote in message
news:e46mctsgjqvnd4l0v...@4ax.com...
> On 4 Apr 2001 11:35:33 GMT, pe...@abbnm.com (Peter da Silva) wrote or
> quoted :
>
> >[1] Caption something like "Come on Intel, we're still waiting."
>
> They have produced SOME. What's the hold up?
>
>
> -
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at:
> http://mindprod.com/jgloss.html or http://209.153.246.39/jgloss.html
> If you don't see what you were looking for, complain!
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963
> Ready to take on new work.
>
Kevin Strietzel
...
> For that you better either have IO devices that can address all your memory
> though or have an IO-MMU in the chipset, which can be quite complicated,
> e.g. the Sun ones are very fancy and can manage thousands of mappings at a
> time.
>
> To get back on topic for comp.arch: does anybody have any thoughts on the
> design of IO-MMUs ? Should they contain few parallel mappings or many
> (which implies a cache and a memory backed table) ?
There have been systems where all or some of the I/O DMA hardware only
had access to some of the memory; e.g., the bottom 16MB. This can be
tolerated, if you can convince the operating system to preferentially
allocate that bottom 16MB (or whatever) to I/O buffers.
You can also use an I/O MMU to protect the system against I/O adapters
that go bonkers and use wild memory addresses. I don't know whether
such adapters are a big problem, but there's enough complex hardware and
software in some adapters for this to be a real risk.
There should be, of course, as few mappings as possible, but no fewer!
Some I/O adapters seem to want to have live access to multiple buffers;
presumably they have a command list and a response list, as well as data
buffers. Systems with many in-fly I/O operations may want many live
mapping. It's like a TLB: too few entries, and you have delays (or lots
of interrupts) to handle frequent misses; too many entries, and you
could have used the real-estate more effectively for something else or
lowered the price.
For example, a network adapter may want a large buffer into which to put
received frames, or you may want to be able to queue up many outgoing
frames for it. Maybe you have multiple sync comm lines at 56Kbit/s (or
less) and they take seemingly forever to drain or fill a buffer.
For example, you're using file systems with 16KB blocks, and your MMU
maps 4KB pages, so you want four mappings for each transfer.
Stratus (my employer) discovered that it was inconvenient (but possible)
to use 1024 mappings to support eight PCI cards; I'm not certain, but I
believe they're 4KB pages. We went up to 4096 mappings in the next
model, and that's conveniently roomy. 1024 was plenty for the default
configuration of three SCSI HBAs (one card), an Ethernet adapter, and a
flash RAM card. But things got tight when adding an extra SCSI card or
two (3 ports each) and maybe a couple dual-port Ethernet adapters!
--Kevin Strietzel
At Stratus Technologies, for whom I do not speak.
PS - On second thought, I don't know the actual hardware
implementation. I know all the mappings are handled in the hardware,
but I *don't* know whether they're all simultaneously live (lots of
comparators!) or whether it's a TLB + page-table-in-memory setup.
Peter da Silva
all the extra RAM into a big buffer cache and mmapping regions of the database
into 32-bit memory. If the memory mapping API isn't good enough to do this
efficiently, then improving that API and implementation would have far greater
benefits than this mess... at any rate it doesn't provide any of the advantages
large address spaces give you, and it doesn't require large address spaces to
implement efficiently.
Douglas Siebert
>In article <bruce-6BED71....@news.nzl.ihugultra.co.nz>,
> Bruce Hoult <br...@hoult.org> writes:
>>
>> On a slightly different track, are there any numbers yet for the 733 MHz
>> PowerPC G4+?
>>
>Only estimated spec95 numbers (MPC7450):
> SPECint95 32.1 SPECfp 23.9
Well, anyone with a SPEC license and a MacOS X CD ought to be able to
produce results pretty easily. I'm sure there are plenty of such,
especially those in .edu land. But without a decent Mac compiler I don't
know if the results will be that great. I don't think the gcc you get
with Darwin/MacOS X developer is gonna be all that good versus the
highly tuned compilers used by Intel and the RISC guys.
Is it still possible to use IBM's C compiler to produce .o files for
Mac OS X as it was in the past for previous versions of Mac OS? That
ought to level the playing field well enough for someone to give this
a shot (assuming they have the time and inclination)
--
Douglas Siebert dsie...@excisethis.khamsin.net
I have discovered a remarkable proof which this .sig is too small to contain!
Nick Maclaren
>Looking at the restrictions on this, you could get better results by tossing
>all the extra RAM into a big buffer cache and mmapping regions of the database
>into 32-bit memory. If the memory mapping API isn't good enough to do this
>efficiently, then improving that API and implementation would have far greater
>benefits than this mess... at any rate it doesn't provide any of the advantages
>large address spaces give you, and it doesn't require large address spaces to
>implement efficiently.
Yes. This is what MVS did, and it worked very well as a temporary
solution. The other great advantage is that only a tiny fraction
of the kernel need know about the extended memory (effectively
just the part that needs to run with address translation off).
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
cjt & trefoil
2 + 2
execution engine or Just In Time compilers? This is a kind of componentized
assembly language (Intermediate Language) that the .NET?
Microsoft has the resources to throw at this Platform Abstraction Layer [TM
Ayende Rahien :) ].
". . . the CLR is able to execute a specific instruction set, known as
Microsoft Intermediate Language (MSIL), the direct embodiment of the VOS
object model. Porting a compiler to dot-NET means, among other things,
retargeting the compiler to generate MSIL instead of, or along with, machine
code or another intermediate language. A distinctive trait of the virtual
machine is that, unlike its Java counterpart, it does not provide an
interpreter: MSIL is meant for on-the-fly compilation to machine code the
first time each MSIL unit is executed. This is also known as "JIT-ting the
code," where JIT stands for Just In Time compilation. Here dot-NET draws on
the lessons of the Java experience (familiar to anyone who has ever seen the
dreaded message "Starting Java" appear in the browser) by putting
performance concerns at the heart of design goals. The results are
impressive: We have seen no difference between the speed of
dot-NET-generated Eiffel# applications and that of code generated through
our standard compiler, which produces machine code through C. The tradeoffs
are clear: Java’s interpreter-oriented design, where JIT compilers are an
afterthought, has fostered portability; dot-NET’s design has put run-time
performance at the top of the design goals. See Bertrand Meyer in "The
Significance of 'dot-NET'" at
http://www.sdmagazine.com/articles/2000/0011/0011l/0011l.htm
2 + 2
Peter da Silva wrote in message <9afkup$c...@web.nmti.com>...
>In article <3ACB4A26...@brussels.sgi.com>,
>Alexis Cousein <a...@brussels.sgi.com> wrote:
>> >>> Too bad IA32 chips run faster than Alphas now. :)
>
>IA32 has occasionally jumped ahead of RISC for integer, but IIRC they're
>still way back in FP.
>
>> > Well, the physical address bus is 36 bits these days, which means 64gb,
>> > but the virtual address space for processes is still 32 bits or 4gb.
The
>> > physical address extensions (PAE) were introduced in the Pentium Pro
>> > series, and AMD included support for them in the Athlon (K7). These
>> > extensions require modifications to the page tables and thus, OS
support.
>
>There's a special hotrodded version of Windows NT that has support for it
>but IIRC only one version of Oracle actually uses it.
>
>> While arguably you could use these to support a kernel that handles more
>> than 4GB, I doubt many *applications* would actually be able to use more
>> than 2 or 4GB, at least not without another ILP model than that normally
>> used (ILP32).
>
>What they do is play with the page tables. It's very much like the original
>QEMM and LIM hacks to get more than 1M in 80x86 real mode under DOS: you
>make system calls to overlay bits of high (>2G) memory in your 2G address
>range.
>
>I don't see how it'd be any faster than memory mapping the database and
moving
>the offset, unless the Win32 memory mapping is particularly inefficient.
anonc...@my-deja.com
> Isn't the big question how Intel new McKinley chip will work with .NET's
> execution engine or Just In Time compilers?
Nah, the big question is whether the Transmeta .NET implementation is already in the bag.
I hear it is.
Roedy Green
quoted :
>We have seen no difference between the speed of
>dot-NET-generated Eiffel# applications and that of code generated through
>our standard compiler, which produces machine code through C. The tradeoffs
>are clear: Java’s interpreter-oriented design, where JIT compilers are an
>afterthought, has fostered portability; dot-NET’s design has put run-time
>performance at the top of the design goals.
I greatly respect Bertrand Meyer, and the fact he had input into .NET
is reason enough to take a serious look at it.
However, I think he erred in that last statement. It has nothing to
do with Java being designed for either interpreter or JIT. This is
Microsoft party line BS. I'm surprised that Meyer would stoop to such
shilldom. He can't claim ignorance. The problem is Sun JITs are aimed
at SERVLETS where start up time is of secondary importance to
execution speed. Sun has almost no interest in the desktop.
Microsoft, in contrast, IS very interested in the desktop. They of
course aim for fast start up. They may be using gespenstering, DLLs,
hibernation or similar techniques to get instant starting.
Meyer said something else interesting in his article: "There is only
one reason Java and dot-NET don’t have multiple inheritance: It makes
dynamic class loading far more difficult to implement."
We have been puzzling why Eiffel style MI was not part of Java.
He further points out that .NET has a more flexible class system that
will support languages other than Java, e.g. even Eiffel and C++
without great strain. The advantage of that approach is it may lead to
a greater choice of development tool, and specialised application
languages that will all interoperate. The disadvantage is that the
generality is extra baggage for pure Java apps.
We programmers probably greatly overestimate the importance of the JVM
and greatly underestimate the importance of the gigantic set of Java
class libraries. Those class libraries are what Java is REALLY about.
-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/jgloss.html or http://209.153.246.39/jgloss.html
If you don't see what you were looking for, complain!
or send your contribution for the glossary.
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963.
Almost ready to take on new work.
Roedy Green
quoted :
>Nah, the big question is whether the Transmeta .NET implementation is already in the bag.
Are they making a chip that uses the MS Intermediate language as its
native instruction set?
Jan Ingvoldstad
> Not when they're manufactured by Intel.
Considering that the really fast Alphas _aren't_ manufactured by
Intel, it's hardly Intel's fault.
--
In the beginning was the Bit, and the Bit was Zero. Then Someone
said, Let there be One, and there was One. And Someone blessed them,
and Someone said unto them, Be fruitful, and multiply, and replenish
the Word and subdue it: and have dominion over every thing that is.
George Coulouris
>Isn't the big question how Intel new McKinley chip will work with .NET's
>execution engine or Just In Time compilers? This is a kind of componentized
>assembly language (Intermediate Language) that the .NET?
IMHO, this question reduces to whether or not the .NET JIT will perform
runtime optimizations analogous to those performed by HP's Dynamo [1].
If I put on my Micrsoft-colored glasses, .NET seems to:
1. provide a runtime which is architecture-independent (ia32, ia64, mips,
sh3, et al.),
2. provide a runtime which is potentially OS-independent, making it easy to
move the MS application base to other OSes (DOJ insurance?),
3. provide a mechanism for extracting better performance out of IA64,
4. move Microsoft towards a renting/leasing/subscription revenue model.
Will be interesting to see how it all pans out for them.
[1] http://www.hpl.hp.com/cambridge/projects/Dynamo/
--
George Coulouris - http://www.tc.cornell.edu/~glc5/
cjt & trefoil
a reference?
Paul Repacholi
> The tradeoffs are clear: Java's interpreter-oriented design, where
> JIT compilers are an afterthought, has fostered portability;
> dot-NET's design has put run-time performance at the top of the
> design goals. See Bertrand Meyer in "The Significance of 'dot-NET'"
> at http://www.sdmagazine.com/articles/2000/0011/0011l/0011l.htm
The trade-off, cough, that I see is dropping portability in the bin.
Re-read the above carefully...
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
Peter da Silva
> Isn't the big question how Intel new McKinley chip will work with .NET's
> execution engine or Just In Time compilers? This is a kind of componentized
> assembly language (Intermediate Language) that the .NET?
Does anyone care? .NET has the same problem as ActiveX... it replaces a
security mechanism with a trust mechanism, and the two are not equivalent.
I can't imagine switching to .NET on any system containing any data I
care about.
ttk_ciar
Once upon a time, cjt & trefoil <chel...@prodigy.net> said:
> Date: Fri, 06 Apr 2001 12:39:56 -0500
>
>Now that's news to me. Who does manufacture them? Can you point me to
>a reference?
>
>Jan Ingvoldstad wrote:
>> On Thu, 05 Apr 2001 20:46:24 -0500, cjt & trefoil <chel...@prodigy.net> said:
>>
>> Considering that the really fast Alphas _aren't_ manufactured by
>> Intel, it's hardly Intel's fault.
Samsung's been manufacturing Alphas for a long time now, qv:
http://www.usa.samsungsemi.com/about/press/archive/alpha21264.htm
This was why most of the comp.arch regulars were scratching their
heads over why everyone thought it was such a big deal that DEC sold
their (obsolete, ill-running) fab plant to Intel. It was a bit of a
white elephant, but somehow everyone got it into their heads that DEC
was selling Alpha ITSELF to Intel.
-- TTK
Del Cecchi
cjt & trefoil <chel...@prodigy.net> writes:
|> Now that's news to me. Who does manufacture them? Can you point me to
|> a reference?
|>
shall find.
Can't believe I am responding on this crossposted thing.
--
Del Cecchi
cecchi@rchland
2 + 2
George Coulouris wrote in message <9akmvc$97$1...@news01.cit.cornell.edu>...
>2...@web.com wrote:
>>Isn't the big question how Intel new McKinley chip will work with .NET's
>>execution engine or Just In Time compilers? This is a kind of
componentized
>>assembly language (Intermediate Language) that the .NET?
>[snip]
>
>IMHO, this question reduces to whether or not the .NET JIT will perform
>runtime optimizations analogous to those performed by HP's Dynamo [1].
>
>If I put on my Micrsoft-colored glasses, .NET seems to:
>
>1. provide a runtime which is architecture-independent (ia32, ia64, mips,
>sh3, et al.),
>
>2. provide a runtime which is potentially OS-independent, making it easy to
>move the MS application base to other OSes (DOJ insurance?),
>
>3. provide a mechanism for extracting better performance out of IA64,
>
>4. move Microsoft towards a renting/leasing/subscription revenue model.
Software as a service started on the server side, partly to counter the
popularity of "shrink wrapped" software.
Now that Microsoft has followed the market, then it becomes a tool of the
devil to certain subgroups.
Consider: "n-tier" development gives great flexibility where functionality
resides physically. E.G., the database tier can be connected by a T-I line
right into a company's physical control (A).
The workflow processing might be an app that is "rent-licensed" on a
vendor's computer either under the control of the vendor (B) or on a
dedicated server at company A.
The business logic might be at on an outsourced web site at still another
vendor, ie web host, facility C.
Licensing practices might vary depending on:
1. what tech support is provided, ie web hosting companies are good at 24/7
operations with web site stuff even if on dedicated servers or not.
2. what app tech support is provided by a workflow app vendor including
upgrades without causing training expense to the customer.
>
>Will be interesting to see how it all pans out for them.
>
>[1] http://www.hpl.hp.com/cambridge/projects/Dynamo/
Nice link. I took it here:
"Compilers
Compiler research has come a long way in the past few years. In fact, it
has come so far that next-generation architectures like Intel's IA-64 (which
I talk about here) depend wholly on the compiler to order instructions for
maximum throughput; dynamic, OOO execution is absent from the Itanium. The
next generation of architectures (IA-64, Transmeta, Sun's MAJC) will borrow
a lot from VLIW designs. VLIW got a bad wrap when it first came out,
because compilers weren't up to the task of ferreting out dependencies and
ordering instructions in packets for maximum ILP. Now however, it has
become feasible, so it's time for a fresh dose of the same medicine that
RISC dished out almost 20 years ago: move complexity from hardware to
software."
http://www.arstechnica.com/cpu/4q99/risc-cisc/rvc-6.html#Compilers
This shows the importance of the PAL (Platform Abstraction Layer) where one
side of the layer is the interface to the programming language and the other
layer interface is the CPU.
Sun will work with integrating MAJC with the Java PAL.
Microsoft will work with integrating IA-64 with the .NET PAL.
2 + 2
Brian Inglis
<eric-no-s...@brouhaha.com> wrote:
>Craig Kelley wrote:
>> Too bad IA32 chips run faster than Alphas now. :)
>
>Alexis Cousein <a...@brussels.sgi.com> writes:
>> Too bad they're IA*32*, though, and can't address more than 4GB.
>
>Only a per-process virtual memory limit. And it might be possible
>to circumvent that. Remeber how on the PDP-11 big programs used separate
>I&D space (64 Kbytes each)? Well, IIRC on the x86 (x>=3) you can have
>multiple segments that are up to 4G each. So you could easily have
>a 4G instruction segment and a 4G data segment, without requiring
>nastiness in C code like near and far pointers.
>
>Probably not enough of a win to be worthwhile, though. Personally, I have
>yet to encounter an executable bigger than 1.5G.
MS W2K or XP perhaps?
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian_...@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
use address above to reply
Brian Inglis
<tit...@expert.cc.purdue.edu> wrote:
>On Wed, 4 Apr 2001, Rick C. Hodgin wrote:
>
>> >> Well, the physical address bus is 36 bits these days, which means 64gb,
>> >While arguably you could use these to support a kernel that handles more
>> >than 4GB, I doubt many *applications* would actually be able to use more
>> >than 2 or 4GB, at least not without another ILP model than that normally
>> >used (ILP32).
>>
>> I doubt there are any kernels that would need more than 4GB. But as
>> far as accessing more than 4GB in an application, that is very easy.
>> Most "data warehouses" (I hate that term) are much larger than 4GB.
>> They could benefit from the speed enhancements over a strictly hard
>> drive system.
>>
>
>Compaq has several Xeon based servers (4x, 8x, and even more) that have up
>to 32 and 64gb of physical RAM. Any kernel running on those machines
>wouldn't "need" that much memory; it would of course, have to manage it,
>though, for user applications. Versions of Windows 2000 server have
>support for these large memory spaces, and I *think* there may be Linux
>support. Plus whatever OSes companies like Compaq and HP have running on
>their "big-iron" Intel boxes probably have PAE support as well.
Their big-iron boxes are not Intel - Alpha and PA-RISC
respectively. They'd probably not push PCs competing with their
high end machines, although they'd probably sell you one if you
wanted to give them that much money. How much cache goes with
your 64GB, and how long does it take to load/save that memory on
a real PCI/UDMA drive?
Ben L. Titzer
I wasn't referring to their Intel boxes as their high end, only referring
to them as "big-iron" Intel...check the original quotation. I meant it
referring to high-end Intel based systems, not high-end systems in
general. Sorry for the confusion.
Paul Repacholi
If you watch comp.os.vms, you will see several posts about Compaq
trying to shove Proliant SMP billyboxes down the throats of VMS/Alpha
sites.