CIPWTTKT&GC v0X12 (v18): Makol can't Computer Very Good - Hardware & Software

[QUOTE=SataniX;35371141]"only"[/QUOTE] By "only" I meant next month/very soon. [editline]31st March 2012[/editline] [QUOTE=Allstone;35371361]Of those the 670 and 675 are rebranded Fermis though, and the stuff below the 640 is mostly just die-shrinked Fermi. [editline]1st April 2012[/editline] And yeah, the Acer timeline has the 640M with much slower DDR3 memory than Nvidia's specs.[/QUOTE] No. The 630M and below are rebranded from what I understood. Making the two high end mobile gpus rebranded cards would be retarded since the 640, 650, and 660 are all Kepler.

My friend just used a Etherkiller on a Raspberry PI................

[QUOTE=gman003-main;35370881]You're still wrong, by the way. EPIC, and even VLIW in general, doesn't work anymore. You save die space by putting the parallelism logic in the compiler instead of the hardware, but then you use up all that space, and more, trying to have enough cache for 64-bit instructions (even in 64-bit mode, x86 uses 32-bit instructions). Much of which is taken up by NOPs, because compilers simply can't know enough about hardware state like "is this address in cache, or main memory?". Now, EPIC *would* have worked quite well, long ago. Before massive caches, and before processor clocks greatly outstripped memory clocks. Maybe it'll even come back, if TTRAM or something takes off and main memory latencies drop to the point that cache is pointless. But for the present and predictable future, EPIC is fail.[/QUOTE] Itanium instructions aren't 64-bit, they're 41-bit. (three 41-bit instructions + 5 bits of flags in a 128-bit instruction word = a bundle.) The code is moderately compact, but x86 wins the code-compactness war at the cost of decoder complexity (yay variable-length CISC!) which means we probably aren't seeing a 6-issue x86 design any time soon. If you compare Power/SPARC/SX/whatever to x86 code compactness, they lose too. I'm also not sure what you mean by "x86 uses 32-bit instructions" - x86 is a variable-length CISC instruction set, with a wide range of instruction lengths (anything that uses 32-bit immediates is going to take up at least 40 bits, for instance.) This is the downside of not going the load-store route. If your workload is Itanium-friendly, you can avoid NOPs almost entirely. Itanium's cache hierarchy is a little weird (L1 d-cache is integer-only, L2 is fp-only) but it's also fairly intelligent, and the binary usually contains load-hints added by the compiler to make the prefetcher more effective. Current-gen microarchitectures [I]do[/I] have a problem that an L1 miss causes a stall; historically, Intel's tried to fix this by implementing switch-on-miss multithreading, which helped a bit. The new microarch (Poulson) solves the problem entirely by using 12-wide instruction issue, continuing to issue instructions until a dependency is found, and re-issuing the instructions in question when the data becomes available. That was the I2's biggest problem, and it's nice to see it go away.

I gave some suggestions to LeaseWeb about improvements to their Control Panel and in return, [url=https://twitter.com/#!/LeaseWeb/status/185390631265370113]they are sending me a thank you gift[/url] (USB Stick, Other LW Merch, etc). Unfortunately its being sent over from the US. Oh and they are doing the "bring hot girls to booth stands at events" thing ([url=https://p.twimg.com/ApUwZ_ECIAAaw1b.jpg:large]Picture[/url]).

Has Newegg always had the option for monthly payments on purchases? What the hell where have I been

[QUOTE=Dorkslayz;35372112]I gave some suggestions to LeaseWeb about improvements to their Control Panel and in return, [url=https://twitter.com/#!/LeaseWeb/status/185390631265370113]they are sending me a thank you gift[/url] (USB Stick, Other LW Merch, etc). Unfortunately its being sent over from the US. Oh and they are doing the "bring hot girls to booth stands at events" thing ([url=https://p.twimg.com/ApUwZ_ECIAAaw1b.jpg:large]Picture[/url]).[/QUOTE] They arn't *that* hot.

[QUOTE=Makol;35371974]By "only" I meant next month/very soon. [editline]31st March 2012[/editline] No. The 630M and below are rebranded from what I understood. Making the two high end mobile gpus rebranded cards would be retarded since the 640, 650, and 660 are all Kepler.[/QUOTE]The 670M and 675M are rebrands of the 570M and 580M, respectively, leaving a space in the numbering system for a cut down desktop GPU as the 680M. To quote VR-Zone: [url=http://vr-zone.com/articles/nvidia-reveals-geforce-600m-line-up-alongside-the-gtx-680/15327.html]"This brings us to the GTX 670M and GTX 675M which are simply re-branded Fermi chips that used to be known as the GTX 570M and GTX 580M"[/url] [editline]1st April 2012[/editline] If you like I can get one of the release previews that actually has the chip numbers specifically showing that the 670M and 675M are Fermi. [editline]1st April 2012[/editline] AnandTech: [url=http://www.anandtech.com/show/5697/nvidias-geforce-600m-series-keplers-and-fermis-and-die-shrinks-oh-my/2]"GeForce GTX 675M: 40nm GF114 [...] GeForce GTX 670M: 40nm GF114"[/url].

[QUOTE=Wooops: 404;35372151]They arn't *that* hot.[/QUOTE] They are the only girls which will wear those LW Outfits.

yay. time to have a casual conversation with one of ea's trained support technicians. [editline]31st March 2012[/editline] I can now say I've talked with a man named kumar. my life is complete

Does anyone have a recommendation for a very low profile CPU cooler. We're talking like 100mm [i]max[/i], and then it's virtually hitting the case. I get some fairly horrible temps, and it's pretty much the stock cooler's fault (not that I've been good at removing dust, and that seems like the big sinner), as the temps in the case are fairly good everything considered (28-30 under load).

[QUOTE=altern;35372263]yay. time to have a casual conversation with one of ea's trained support technicians. [editline]31st March 2012[/editline] I can now say I've talked with a man named kumar. my life is complete[/QUOTE] "Trained" [editline]31st March 2012[/editline] Also [IMG]http://dl.dropbox.com/u/26604285/Dafuck.jpg[/IMG] O_o

[QUOTE=Keyrah;35372019]Itanium instructions aren't 64-bit, they're 41-bit. (three 41-bit instructions + 5 bits of flags in a 128-bit instruction word = a bundle.) The code is moderately compact, but x86 wins the code-compactness war at the cost of decoder complexity (yay variable-length CISC!) which means we probably aren't seeing a 6-issue x86 design any time soon. If you compare Power/SPARC/SX/whatever to x86 code compactness, they lose too. If your workload is Itanium-friendly, you can avoid NOPs almost entirely. Itanium's cache hierarchy is a little weird (L1 d-cache is integer-only, L2 is fp-only) but it's also fairly intelligent, and the binary usually contains load-hints added by the compiler to make the prefetcher more effective. Current-gen microarchitectures [I]do[/I] have a problem that an L1 miss causes a stall; historically, Intel's tried to fix this by implementing switch-on-miss multithreading, which helped a bit. The new microarch (Poulson) solves the problem entirely by using 12-wide instruction issue, continuing to issue instructions until a dependency is found, and re-issuing the instructions in question when the data becomes available. That was the I2's biggest problem, and it's nice to see it go away.[/QUOTE] OK, 41-bit instructions. Still bigger than 32. And still with extra wasted space for NOP and load-hints. And yes, x86 has some horrible implementation details, but it *works*. And it works well - it runs well in the $40 to $1200 price range, the 6W-120W power range, and the 1-8 socket range. It has *proven* itself on the desktop, the laptop, and the small server. The remaining high-end servers are dying out in favor of x86 clusters. The ultra-low-power, now a haven for ARM, is *also* getting attacked by x86 as they compete for higher performance.

[QUOTE=gman003-main;35372626]OK, 41-bit instructions. Still bigger than 32. And still with extra wasted space for NOP and load-hints. And yes, x86 has some horrible implementation details, but it *works*. And it works well - it runs well in the $40 to $1200 price range, the 6W-120W power range, and the 1-8 socket range. It has *proven* itself on the desktop, the laptop, and the small server. The remaining high-end servers are dying out in favor of x86 clusters. The ultra-low-power, now a haven for ARM, is *also* getting attacked by x86 as they compete for higher performance.[/QUOTE] x86 instructions aren't fixed-length at 32-bit, and ones that can take immediates can be way, way more. 8-socket x86 is a joke (no directory cache) and the high-end server market isn't going away. It's awfully hard to compete with 32 sockets of cache-coherent shared memory with a cluster.

In other non-nerd competition news, my mom fixed my XB-500's for me. [t]https://fbcdn-sphotos-a.akamaihd.net/hphotos-ak-prn1/524240_10150689439950502_804800501_9175938_1293083351_n.jpg[/t]

altern might be gone for a while. He said on steam that his Mom is taking away his computer because his GPA is 85..................

[QUOTE=GoDong-DK;35372541]Does anyone have a recommendation for a very low profile CPU cooler. We're talking like 100mm [i]max[/i], and then it's virtually hitting the case. I get some fairly horrible temps, and it's pretty much the stock cooler's fault (not that I've been good at removing dust, and that seems like the big sinner), as the temps in the case are fairly good everything considered (28-30 under load).[/QUOTE]I've heard good things about the Scythe Big Shuriken (2) and Noctua L-12.

gman is being out gmanned.

[QUOTE=Wooops: 404;35372781]altern might be gone for a while. He said on steam that his Mom is taking away his computer because his GPA is 85..................[/QUOTE] .85 or 85 as in he has an average of a 'b' in all his classes? because if it's the latter then what the fuck

Apparently its the average, if that helps.

[QUOTE=SataniX;35372824]gman is being out gmanned.[/QUOTE] I guess you could say He got beaten at his own game. YEEEEEEEEEEEEEEEEEAAAAAAAAAAAHHHHHHHH!!!!!!!!!!!!!!!!!!!!!

[img]http://i.imgur.com/08BUv.png[/img] Umm....

[QUOTE=Keyrah;35372698]x86 instructions aren't fixed-length at 32-bit, and ones that can take immediates can be way, way more. 8-socket x86 is a joke (no directory cache) and the high-end server market isn't going away. It's awfully hard to compete with 32 sockets of cache-coherent shared memory with a cluster.[/QUOTE] 1) Instructions taking immediates are longer mainly because there's data being stored in the "instruction". Since it would otherwise be stored in data cache, there's not really a problem. 2) Correct me if I'm wrong, but doesn't the translation lookaside buffer on x86 SMP processors give most of the benefits of a directory cache anyways?

[QUOTE=gman003-main;35373084]1) Instructions taking immediates are longer mainly because there's data being stored in the "instruction". Since it would otherwise be stored in data cache, there's not really a problem. 2) Correct me if I'm wrong, but doesn't the translation lookaside buffer on x86 SMP processors give most of the benefits of a directory cache anyways?[/QUOTE] What about multiple operand-instructions? Those can also go past 32-bit, afaik. You're also blowing the importance of the code-density thing way out of proportion - x86 has a small advantage in code density but completely loses at cache performance, inter-socket I/O performance, issue width... The TLB is nothing like a directory cache. The whole point of a directory cache is to prevent the need to broadcast in order to do cache coherency - a process that is slow on 4-socket and painful on 8-socket. Directory-based cache coherence keeps a list of cache lines and which CPU has them. There's been some suggestion that Ivy-EX is going to have a directory cache, but it hasn't happened yet.

[QUOTE=Keyrah;35373122]What about multiple operand-instructions? Those can also go past 32-bit, afaik. You're also blowing the importance of the code-density thing way out of proportion - x86 has a small advantage in code density but completely loses at cache performance, inter-socket I/O performance, issue width... The TLB is nothing like a directory cache. The whole point of a directory cache is to prevent the need to broadcast in order to do cache coherency - a process that is slow on 4-socket and painful on 8-socket. Directory-based cache coherence keeps a list of cache lines and which CPU has them. There's been some suggestion that Ivy-EX is going to have a directory cache, but it hasn't happened yet.[/QUOTE] Look, I'm not arguing that Itanium, or at least a processor with Itanium-like features, is completely useless in the high-end server market. Most of the use cases can be handled by several x86 processors, mind you, but it does have a place. At least until x86 starts copying those features. Remember when people were saying "x86 will never have good FP performance", then "x86 will never compete with 64-bit addresses", then "x86 can't virtualize", and so on. I was *trying* to argue with Wings' saying he wants an Itanium smartphone and shit. And I'm pretty sure nobody needs a 32-socket phone yet.

Fight Fight Fight

[QUOTE=BreenIsALie;35373506]Fight Fight Fight[/QUOTE] No, we're done fighting.

I want a 32 socket phone

One of my fans is cracking. I dislike that.. It seems to be my GPU fan. I dislike that. To get that fixed, I should get a new GPU (Or a cooler) but I have no need for a new GPU and even if I get a new one, it would be bottlenecked to hell and back. The temps seem to be fine and the fan runs well enough. That is a good thing.

Finally got around to fixing my desktops BIOS resetting every time i turn it off awh yeee

[QUOTE=Wooops: 404;35370283]How would I get a shortcut to go from where it is and not a drive letter. I'm putting a few things onto my pendrive but on all 3 of the computers I'm using it on, it shows up as a different drive letters. Any ideas?[/QUOTE] Anyone?