Is Itanium the first 64-bit casualty?

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news😛j97e09ahuh9sdq8ha8go0rv3rvejlbmsi@4ax.com...
> On Wed, 30 Jun 2004 14:42:01 -0600, "Judd" <IhateSpam@stopspam.com>
> wrote:
> >"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
> >news:fts5e0536f09o7c2cj6g0no6jomnvre9u2@4ax.com...
> >>
> >> That's the last of 'em then. It looks like EVERY major Linux
> >> distribution has managed to beat Microsoft to market with a usable
> >> AMD64/x86-64 operating system (at least as long as you don't count
> >> Slackware as a "major distribution", which most people don't these
> >> days). SuSE, RedHat, Mandrake, Gentoo, Turbolinux and now Debian are
> >> all out there now. Debian's distribution is still in the "unstable"
> >> stream, but those who know Debian should know that Debian "unstable"
> >> is roughly equivalent to pre-SP1 release of Windows rather than a beta
> >> version.
> >>
> >> Ohh, and FreeBSD and OpenBSD also have full support for AMD64 as well.
> >> Kind of makes you wonder just what the heck is taking MS so long?!
> >
> >What is taking them so long? Answer = Intel! If 64-bit was such a big
deal
> >for consumers, we would be looking at Itanium Workstations. 64-bit = not
> >big deal = why MS hasn't pushed it very hard. Wait for Intel's 80+
percent
> >market share to join in and then release something for OEM's to sell
their
> >i64 and AMD64 systems. It's a very smart business move.
>
> Smart business move for who?!? For Intel maybe, but how exactly does
> it help MS' cause? It's not like they're selling more by not having a
> product now and I can't see any way that it would help them long-term.
> Not releasing the product until the end of this year or early next
> year (it looks like 64-bit Windows is being delayed *again*) is only
> going to hurt Microsoft relative to Linux.
>

It isn't hurting them at all. Development costs $$$... In today's world,
you don't develop unless the $$$ is there. The $$$ isn't there until Intel
is OEM'ing large quantities of 64-bit hardware. Linux isn't gaining
anything at all from this.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Nick Maclaren wrote:

> Using multiple hardware segments to create a software segment that
> is larger than the indexing size is, I agree, an abomination. It
> has been done many times and has never worked well.
>
> But a single flat, linear address space is almost equally ghastly,
> for different reasons. It is one of the surest ways to ensure
> mind-bogglingly revolting and insecure designs.
>
> What is actually wanted is the ability to have multiple segments,
> with application-specified properties, where each application
> segment is inherently separate and integral. That is how some
> systems (especially capability machines) have worked.
>

Thats what paging is for, and, IMHO, a vastly superior system that
gives you memory attributing while still resulting in a linear
address space.


--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Being right is more powerfull than large corporations or governments.
The right argument may not be pervasive, but the facts eventually are.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Rupert Pigott wrote:

> I think we should play the Marketoids at their own game : Let's start
> referring to IA-64 as "Legacy" now that we have a dual-sourced 64bit
> architecture in the x86 world.

It didn't get widespread enough to be a legacy.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Being right is more powerfull than large corporations or governments.
The right argument may not be pervasive, but the facts eventually are.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Nick Maclaren wrote:

> If you don't care about robustness and security, then obviously a
> single flat address space is best. But even current systems are

If you don't care about pimento stuffed olives, you obviously don't
care about world peace.

> now trying to separate the executable segments from the writable
> ones, which is moving away from a single flat address space. If
> you think about it:
>
> Why shouldn't I be able to load a module onto the stack, or use
> part of an executable as a temporary stack segment? We used to be
> able to do that, after all, and a genuinely integral flat address
> space would allow it.
>
> The reason is that it is generally accepted to be sacrificing too
> much robustness and security for flexibility.

Having segmentation return would be to me like seeing the Third
Reich make a comeback. Segmentation was a horrible, destructive
design atrocity that was inflicted on x86 users because it locked
x86 users into the architecture.

All I can do is hope the next generation does not ignore the
past to the point where the nightmare of segmentation does not
happen again.

Never again !

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Being right is more powerfull than large corporations or governments.
The right argument may not be pervasive, but the facts eventually are.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Stephen Sprunk wrote:

[SNIP]

> The distinction I've always used is that a workstation is a high-performance
> server platform that was later scaled down to single-user performance,
> whereas a desktop was designed originally with single user in mind and might
> be later scaled up to make mid-range servers (often requiring extensive
> kludges).

Seems like a better way of drawing the line.

Despite the different definition it still places Alphas in the
workstation slot and PCs in the desktop slot.

Mac IIs were schziophrenic by that definition, they could run
MacOS or A/UX.

Given the price and the spec I'd still the Mac II a workstation
because they were too pricey to find their way onto every desk
in an office. I'm making it sound like the universal truth, but
it's what I saw in practice. :/

The guys doing the heavy work (+PHB) would get a Mac II and the
rest would get something more modest like a Mac SE... At least
that is how it panned out at the few Mac sites I visited.

> I've also heard the term "workstation" applied to x86 Linux boxes, so some
> people seem to associate the term with running a real multiuser OS as
> opposed to a consumer OS, not the hardware that is in use.

I think it's a fair cop in that regard.

Cheers,
Rupert

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Scott Moore wrote:
> Rupert Pigott wrote:
>
>> I think we should play the Marketoids at their own game : Let's start
>> referring to IA-64 as "Legacy" now that we have a dual-sourced 64bit
>> architecture in the x86 world.
>
>
> It didn't get widespread enough to be a legacy.

I think it's old enough and dead enough and has had enough money thrown
at it to be called legacy though. 😉

Cheers,
Rupert

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Tony Hill <hilla_nospam_20@yahoo.ca> wrote:
> On Wed, 30 Jun 2004 14:42:01 -0600, "Judd" <IhateSpam@stopspam.com>
> wrote:
>> What is taking them so long? Answer = Intel! If 64-bit was such a
>> big deal for consumers, we would be looking at Itanium Workstations.
>> 64-bit = not big deal = why MS hasn't pushed it very hard. Wait for
>> Intel's 80+ percent market share to join in and then release
>> something for OEM's to sell their i64 and AMD64 systems. It's a
>> very smart business move.
>
> Smart business move for who?!? For Intel maybe, but how exactly does
> it help MS' cause? It's not like they're selling more by not having a
> product now and I can't see any way that it would help them long-term.
> Not releasing the product until the end of this year or early next
> year (it looks like 64-bit Windows is being delayed *again*) is only
> going to hurt Microsoft relative to Linux.

I wonder if Intel's lack of IOMMU support beyond 4GB is going to result in
device drivers having to be revalidated under 64-bit Windows? If
manufacturers were using Opteron and A64 hardware to do device driver
validation, this incompatibility by Intel might require them to redo their
drivers to take into account the Intel discrepancy. I know that MS is now
having to redo its 64-bit beta just for the EM64T, since it breaks
compatibility in this way. Hopefully, the Windows code will have to bear the
brunt of taking care of Intel's oversight, and not the device drivers.

As it turns out Intel's 64-bit doesn't even support DMA beyond 32-bit memory
address boundary.

http://www.theinquirer.net/?article=16879

Yousuf Khan

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Stephen Sprunk <stephen@sprunk.org> wrote:
> I've never run across a desktop app that needs more than 2GB of
> address space; for that matter my 512MB machine (with no VM) handles
> anything I throw at it, though I'm sure it'd be a bit faster if the
> motherboard accepted more than that.

Many news readers are running into the file size limitation when downloading
from binary newsgroups.

Yousuf Khan

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Zalman Stern <googlenews@peachfish.com> wrote:
> I suggested using Boyer-Moore-Gosper (BMG) since the search string is
> applied to a very large amount of text. A fairly straight forward BMG
> implementation (including case insensitivity) in C is ~3 times faster
> than strstr on PowerPC and SPARC for the test cases they use. On PIII
> class hardware it is faster than strstr by maybe 50%. On a P4 it is a
> little slower than strstr.

Typical story, the P4 seems to fall down anytime there is non-linear data
thrown at it.

> AMD64 is a well executed piece of practical computer architecture
> work. Much more in touch with market issues than IPF ever has been or
> ever will be.

Even without the extra registers, AMD64 is achieving big performance gains
just with bog-standard unoptimized 386 code. Mostly due to the integrated
memory controller, I would gather, but also possibly due slightly to the
Hypertransport i/o.

Yousuf Khan

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Stephen Sprunk <stephen@sprunk.org> wrote:
> There was a year or so when an Alpha running x86 binaries on FX!32 did
> indeed outpace the fastest x86 machines available, though by less
> than a 50% margin. I believe it was right before the P6 core came
> out.

As far as I recall, FX32 came out a long time after the P6 core introduced.
P6's first generation, PPro, was already obsolete, and they were already
into the second generation, PII. PPro was introduced in late 1995. I don't
think FX32 came out till sometime in 1997.

I'm sure FX32 could smoke an x86 core a couple of generations old, but it
never came close to any of the modern x86 cores it was competing against at
the time.

Yousuf Khan

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Some ancient software (Premiere v4 IIRC) could happily write AVI files
beyound 2 GB, but such files were unusable.

Now, ODML AVI files are virtually unlimited in size.

There is no need to memmap a file to work on it. And it actually may be
slower than using explicit read.

"Rupert Pigott" <roo@try-removing-this.darkboong.demon.co.uk> wrote in
message news:1088677506.849776@teapot.planet.gong...
> RusH wrote:
> > Tony Hill <hilla_nospam_20@yahoo.ca> wrote :
> >
> >
> >>>thats FAT limitations
> >>
> >>Not this time (though it could be in other situations). FAT32 has
> >>a limit on file sizes of 4GB (unsigned 32-bit int)
> >
> >
> > ha, i was thinking about disk and thats where this FAT idea came, but
> > now I remember, its AVI file format limitation 2GB no more, there is
> > a new wersion of this format now supporting larger files
>
> AVI was his *output* format, not the *input* format. What's more he had
> verified that the input files were OK. I think he had the same idea that
> perhaps they were junk after the 2GB mark.
>
> Cheers,
> Rupert
>

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <2x0Fc.9424$XM6.996@attbi_s53>,
Scott Moore <samiam@moorecad.com> writes:
|>
|> > What is actually wanted is the ability to have multiple segments,
|> > with application-specified properties, where each application
|> > segment is inherently separate and integral. That is how some
|> > systems (especially capability machines) have worked.
|>
|> Thats what paging is for, and, IMHO, a vastly superior system that
|> gives you memory attributing while still resulting in a linear
|> address space.
|>
|> Having segmentation return would be to me like seeing the Third
|> Reich make a comeback. Segmentation was a horrible, destructive
|> design atrocity that was inflicted on x86 users because it locked
|> x86 users into the architecture.
|>
|> All I can do is hope the next generation does not ignore the
|> past to the point where the nightmare of segmentation does not
|> happen again.
|>
|> Never again !

I suggest that you read my postings before responding. It is very
clear that you do not understand the issues. I suggest that you
read up about capability machines before continuing.

You even missed my point about the read-only and no-execute bits,
which are in common use today. Modern address spaces ARE segmented,
but only slightly.


Regards,
Nick Maclaren.

 

[zak]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Yousuf Khan wrote:

> I wonder if Intel's lack of IOMMU support beyond 4GB is going to result in
> device drivers having to be revalidated under 64-bit Windows? If
> manufacturers were using Opteron and A64 hardware to do device driver
> validation, this incompatibility by Intel might require them to redo their
> drivers to take into account the Intel discrepancy.

It seems the IOMMU is broken for Linux on some chipsets. If it is broken
hard on those, 64 bit windows should know how to work around that already.

> I know that MS is now
> having to redo its 64-bit beta just for the EM64T, since it breaks
> compatibility in this way. Hopefully, the Windows code will have to bear the
> brunt of taking care of Intel's oversight, and not the device drivers.

Probably also quite some assumptions in that code (no support for
certain support chips for example).

> As it turns out Intel's 64-bit doesn't even support DMA beyond 32-bit memory
> address boundary.

That would be very strange as it is supported (using 64 bit PCI
addressing) on older Xeons. But stranger things have happened... hmm...
switch CPU to 32 bit mode, do your 64 bit DMA, then switch back? Hehe...


Thomas

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Zalman Stern wrote:

> Terje Mathisen <terje.mathisen@hda.hydro.com> wrote in message
>
>>Rather the opposite: The extra GPRs is a relatively small improvement,
>>but as you said, it made a lot of sense to do it at the same time.
>
> I recently helped a friend with perfomance optimization of some string
> searching code. They were using strstr, which was acceptably fast, but
> needed a case insensitive version and the case insensitive versions of
> strstr were much slower. The platform where this was discovered was
> Win32 using VC++ libraries, but Linux, Solaris, AIX, HP-UX, etc. are
> also targets for the product.
>
> I suggested using Boyer-Moore-Gosper (BMG) since the search string is
> applied to a very large amount of text. A fairly straight forward BMG
> implementation (including case insensitivity) in C is ~3 times faster
> than strstr on PowerPC and SPARC for the test cases they use. On PIII
> class hardware it is faster than strstr by maybe 50%. On a P4 it is a
> little slower than strstr.
>
> The Microsoft strstr is a tight hand coded implementation of a fairly
> simple algorithm: fast loop to find the first character, quick test
> for the second character jumping to strcmp if success, back to first
> loop if failure.
>
> The BMG code had ridiculous average stride. Like 17 characters for
> this test corpus. But the inner loop did not fit in an x86 register
> file. (It looked like I might be able to make it fit if I hand coded
> it and used the 8-bit half registers, and took over BP and SP, etc.
> But it wasn't obvious it could be done and at that point, they were
> happy enough with the speedup it did give so...)

OK, this is fun!

I wrote an 8-bit, case-insensitive, BM search many years ago, and I
found it relatively easy to make it fit in 6-7 regs, even in the 16-bit
days.

Let's see... darn, I've lost the source code. :-(

It was something like this (with 486 timings):

; SI -> source string
; DI -> Search record, containing among other things the
; Skip distance and case conversion lookup tables, as well
; as a (possibly) monocased target string

next4:
mov bl,[si] ; 1 Load next char to test
mov bl,[di+bx] ; 1+1(AGI) Convert to skip distance
add si,bx ; 1 Increment source ptr

mov bl,[si] ; 2 Load next char to test
mov bl,[di+bx] ; 1+1(AGI) Convert to skip distance
add si,bx ; 1 Increment source ptr

mov bl,[si] ; 2 Load next char to test
mov bl,[di+bx] ; 1+1(AGI) Convert to skip distance
add si,bx ; 1 Increment source ptr

mov bl,[si] ; 2 Load next char to test
mov bl,[di+bx] ; 1+1(AGI) Convert to skip distance
add si,bx ; 1 Increment source ptr

test bx,bx ; 1 Did we get a match?
jnz next4 ; 3 No, so try again

; Check for
; Possible match, check remaining chars...

At this point I did have to spill/fill one register, it might have been
faster to do an other explicit test against the second-to-last target
character first.

Something like 10 years ago I figured out how to make it work for
case-insensitive 16-bit strings. There are two key ideas to make this work:

1) Use a _very_ simple hash table for the skip distance lookup, i.e. XOR
the top 6 bits into the lower 10, and use the resulting 0..1023 value as
an index into the skip table. For each location in that table, there
will be 64 collisions. Record the shortest possible skip distance for
any of these. This is normally still very close to the maximum skip
distance!

2) During setup, generate two versions of the target string, one
lowercased and the other uppercased. During a check for a possible match
you should, for each iteration of the match verification loop, test
against both versions of the string.

This avoids a possibly _very_ expensive 16-bit toupper() call for each
char loaded!

> It turns out that the P4 core can run the first character search loop
> very fast. (I recall two characters per cycle, but I could be
> misremembering. It was definitely 1/cycle.) The BMG code, despite

1/cycle? Hmmm!

With one char/iteration, that's impossible:

next:
mov al,[esi] ; 1
inc esi ; 1
cmp al,bl ; 2
jne next ; 2

Unrolling makes it better:

next4:
movzx eax,word ptr [esi] ; Load 16 bits
cmp bl,al
je first_match
cmp bl,ah
je second_match
movzx eax,word ptr [esi+2] ; Load next 16 bits
add esi,4
cmp bl,al
je third_match
cmp bl,ah
jne next4
fourth_match:

Even better would be to load 32 bits and check all four characters at
the same time:

next4:
mov eax,[esi]
add esi,4
cmp bl,al
je first_match
cmp bl,ah
je second_match
shr eax,16
cmp bl,al
je third_match
cmp bl,ah
jne next4
fourth_match:

A case-insensitve version of the same kind of loop could also be written:

next:
mov al,[esi]
inc esi
cmp al,bl ; tolower(first_char)
je match
cmp al,bh ; toupper(first_char)
jne next
match:
mov al,[esi]
cmp al,dl ; tolower(second_char)
je match_pair
cmp al,dh
jne next
match_pair:

I have a feeling that a regular, case-sensitive, strstr() could work
quite well on x86 by using/abusing the ability to do misaligned loads
quite fast. I.e. only when straddling cache lines do you get a real penalty:

next4:
cmp ebx,[esi]
je match4_0
cmp ebx,[esi+1]
je match4_1
cmp ebx,[esi+2]
je match4_2
cmp ebx,[esi+3]
add esi,4
jne next4

match4_3:
sub esi,3
match4_2:
inc esi
match4_1:
inc esi
match4_0:
; ESI -> place where the first four characters all match,
; check the rest!

> theoretically doing a lot less work, stalls a a bunch. A good part of
> this is that it has a lot of memory accesses that are dependent on
> loads of values being kept in memory because there are not enough
> registers. 16 registers is enough to hold the whole thing. (I plan on
> redoing the performance comparison on AMD64 soon.)

The inner loop will always fit in registers, but the data-dependent skip
distances means that all the loads suffer AGI stalls.
>
> The point is this: having "enough" registers provides a certain
> robustness to an architecture. It allows register based calling
> conventions and avoids a certain amount of "strange" inversions in the
> performance of algorithms. (Where the constant factors are way out of
> whack compared to other systems.) As a practical day to day matter, it
> makes working with the architecture easier. (Low-level debugging is
> easier when items are in registers as well.)
>
> I expect there are power savings to be had avoiding spill/fill
> traffic, but I'll leave that to someone with more knowledge of the
> hardware issues.
>
> AMD64 is a well executed piece of practical computer architecture
> work. Much more in touch with market issues than IPF ever has been or
> ever will be.

That is something we can agree on!

(Or as I told our Dell representative this spring, by coincidence the
day before Intel caved in and announced their x86-64 version: "Dell has
to deliver 64-bit x86 product within six months or so, or you'll be
history.")

A C(++) version of the 16-bit (possibly) case-insensitive BM:

do {
do {
c = [src];
c = hash(c); // #define hash(c) (c & 1023)
skip = skiptable[c];
src += skip;
} while (skip);

// Assume we placed a sentinel at the end!
if (src >= source_end) return NULL;

// Since the skip table test can have false positives, we
// must check the entire string here!

s = src;
l = target_len;
tu = target_upper_end;
tl = target_lower_end;
do {
c = [s--];
if (c != *tu) && (c != *tl) break;
tu--; tl--;
} while (--l);
if (! l) return (s+1);

src++;
} while (src < source_end);

When doing a case-sensitive search, you simply allocate a single buffer
for the target string, and set both tu and tl to point to the last
character in it.

Terje

PS. When the buffer to be searched can be shared or read-only, then it
is faster to make two versions of the code above, with the first using
an unrolled inner loop that checks that it stays within (UNROLL_FACTOR *
MAX_STRIDE) of the end, and the second version doing an explicit check
on each iteration.

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:wm5Fc.667735$Ar.584754@twister01.bloor.is.net.cable.rogers.com...
> Stephen Sprunk <stephen@sprunk.org> wrote:
> > I've never run across a desktop app that needs more than 2GB of
> > address space; for that matter my 512MB machine (with no VM) handles
> > anything I throw at it, though I'm sure it'd be a bit faster if the
> > motherboard accepted more than that.
>
> Many news readers are running into the file size limitation when
downloading
> from binary newsgroups.
>
> Yousuf Khan

File sizes and physical or virtual addressability are not related. Its a
rare app that *needs* to have a whole file mapped into the adress space, and
if it does then the app isn't intended to handle large files (i.e. more than
tens of megs). It would be folly for a video-stream editor to have to fit
the file into memory.

Peter

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Peter Dickerson" <first{dot}surname@ukonline.co.uk> wrote in message
news:w1cFc.9$lP1.7@newsfe5-gui.ntli.net...
> File sizes and physical or virtual addressability are not related. Its a
> rare app that *needs* to have a whole file mapped into the adress space,
and
> if it does then the app isn't intended to handle large files (i.e. more
than
> tens of megs). It would be folly for a video-stream editor to have to fit
> the file into memory.
>
> Peter
>
>

You may very well need to if you're doing a combine and decode in a news
reader. Not sure how specific news readers do this but I could see OE for
example keeping the entire file in memory until it's fully decoded.

Carlo

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <ltGdnS2Bb5h303jdRVn2gA@giganews.com>,
"Carlo Razzeto" <crazzeto@hotmail.com> writes:
|> "Peter Dickerson" <first{dot}surname@ukonline.co.uk> wrote in message
|> news:w1cFc.9$lP1.7@newsfe5-gui.ntli.net...
|>
|> > File sizes and physical or virtual addressability are not related. Its a
|> > rare app that *needs* to have a whole file mapped into the adress space,
|> and
|> > if it does then the app isn't intended to handle large files (i.e. more
|> than
|> > tens of megs). It would be folly for a video-stream editor to have to fit
|> > the file into memory.
|>
|> You may very well need to if you're doing a combine and decode in a news
|> reader. Not sure how specific news readers do this but I could see OE for
|> example keeping the entire file in memory until it's fully decoded.

Only if the protocol or application are seriously misdesigned.
Competently designed streaming systems need very little memory.
And video is an inherently streaming data type!

This is precisely where PAE scores, because the file can be kept
in fast memory, and the application just slides a window over it.
So a 'read' is merely a question of fiddling the page tables.
Clean, simple and fast.


Regards,
Nick Maclaren.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In <1088710894.403058@teapot.planet.gong> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> writes:

>Here's a list of comments I received in response to suggesting using
>Linux :
>
> "It's too expensive !"
> "It's unsupported !"
> "There's no hardware support !"
> "People don't understand it !"
> "Customers won't like it !" (Customers wanted gear that worked
> appliance style 24x7, no UI)

Seem most of them myself, when budget cuts forced the migration from
RISC systems to Intel PCs. OTOH, the users soon realized that they
can't get their work done on NT and started asking for Linux, loud
enough that the suits had to comply.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In <1088713322.651904@teapot.planet.gong> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> writes:

>I never heard of anyone referring to an Apollo or a Sun as a
>Desktop, always a Workstation.

At my previous job, all workstations with a single user, sitting on or
near his desk, were called desktops, just as the PCs and Macs. The ones
in the machine room were called servers, even if they were identical with
those in the first category. The definition was based on how the machine
was used and not on some political/religious issues.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In <1088723509.399206@teapot.planet.gong> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> writes:

>Scott Moore wrote:
>> Rupert Pigott wrote:
>>
>>> I think we should play the Marketoids at their own game : Let's start
>>> referring to IA-64 as "Legacy" now that we have a dual-sourced 64bit
>>> architecture in the x86 world.
>>
>> It didn't get widespread enough to be a legacy.
>
>I think it's old enough and dead enough and has had enough money thrown
>at it to be called legacy though. 😉

The usual definition of "legacy", in context, is: "obsolete, but we have
nothing to replace it with".

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Zak <jute@zak.invalid> wrote:
>> As it turns out Intel's 64-bit doesn't even support DMA beyond
>> 32-bit memory address boundary.
>
> That would be very strange as it is supported (using 64 bit PCI
> addressing) on older Xeons. But stranger things have happened...
> hmm... switch CPU to 32 bit mode, do your 64 bit DMA, then switch
> back? Hehe...

I don't think it would need to be switched to 32-bit just to do DMA, more
likely, they will prevent the devices from writing beyond the 4GB barrier.
And if they need to write beyond that barrier, then the OS would have to
take care of repaging the lower 4GB into the upper addresses.

Yousuf Khan

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Peter Dickerson <first{dot}surname@ukonline.co.uk> wrote:
> File sizes and physical or virtual addressability are not related.
> Its a rare app that *needs* to have a whole file mapped into the
> adress space, and if it does then the app isn't intended to handle
> large files (i.e. more than tens of megs). It would be folly for a
> video-stream editor to have to fit the file into memory.

They probably did it to get higher performance access to their database
files, but likely they were never envisioning that these databases would get
that large.

Yousuf Khan

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Carlo Razzeto" <crazzeto@hotmail.com> wrote in message
news:ltGdnS2Bb5h303jdRVn2gA@giganews.com...
> "Peter Dickerson" <first{dot}surname@ukonline.co.uk> wrote in message
> news:w1cFc.9$lP1.7@newsfe5-gui.ntli.net...
> > File sizes and physical or virtual addressability are not related. Its a
> > rare app that *needs* to have a whole file mapped into the adress space,
> and
> > if it does then the app isn't intended to handle large files (i.e. more
> than
> > tens of megs). It would be folly for a video-stream editor to have to
fit
> > the file into memory.
> >
> > Peter
> >
> >
>
> You may very well need to if you're doing a combine and decode in a news
> reader. Not sure how specific news readers do this but I could see OE for
> example keeping the entire file in memory until it's fully decoded.
>
> Carlo

Indeed MS might do that but it certainly isn't necessary or particularly
sensible. MS Win NT was designed with 64-bit file sizes in mind so I doubt
they would then restrict such apps to creating 32-bit sized files.

Peter

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch Yousuf Khan <bbbl67@ezrs.com> wrote:
> Stephen Sprunk <stephen@sprunk.org> wrote:
> > I've never run across a desktop app that needs more than 2GB of
> > address space; for that matter my 512MB machine (with no VM) handles
> > anything I throw at it, though I'm sure it'd be a bit faster if the
> > motherboard accepted more than that.
>
> Many news readers are running into the file size limitation when downloading
> from binary newsgroups.

What does file size have to do with 32 vs 64bit? The OS I run on my desktop
has been supporting file sizes in excess of 4GB since at least 1994 when I
switched to it, *including* on plain vanilla x86 hardware.

>
> Yousuf Khan
>
>

--
Sander

+++ Out of cheese error +++

 

[cjt]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Carlo Razzeto wrote:

> "Peter Dickerson" <first{dot}surname@ukonline.co.uk> wrote in message
> news:w1cFc.9$lP1.7@newsfe5-gui.ntli.net...
>
>>File sizes and physical or virtual addressability are not related. Its a
>>rare app that *needs* to have a whole file mapped into the adress space,
>
> and
>
>>if it does then the app isn't intended to handle large files (i.e. more
>
> than
>
>>tens of megs). It would be folly for a video-stream editor to have to fit
>>the file into memory.
>>
>>Peter
>>
>>
>
>
> You may very well need to if you're doing a combine and decode in a news
> reader. Not sure how specific news readers do this but I could see OE for
> example keeping the entire file in memory until it's fully decoded.
>
> Carlo
>
>
Define "need to." Is your definition specific to OE?

--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.