Lets talk Amd Vs Intel platform longevity

UnaSalusVictus

  • Bibliophile, Autodidact
  • Administrator
  • Posts: 4,646
Re: Lets talk Amd Vs Intel platform longevity
« Reply #90, on January 13th, 2009, 02:51 AM »
my buddy has the quad pipe opeteron cooler from way back and still uses it for his main amd rig, cost him 15bucks on ebay to get just the cooler, those where nice, even the 2 pipe version was decent, most stock coolers are SHIT for clockers tho.

Zek, i would say thats a fallicy, or just dosnt matter(10c=1/2 life) I have seen athlon xp rigs that run close to 60c constantly yet they been going for years, about to outlive their usefull lives under normal use( windows is about to out pace them)

Same deal with p4/d chips, seen them run for years at temps amd chips cant ever get to because they error b4 they get to them!!!

now nvidia gpu's g84/g86/g92 i wouldnt want to let them get hot alot, they got a flaw in the prosess used to make them(to much lead in the binder) so they die easyer from heat cycling(helps explain the fail rate on alot of companys 8800gt's!!!) 
"It's funny that Christians want people to believe Muslims are evil due to what's in their holy book, their history, and the actions of their extremists, while telling people to ignore what's in their own holy book, their history, and the actions of their extremists."
http://www.pirate-party.us
“Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.”

Carlosbailey

  • Newbie
  • I'm new, be nice.
  • Posts: 1
Re: Lets talk Amd Vs Intel platform longevity
« Reply #91, on December 8th, 2012, 12:26 PM »Last edited on December 9th, 2012, 10:24 AM by Carlosbailey
Quote from APK on December 8th, 2008, 02:27 PM
The point is that those "types of snags" (apps that exist in 32-bit, but, do not in 64-bit (drivers too)), still exist though... that's all.

----

See? It IS important to have that stuff "ready to go" in the OS if possible, as you're stating, or from the OEM of the hardware itself (in having a 64-bit ready port for say, a driver)... when it's NOT there though??

All you have is a "box that
nice led lights up" (or, card, or printer, or etc. et al)... No "ghost-in-the-machine/deus ex machina" to make it REALLY, "go"...

----

Yes, they are THAT way, largely... but, it is a RIOT going in there to their website, especially vs. the hardcore *NIX fans, + taking their points, & tearing them apart with them...

(... &, it's fairly easy to do, MOST of the time (occasionally you run into someone that knows what they're about though)).

Linux has a few weakpoints (drivers for various hardwares like printers or all-in-one fax/printer setups, modems, & USB) that are easily brought up, as well as a lack of applications vs. Windows wealth of them.

In other words? "KNOW THY ENEMY"... lol, & better than he knows himself, if possible... it also makes YOU, stronger, & know the upsides of your chosen platform (in this case, Win32/Win64) also.

----

Which is EXACTLY WHY I used it as a point against going first, after a NEW OS release, & secondly because it only gets worse, on a new OS that is 64-bit... because, like Novocaine? It works, everytime, just give it time...

That same "hassle" also exists on hardwares (mobo RAM onboard possible limits) in transitions like this one...

I.E.-> Do hardware constraints also "live up to" the next gen of memory addressability, & fully ( clearly? they still don't... not yet, & my guess is, not for a LONG while)... the OS cache is the ONLY thing so far that really consistently & constantly MIGHT do so...

However, even there? I don't think it does, fully... even on VISTA (perhaps especially VISTA... it had problems caching already, once, & that was only a partial "FIX" in SP #1 for VISTA too, for its caching hassles).

----

Having 32-bit alternate apps is 1 thing, but also having 64-bit ones, is quite another... hence, my point (or, rather, 1 of them, in this regards).

I've been through it 2x before (8-16 bit, & then 16-32 bit)... I know the "up & down sides" of it, first hand, & 2 times now... didn't like it, the wait, for ports to the "higher platform"... it takes time.

First, for apps... & moreso usually, for drivers for various kinds of equipment.

It gets to the point where you have to pay attention to IF the OEM of a certain hardware has BOTH 32-bit AND 64-bit drivers ready in fact... it's important, @ these times (transitions between memory addressability thresholds).


Right now? We're presently NOT quite there, thus, why I stated I'd believe we're MOSTLY 64-bit out there, hardware AND OS + softwares ready, maybe this time next year.

----

Actually, I take it QUITE positively...  for "overcoming objections"...

I use their views, to tear them apart, by finding the blatant "holes" in some of their arguments in favor of various *NIX's, vs. that of Windows... again, it helps you "KNOW THY ENEMY" (first, though? You really have to "KNOW THYSELF", & the OS platform YOU ARE ON, & very well - enough so, to compare & contrast it to theirs).

----

I'd believe that, if a process was given enough RAM, onboard the mobo that is, & it may help it NOT have to begin "page faulting" (paging), because it ran out of RAM, & forces parts of itself AND other apps to page to disk & then itself perform a diskbound READ for more data to work on...

Which is why I was saying earlier "You have 'only 4gb of RAM'"... which a 32-bit OS can use, just as well as a 64-bit one can, also... you're really "holding yourself back" with only 4gb over there, & not living up to what you MIGHT be able to do in 64-bit, with a lot more RAM.

However, there IS A DOWNSIDE TO APPS WITH HUGE DATA:

The OS cache, the 1 thing that might be able to actually USE more than 4gb all the time & effectively? It too, 'flushes' when system RAM on the mobo get flooded out by a HUGE process & its data...

... Negating the values of a large system cache AND incurring a "performance hit" while it flushes as well (takes time, it's NOT 'instantaneous' but, it is faster than a normal read/write because it's RAW WRITTEN, & doesn't use the filesystem driver (pagefile.sys reads/writes)).

ONLY 1 GOOD THING RESULTS WHEN LARGE DATA ENTERS MEMORY: It defrags the memory into a contiguous available block - what apps are KNOWN to gain by this?

----

1.) EXCHANGE SERVER (has bad problems in 32-bit especially w/ memory fragmentation, it actually HALTS it)

2.) FireFox (which is WIDELY used, but, has known issues w/ memory fragmentation & bloat due to it).

----

Unfortunately though, the fact remains, that "the 64-bit spirit (OS & apps) IS WILLING, but the FLESH (hardware in mobo & RAM you can place on it) is WEAK"

The OS & apps can get to up to 16 exabytes of RAM... however the mobos out there now can only load 64gb of RAM onto them (far short of that 16 exabyte mark)...

* That all above, is WHY I would wait, & am, personally...

I.E.-. The lack of apps & drivers for 64-bit, & the fact that the OS + apps & drivers in 64-bit can use a LOT more than what present hardware designs allow for.

APK

P.S.=> Now, IF co$t$ were NOT an issue?

I'd still have to say:

----

"1.) Go for BOTH tons of RAM onboard (@ least 4gb) for caching gains potentially @ least (& setup a large cache in the OS properties for it in the SYSTEM ICON)

&

2.) Also the use of an SSD to offload the main OS & programs housing disk from pagefile.sys, %temp% ops, & logging by the OS + apps too!

Simply because it allows for less head movements, cache flushes, & less fragmentation (long term gain), effectively speeding up the SLOWEST part of your system: Mechanical HDD's"...

----

Only problems are, is that SSD usage extends to most any OS & hardware there is... using > = 4gb does not, due to not all hardware being able to take advantage of it.

AND IN CACHING TOO, here is how/why/where:

ON Windows 2000/XP/Server 2003, the cache works, like this:

----

128mb of VIRTUAL MEMORY is typically ALL that is allotted to the diskcache!

(vacb type, works @ filesystem driver level, vs. other types like SuperCache II, which works @ the diskdriver level, lower, & can even cache a pagefile.sys due to that (paging doesn't use the filesystem, & writes "RAW" direct to the file is why))

... Now, for every 4mb above 16mb, of PHYSICAL RAM?

The OS gives the cache 64mb of added VIRTUAL MEMORY, BUT caps it, @ 512mb total on x86 rigs.

Thus, there IS a limit on those older MS OS'... even in caching!

----

The problem? VISTA's cache design, of "commit all FREE ram to caching", which IS different from the way it worked on older MS' OS' above?

It's had problems!

Problems that were only partially corrected in SP#1 mind you, hopefully the recently released SP#2 does more here specifically (don't think so though)... do you TRUST IT, fully?

I don't...

I.E.-> That would STILL (even w/ cacheline size limits) be, imo, the best gateway/route to HIGHEST & MOST CONSISTENT possible performance boosts is that, right there, in a nutshell... apk
Thanks for sharing this useful information.

UnaSalusVictus

  • Bibliophile, Autodidact
  • Administrator
  • Posts: 4,646
Re: Lets talk Amd Vs Intel platform longevity
« Reply #92, on December 9th, 2012, 04:43 AM »
please dont take APK's opinion that 64bit is useless and has no perf advantages if your not using huge amounts of ram as fact, its been proven over and over that hes wrong, its also been shown that his main reason for not doing 64bit version is that delphi dosnt or last I checked still didnt have a compiler that supported 64bit, and since he really dosnt use anything but pascel...i mean delphi that holds him back.

an easy example of faster is comparing a 64bit compile of the encoder for ogg vorbis with a 32bit compile using the same source and compiler, the 64bit is ALWAYS faster, depending on the compiler it can be as much as 6x faster in large batch encodes.

APK got himself banned here as he did on many other sites, he made an ass of himself and attacked us, spammed the forums and generally made a huge ass of himself over stuff that didnt matter(a joke that we mods use to play on eachother all the time changing eachothers titles to funny things....something he could have changed back himself....)
"It's funny that Christians want people to believe Muslims are evil due to what's in their holy book, their history, and the actions of their extremists, while telling people to ignore what's in their own holy book, their history, and the actions of their extremists."
http://www.pirate-party.us
“Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.”