Comment Re:X32 (Score 1) 95
Show me one 20 year old x86 CPU, capable of executing 64-bit code.
And then please explain why would someone with such configuration even go with glibc when there are other, much slimmer choices.
Show me one 20 year old x86 CPU, capable of executing 64-bit code.
And then please explain why would someone with such configuration even go with glibc when there are other, much slimmer choices.
So you will go with small, cheap and economic ARM instead of x86.
Why go for x86 and then worry about a couple bytes of _code_ ?
One can be lover of sport cars and byu a Ferrari. Or one could be a prudent driver and go for Diesel car.
But having Diesel Ferrari doesn't make you prudent performance driver, it makes you a moron.
So, it was meant for the case where you'd go with X86_64, but with anorexic memory ?
Who is so moronic to do that ?
Well, I don't like Bulldozer, at least not as it is now.
It doesn't make much sense as it is nether here not there. They are trying to sell one modules as two cores, which is ridiculous. Also, it is not clear why in real life one module ( ie by making it execute just one thred with all its resources) can't match performance of one decent core on clock-by-clock basis.
Also, AMD managed to squeeze 6 K-10 cores on 346 mm2 with 45nm geometry on Thuban ( x6 1055,1075,1090,1100T), With 32nm they should be able to use 2x logic on same area. If one module costs them only 18% more die area as the classical core from previous generation, then they should be able to put something like 8-10 MODULES ( and not only 4) on a chip, done with 32nm on 315mm2 like FX-8150. If they went for 350mm2 like before, then even 12 modules, perhaps with a bit less L3 wouldn't be out of the question ( 12 modules = 24 threads ! ).
Users would then get poor man's Magnycores. It would be awesome. And people would understand even if unithread performace sucked - it would be manythreading monster. Even better, they could offer higher clocked versions with just two or 4 modules for those kind of customers. Or even refer them to existing Thubans.
As it is now, it looks as if someone panicked in the late stage of the design and tried to save it by bundling it with shitload of L2 and L3 cache.
Affordable. Something like Tyan's dual socket Opteron boards. â300-400.
I second that.
I'm from penguin crowd, but nevertheless it would be really nice to work on some decent, many-cores non-x86-crap design...
Ideally, on dual socket board...
True. Where are all those promised cores ?
Bulldozer was supposed to be about doing things parrallel big time.
All they have shown are four fat cores they call modules, and they paid for each only 18% more transistors than for regular core.
If that is true and if they have 2x bigger transistor budget, shouldn't we be seeing chips with something like 12 modules ?
You are naive.
CIA had its hands all over Balkan all the time(amongst others) And all that time, there were wery little visible agents that one could point on.
They used various sorts of puppets instead. So, if they're involved in this, those two girls are just getting paid in one way or another and doesn't particularly care or know who is paying them.
After all, why would you need specially trained agent to scream "RAPE!" ?
Can you give an example ?
I tried Open64 with bzip2 and result was about the same execution speed as with gcc-4.3
I use this with all my Epsons and it works beautifully and by far the cheapest.
Refilling the cartridge takes me maybe 2 mins all in all.
It's nice to have thin latex gloves if a drop of ink spills, it's kinda hard to wash out from hands and fabric, but that's a minor bump...
I wish Slashdotters would stop with the incessant "x86 sucks" mantra. You're all fools.
There's plenty of crufty old instructions in the x86 ISA; no modern compilers generate them though, so no one cares that they're there. They take up a couple pages in the ISA manual I guess. The die area it takes to implement them is totally, completely insignificant.
Take a look at what it takes to decode x86 instruction in parallel and then we'll talk.
2.95 is/was regarded as a "golden" version for its maturity and stability.
I'm not certain that newest 4.3x is that much better on small embedded system without SSE and FPU units to be worth a swap...
No, UV LEDs are far too costly, fragile and unpolished for this.
Remember how BlueRay still has so many problems because they can not produce UV LEDs to sufficient quantities ?
In fact, many white LEDs use BLUE LED as a foundation, covered with small amount of phosphorus.
Phosphorus then converts some part of incoming blue light to higher wawelentgths and the result is more or less "white"...
...from previous meager 40.something percents to 40.8 current percent.
Scary stuff, man...
The moon is made of green cheese. -- John Heywood