[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: 1752477732021.jpg (124 KB, 1280x720)
124 KB
124 KB JPG
Why were AMD FX processors considered bad?
>>
>>108232788
because people ran them on low end 4 phase boards with slow ram
>>
>>108232788
It was subjective really. Weak single core, strong multicore. like >>108232811 said, people were running them on shit motherboards, and using slow crap RAM. AMD recommended 1866MT in the data sheet.
>>
>>108232788
>FX is one letter away from fox
>Fox News is Republican
>Republicans and conservatives were very bad at the time according to plebbit
Politics is gay Jewish tricks
>>
pseudo cores when they say 8 they really mean 4
>>
>>108232788
Dolphin and PCSX2 ran fine on a first gen i7 yet struggled on an FX-6300
>>
>>108233138
There are 8 cores, you can see them if you look closely
>>
>>108232788
faildozer, clock for clock, was slower than their own precious phenom based processors. its why they had to clock faildozer so high and shove as many fake cores they could into them.
in many cases, it was slower than a core 2 quad era processor in games. especially, single core games.
it only ran decently in games that were able to use 4 - 8 cores because, well the game is able to use many cores, but the best faildozer could achieve in that scenario was matching i5's from nehalem and sandy generation.
i was a dumbass who fell for the shilling back then and bought a fx 8350. the thing was slower than a haswell based pentium in games like starcraft 2 that i played heavily back then. i remember trying to play arma and the thing struggled so hard in that. it ran bioshock infinity, ok. just, ok.
i sold it and bought a haswell 4670K. it was night and day difference. it was such a god awful experience with amd that i didn't give amd another chance until the ryzen 5000 series.
>>
>>108233156
Considering how many unnecessary copies PCSX2 does, I believe that.
>>
>>108232788
Bad compared to Intel's offerings, actually good value wise and held up well when more threads became a thing software side and Intel barely gave you more than 4.
>>
>>108233360
>when more threads became a thing
When was that again?
>>
>>108233193
Faildozer was supposed to come out in 2009. The one that came out, finally, was heavily cut down due to GloFo process limitations.
>>
>>108233363
2010's
an OCd FX-8350 would get beat in games by a 2500k in the early 2010's but later on in games like Doom 2016 that were really well optimized and multithreaded, it matched a 4970k.
>>
>>108233417
>Doom 2016
So that's "more threads became a thing" now? One game?
>>
>>108233424
I'd say all the big off the shelf engines were thriving towards better multithreaded support from late 00's to late 2010's
major driving forces being Core2 release and Ryzen release
>>
>>108233433
>I'd say all the big off the shelf engines were thriving towards better multithreaded support from late 00's to late 2010's
So surely you can drop some names? Because mutli-threading doesn't magically happen - you need proper allocation strategies, otherwise you just end up with tons of false sharing and cache line invalidations that congest the memory bus to the point that your multi-threading ends up yielding *worse* performance.

And *many* games don't bother with that, and thus multi-threading. To this very day, even.
>>
>>108233449
>So surely you can drop some names?
id Tech, Unreal, Unity, back then also CryEngine
Doom 2016 for it's time was just a excellent example
>>
>>108233474
Games! Not engines! I want to know which games out there bothered to lay out their fucking data in ways that would take advantage of multi-threading. Otherwise you're actively murdering your performance even with multi-threading.
>>
>>108233486
I think it would be easier for you to list games that run faster single threaded then multithreaded
Actually curious
>>
>>108233507
You're replying to a retard.
>>
>>108233507
I can actually deliver a postmortem:
https://factorio.com/blog/post/fff-215

>>108233511
Wow, you're seething-
>>
>>108233515
Oh, and for the record - I have traced Factorio, and I can say with confidence that they still haven't fixed their allocation patterns - or file I/O, for that matter. Like, that slow load process at the very beginning? Completely unnecessary. They open all files sequentially, they read everything in 4096 byte chunks, at best they *copy* all their stuff from the page cache, if it's still there, and they use absolute paths rather than relative directory handles.

Which is, y'know, pretty bad for a game being praised for being well optimized.
>>
>>108233515
>custom autismo engine
>>
>>108233543
Your point?
>>
>>108233339
Maybe, but the original i7 was up to the task while the FX-6300 wasn't.
>>
File: part_of_the_problem.png (397 KB, 828x683)
397 KB
397 KB PNG
>>108233566
It was a very stupid task though.
>>
>>108233584
A stupid task which proved that a 4 year old processor had more compute
>>
>>108233606
>that a 4 year old processor had more compute
Waiting for the memory bus isn't compute, anon. That's the definition of being memory-bound, not CPU-bound.
>>
>>108233611
Ok so the newer fancy CPU from AMD still had more latency than something which came out during the Bush presidency, and thus wasn't resolved until Ryzen
>>
>>108233611
Memory controller is part of the CPU since... 20 years.
>>
>>108233622
So you're saying CPU manufacturers should be optimizing for retarded software?

>>108233624
>>108232865
>>
>>108233660
No, I'm saying CPU's should have low latency and high performance. The FX-6300 failed at this.
>>
>>108233663
>No, I'm saying CPU's should have low latency and high performance
You're being vague about "performance". More cores provide more raw compute power, meaning that as long as everything is in registers or caches those CPUs will absolutely murder CPUs with lesser cores.

Only problem is that most software isn't doing raw compute. That's why we have out-of-order execution, to execute memory loads way ahead of time.
>>
>>108233688
Ok but the older i7 with fewer cores still had better performance, which you seem to have suggested is due to lower latency. Latency is obviously a bad thing.
>>
>>108233701
>but the older i7 with fewer cores still had better performance, which you seem to have suggested is due to lower latency
"Overall performance", but yes - due to lower latency. In short: Intel was, and is technically to this day still, optimizing for poor software.
>>
>>108233710
Latency is a bad thing. Lowering latency is not just about subsidising bad software, lol
>>
>>108233732
>Latency is a bad thing
And you can avoid latency. In software. That's what caches, prefetchers, out-of-order execution, shadow and SIMD registers and so on are all about.

Unless, y'know, you completely give up on where you're going to place your data, and adhere to retarded ABI rules where it makes no sense (module-internal code, which is a staple for compilers to fuck up). See >>108233515.
In fact, if anything more cores also means more L1 and L2 caches. In theory there should be even *less* latency than with fewer cores.
>>
>>108233749
And it's not like latency was an entirely new thing in 2009. The 386, released in 1985, already had a cache for address translations (TLB), the 486, released in 1989, had a unified (data + instruction) cache, and it's been getting worse ever since.
>>
>>108232788
Phenom II was basically equal to Core 2, and launched a year later. A year after Phenom II, Nehalem launched and just shat all over everything else.
Insert huge 3-year gap until Bulldozer finally launched, and despite AMD already being far behind Intel, it was strictly worse than even Phenom II in everything except heavily multithreaded integer math.
The entire Bulldozer family just sucked, for a long time, to the point that it alone put AMD in very real danger of folding. They probably would have if Zen hadn't turned out to be such a huge success.
>>
>>108233749
>And you can avoid latency. In software.
The software itself doesn't affect the physics of the metal. For years and years AMD CPU's just had horrendous logistical bottlenecks which didn't exist on Intels.
>>
>>108233835
>For years and years Intel CPU's just had horrendous logistical bottlenecks which didn't exist on AMDs.
>>
>>108233842
Dolphin and PCSX2 ran better on a Core 2 Duo than any pre-Ryzen AMD, and this is a more practical real world examples than some hypothetical spreadsheet generation bullshit.
>>
>>108233850
>>108233660
>>
>>108233853
Your only evidence for them being badly optimised is that they demanded lower latency, which to me just sounds like emulating these consoles inherently demands low latency.
>>
>>108232788
Back in the day, most programs were single or lightly-threaded. You would get more from a strong quadcore than a weak octocore.

Bulldozer was a huge disaster. Worse performance than the Phenoms.
>>
>>108233858
>Your only evidence for them being badly optimised is that they demanded lower latency
I can provide more evidence if you'd like. PCSX2 for instance used to have to switch to kernel mode and copy 256 KiB (one sector + one readahead) for every single read, and then copy that again into the instruction decoder. They recently fixed that ... by allocating a big chunk of memory and copying the ISO's data into that chunk, rather than using the page cache directly. The only possible reason why you would ever do that is to avoid page cache limitations, like the inability to use larger pages (size and alignment), *which they're also not utilizing*, meaning that the emulator is thrashing 128 TLB entries for every sector read. Oh, and the copy into the instruction decoder is also still there.

Mind you, that's within the last year that I looked into the emulator. I haven't had the stomach since.
>>
>>108233890
So if you were developing for an FX-6300, how would you emulate a 729Mhz PowerPC processor at full speed?
>>
>>108233915
Dunno much about the PowerPC, but my first thoughts are
>long-mode only
>recreate memory map of machine in one chunk so that address translation is easy (a single offset to be added, like on OG UNIX)
>possibly all within 1-GiB pages (have been a thing since 2010+, to reduce TLB pressure)
>since both NT and Linux don't support hugepage file caches allocate another HP mapping and copy the ISO data in there (again to refuse TLB pressure)
>let instruction decoder read directly from the mapping
Obviously HP support would be optional, setting this shit up is pretty fucked up, but if users actually go through the trouble I want to reward them.
>>
>>108233947
... now that I think about it, for an FX-6300 bigger pages would possibly even better than for modern CPUs. Back then you had dedicated TLBs for 4-KiB, 2-MiB, and 1-GiB pages, with the latter ones being completely ignored. Nowadays it's all one TLB whose entries can all switch, meaning that you're going to have at least one entry for each chunk of memory.
>>
File: 19-103-849-02.jpg (79 KB, 640x596)
79 KB
79 KB JPG
Rest easy friend
>>
>>108232788
Partially because they only had 4 fpus, but mainly because they stuck around for a long time without any major revisions or upgrades. They were competitive with the Intel CPUs they launched to compete against, they just weren't against the following generations, and AMD didn't release a successor until Zen.
>>
File: royal_knight.png (377 KB, 1261x718)
377 KB
377 KB PNG
Heat pipe count is like core count; more not always better.
Royal Knight 120 SE (6 heat pipes) puts 7 heat pipe coolers to shame.
>Updated performance pure copper heat pipes.
>Unbounded by gravity affecting heat pipe performance,
>Six AGHP technology heatpipes.
>>
>>108232788
because they were about 0.8x in games compared to ivy bridge
much like arrow lake
>>
>>108232788
I want to thank the people who bought Bulldozies I couldn't do it myself as it was too shit but you guys gave AMD enough cash to stay alive so thank you
>>
>>108238167
You are welcome. Btw, my FX 8150 still running a secondary PC and it came inside a cool metal box.
>>
File: AMD-bulldozer.jpg (44 KB, 300x200)
44 KB
44 KB JPG
2011 was a disappointing year for AMD
>>
>>108233115
LMFAO
>>
they TDP 148W ish and people used old aircoolers that could cool 90W?
>>
>>108232788
I remember my friend getting assblasted when we benched flac to AAC encoding and my 2600K wiped the floor with 8350, so much for that multithreading performance jej
>>
>>108242727
I can dig out my 8350 we can retest
>>
>>108233424
It was during the 8th console gen, Battlefield 4 for example performed better than 3 on them because it was targeting consoles with 8 cores.
>>
>>108233138
keeping your instruction pipeline full is a legitimate optimisation technique
>>
>>108243354
that was so long ago, I have a 9800x3d now
>>
File: Clipboard_02-26-2026_01.png (71 KB, 1102x185)
71 KB
71 KB PNG
>>108232788
yes they were bad, from shitty mobos to architecture
there is a reason of why i am still running on x79 platform



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.