| |||||||||||||
Pettenò: Debunking x32 mythsPettenò: Debunking x32 mythsPosted Jun 25, 2012 21:20 UTC (Mon) by Flameeyes (subscriber, #51238)In reply to: Pettenò: Debunking x32 myths by tialaramex Parent article: Pettenò: Debunking x32 myths
Uhm no, again, let's remember that Intel themselves are considering x32 a "closed system" ABI, an embedded ABI, something that Gentoo is very useful for (I know that for experience having worked multiple times before on embedded Gentoo Linux devices).
Please see the other linked article as well, it's easier to see the two of them together.
Also, for what concerns "binaries on disk", the comparison between the two libc files is actually done on the _allocated_ sizes, which is memory, not disk. The fact that it refers to files on disk is definitely not the point.
(Log in to post comments)
Pettenò: Debunking x32 myths Posted Jun 25, 2012 22:47 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
If my earlier interpretation was wrong then this is an even more disappointing use of LWN's space than I thought.
Putting the two articles together I am even more inclined to think it's supposed to be targeted at ricers. Who else could imagine that recompiling some assembly-heavy video codecs for x32 was somehow even remotely relevant? At no point in these articles does it appear that you've really grasped what the people who proposed, developed and shipped this ABI were trying to achieve. You almost touch on it in the second article, but only long enough to lurch onto the afore-mentioned tangent about the C standard library and files on disk.
A lot of the "myths" look more like strawmen. They aren't common misconceptions anywhere, some aren't even mentioned in the not-so-bright comments to the previous article.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 5:25 UTC (Tue) by cmccabe (guest, #60281) [Link]
I'm not sure why you're being so hard on Diego. The whole point of the x32 ABI was increased performance. Diego is questioning whether the API will actually achieve that. You may disagree with his conclusions, but there isn't any need for name-calling.
You don't have to be a "ricer" (whatever that is) to be interested in performance. You could just be an engineer who gets paid to make servers or embedded devices go faster and use less battery. Or someone who is interested in the topic in general.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 17:08 UTC (Tue) by mikemol (subscriber, #83507) [Link]
"ricer" is a pejorative term intended to describe (and be dismissive of) someone who is interested in speed, does things to get more speed, but has no actual understanding of what it is they're doing.
Pettenò: Debunking x32 myths Posted Jun 26, 2012 19:06 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
from how I've seen the term thrown around, there's no attempt to know if the person has any understanding of that they are doing or not. Just the assumption that it's a waste of time.
Pettenò: Debunking x32 myths Posted Jun 28, 2012 17:34 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] In any case, whether it's true or not, the perception that "ricers prefer Gentoo" is far from new. There's an entire website devoted to mocking them, and that website is ooooooollld. (Almost as old as Gentoo.) There are plenty of folk who know what they're doing, I'm sure. At the same time, there is (or at least was) a visible crowd whose competence seems to barely rise above "script kiddie," applying the equivalent of "go faster stripes" to their computer. (20 years ago, I probably would have been no different, I must admit.) If the latter crowd thinks x32 is the latest "go faster stripes" that will magically make their computer a gazillion times faster, then they need to be told why that's not the case. Anyway, I don't really have an opinion on whether Diego's post was aimed at that crowd. I saw some valid criticisms, and some odd attention to multiply latency. *shrug* What I'd really like to see is some comprehensive benchmarks. Now *that* might be interesting. One I'd particularly like to see is "memory footprint of Firefox after loading these 100 tabs." ;-) These days, that seems to be the most common resource hog on my own machine, cycle or RAM-wise.
|
|||||||||||||