Slashdot Mirror

I'm going to give Torvalds the benefit of the doubt and assume he might have overlooked this on the mailing list: http://www.phoronix.com/scan.php?page=news_item&px=MTA0ODE but NVIDIA proposed a very reasonable solution to the Optimus on Linux problem, and everyone just started arguing that it needed to be more Stallmanesque. Sitting there demanding that NVIDIA open up[ their source code is silly.

This is only true if your definition of "full-featured" does not include KMS or complete XRandR support.

They added XRandR 1.2/1.3 support in 302-series.

See e.g. http://www.phoronix.com/scan.php?page=news_item&px=MTEyMDk

Is this to do with the Great Game or just the stuff the rest of us don't play in real life?

Because the IBM advert in here:

http://www.phoronix.com/scan.php?page=article&item=ubuntu_1204_omap4460&num=1 just wouldn't go away.

And the results table wasn't designed to work properly on Ubuntu. Not on my Ubuntu at least.

Or maybe it doesn't like Opera. (Whose DDoSsing them by the way?

Not the Persians shirley?)

So what I was thinking is... that with a super-fast Ubuntu desktop, can Tetris work?

Or Pacman?

Anyway, now that you have scared everyone off Intel Chips and Microsoft Operating systems....

Besides nuclear bunkers, what's next to build?

Phoronix just today compared ARM power efficiency (on a cluster of PandaBoards) to Atom, Ivy Bridge and AMD Zacate. http://www.phoronix.com/scan.php?page=article&item=phoronix_effimass_cluster&num=1

End result: ARM was far more efficient - performance per watt was far superior to Atom and Zacate. And that was with GCC 4.6 and Ubuntu 12.4, GCC 4.7 optimises for ARM significantly better...

Performance/Watt on IB was very good however, but overall power consumption was very high comparatively.

Phoronix just did an article on 6 clustered Panda boards (Cortex A9) VS the other guys. It's worth a read.

There was already an article about L4D2 running on Linux.

http://www.phoronix.com/scan.php?page=article&item=valve_linux_dampfnudeln&num=2

Here are some facts. GCC 4.6.3 Loses to Clang 3.0 50% of the time. GCC 4.6.3 Loses to Clang 3.0 ~18% of the time. Most of the benchmarks use OpenMP which clang doesn't support. GCC 4.6.1 Loses to a prerelease Clang 3.0 ~50% of the time.

Where are you getting this 90% from? Cause it's not from reality.

I also get quite variable results. I have some code that runs significantly faster with gcc 4.6.x or 4.7.x. Other code is faster with clang 3.0. It really depends. In my experience gcc is more faster than not, but the gat is closing quickly. Roberto

Here are some facts. GCC 4.6.3 Loses to Clang 3.0 50% of the time. GCC 4.6.3 Loses to Clang 3.0 ~18% of the time. Most of the benchmarks use OpenMP which clang doesn't support. GCC 4.6.1 Loses to a prerelease Clang 3.0 ~50% of the time.

Where are you getting this 90% from? Cause it's not from reality.

I also get quite variable results. I have some code that runs significantly faster with gcc 4.6.x or 4.7.x. Other code is faster with clang 3.0. It really depends. In my experience gcc is more faster than not, but the gat is closing quickly. Roberto

Here are some facts. GCC 4.6.3 Loses to Clang 3.0 50% of the time. GCC 4.6.3 Loses to Clang 3.0 ~18% of the time. Most of the benchmarks use OpenMP which clang doesn't support. GCC 4.6.1 Loses to a prerelease Clang 3.0 ~50% of the time.

Where are you getting this 90% from? Cause it's not from reality.

I also get quite variable results. I have some code that runs significantly faster with gcc 4.6.x or 4.7.x. Other code is faster with clang 3.0. It really depends. In my experience gcc is more faster than not, but the gat is closing quickly. Roberto

I see you were modded down as flamebait. However, benchmarks would seem to support your claim.

C'mon Apple people, please back off the reality distortion. LLVM has a lot of interesting points to recommend it, but one those is very definitely not beating GCC in code optimization. Particularly GCC 4.7 which has turned in yet another impressive performance increment across the board.

I see you were modded down as flamebait. However, benchmarks would seem to support your claim.

C'mon Apple people, please back off the reality distortion. LLVM has a lot of interesting points to recommend it, but one those is very definitely not beating GCC in code optimization. Particularly GCC 4.7 which has turned in yet another impressive performance increment across the board.

Here are some facts.
GCC 4.6.3 Loses to Clang 3.0 50% of the time.
GCC 4.6.3 Loses to Clang 3.0 ~18% of the time. Most of the benchmarks use OpenMP which clang doesn't support.
GCC 4.6.1 Loses to a prerelease Clang 3.0 ~50% of the time.

Where are you getting this 90% from? Cause it's not from reality.

Here are some facts.
GCC 4.6.3 Loses to Clang 3.0 50% of the time.
GCC 4.6.3 Loses to Clang 3.0 ~18% of the time. Most of the benchmarks use OpenMP which clang doesn't support.
GCC 4.6.1 Loses to a prerelease Clang 3.0 ~50% of the time.

Where are you getting this 90% from? Cause it's not from reality.

Here are some facts.
GCC 4.6.3 Loses to Clang 3.0 50% of the time.
GCC 4.6.3 Loses to Clang 3.0 ~18% of the time. Most of the benchmarks use OpenMP which clang doesn't support.
GCC 4.6.1 Loses to a prerelease Clang 3.0 ~50% of the time.

Where are you getting this 90% from? Cause it's not from reality.

Unity 3D will use LLVMpipe to dynamically translate OpenGL to CPU commands. Modern CPUs have enough horsepower to do desktop effects in software. I will miss Unity2d though. It was the only usable Unity type. Check out this Phoronix article for more info http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTA

I know, it feels like tilting at whindmills ... or working in the Fox Fact-Free Zone.

Just look at the mess of the "latest and greatest" video card support from 2 weeks ago. Stability problems, locking up, memory corruption, across-the-board lack of functionality ... this all points to a serious design flaw in the kernel itself. Every cpu since the 386 has supported 4 "rings", or levels of access and process/memory protection. Why implementers only use two of them, and insist on running graphics drivers in the kernel is a holdover from the past when context switches were more expensive in terms of "wall clock time".

People also forget that one of the reasons that DOS was a $15 billion product was because they bent over to maintain backward compatibility between versions. There was even code to make sure that newer versions of DOS specifically didn't break SimCity.

We hear all the screaming about how "Linux needs games", "Linux needs applications" (and not just clone-wanna-be work-alikes) but nobody's doing the dirty work. Everyone's just playing around with making a "shinier desktop experience." A lot of that has to do with the problems with interacting with gpl-licensed code. Nobody wants the headaches from the zealot hordes.

I think the point you're making is covered pretty comprehensively in this article:

http://www.phoronix.com/scan.php?page=article&item=valve_linux_dampfnudeln&num=1

Phoronix.com just published an article called "AMD To Drop Radeon HD 2000/3000/4000 Catalyst Support and never mentions software freedom in their article. The proprietor changes but the freedom issues remain the same.

And now OpenGL basically owns the entire gaming universe except for the steadily shrinking part over which Microsoft is able to exercise monopoly control.

Well, and Linux gaming does exist, just not at the level where we can throw away our consoles quite yet. But that day is coming.

One can fairly ask, why is the Linux game market, with millions of potential customers, not already well served by the likes of EA and Activision? I don't know the answer to that, and I don't think you do either. It very definitely has nothing to do with the influence of CAD vendors on OpenGL. I tend to suspect the hidden hand of Microsoft, however I do not have firm evidence of that.

I think the main reasons are much simpler (even if I would not trust Microsoft to abstain from meddling):
1) Low market share of Linux on the desktop. That means far fewer potential customers.
2) For fast 3D graphics (which are important to "AAA"games), the driver situation on Linux is still a bit unsatisfactory. You either have to run the binary drivers from the vendor, which have a lousy reputation in case of AMD, or the Open Source drivers which are still inferior in terms of performance (check the benchmarks on http://www.phoronix.com/scan.php?page=home).
For the Open Source drivers, the situation in the field is probably worse than the Phoronix benchmarks suggest:
Phoronix usually tests the latest developments, which will then take some months more to go into the next kernel version and some months on top of that to land in the distros. Not so long ago, the Open Source drivers were struggling not only with performance but also with correct rendering. I suspect a lot of those broken drivers are still out there.

clang is nice but it is far from producing efficient code...

[citation needed]

The big regression was fixed this release, I do believe.

ah, yes: http://www.phoronix.com/scan.php?page=news_item&px=MTA2OTY

ivy bridge compare to ARM

Arm is in the same neighborhood as the Atom N270 and Z530. Cortex A11 is the next revision.

it depends on the specific Arm processor, there's a vast number of variants, from those designed to go into kitchen appliances to those for "smartbooks". here's a comparison of arm vs atom:
http://www.phoronix.com/scan.php?page=article&item=ubuntu_1204_armfeb&num=1

If one believes the recurring tests at http://phoronix.com/, the open source (Gallium3D) drivers for the R300 through R500 chipsets are reasonably mature this days. Still slower than Catalyst, but for a Windows manager they might do.

And Catalyst versions after 9.3 don't support R300 anyway (see http://www.phoronix.com/scan.php?page=article&item=amd_r500_legacy&num=1). So unless you already tried it, why not run the open source drivers?

If one believes the recurring tests at http://phoronix.com/, the open source (Gallium3D) drivers for the R300 through R500 chipsets are reasonably mature this days. Still slower than Catalyst, but for a Windows manager they might do.

And Catalyst versions after 9.3 don't support R300 anyway (see http://www.phoronix.com/scan.php?page=article&item=amd_r500_legacy&num=1). So unless you already tried it, why not run the open source drivers?

The changes would go upstream, not downstream. And some of Android's kernel patches have been merged with mainline. Linus himself stated last year that he expects the two source trees to merge gradually over time. http://www.phoronix.com/scan.php?page=news_item&px=MTAzMTY

It has nothing to do with AMD and frankly you will NEVER get those bits because it would be illegal to give them to you. AMD has already said there is nothing they can do over HDCP and protected path as that technology is owned by the HDMI consortium and to give out that information would be breaking DMCA as well as get every AMD card blacklisted. If you want those bits you can use the blob which again Phoronix ran full tests and found it runs just fine on Ubuntu 10.04 and Ubuntu 11 runs OOTB, it also smokes Atom + ION on their benches. For a board that costs just $142 for the barebone kit complete with PSU and case that makes it a hell of a cheap Linux box, especially when you figure in the fact you are getting dual core plus Radeon plus the ability to run 8Gb of RAM.

But FOSS users are simply gonna have to accept the fact unless you wanna do like RMS and hop on chinamart for some funky ass Loongson MIPS netbook there are NO machines that you are gonna have complete access to, because if it has even slightly modern video output it'll have protected path and if it has wireless it'll have non FOSS firmware. Hell even the Raspberry Pi has broadcom binary blobs, welcome to reality. in the end what should matter is "does it work" and as phoronix shows yes it does, and it beats Atom + ION while having better graphics and often a lower price. Seems like a win/win to me but if you really have your heart set on Nvidia they have a PCIe slot, and there is an open box GT210 on Newegg for less than $20, knock yourself out. Even with the discrete card it'll still be cheaper than an Atom + ION board.

You might not be joking.

Last I checked, clang wasn't anywhere near close either g++ or VC++ when it came to optimizing code - so, no.

Last I checked it was beating GCC in quite a few places.

But now we see the strategy of Canonical and why the (at the time) weird decisions were being made

Um duh, it was made for Instant-On web devices, it just so happens that tablets fall into that category nicely.

But let's look at each point individually because not everything you stated relates to Canonical's desire to go to Tablet's, it's more along the lines of, "it just happens to also help them out towards tablets."

1) The nasty split, isn't any more nasty than other things in the Linux world. Canonical wants Canonical stuff in Canonical's distro. GNOME 3 is still used in Unity, but just differently. It's hard for me to explain because I suck at summing things up, but trust me, Unity is GNOME 3 at the core and Unity runs more with how people predicted GNOME3 to be used more as a platform and less like a standard desktop. The main facet is that it removes a lot of upstream push from the GNOME community. Canonical wants their desktop to look the way they want it to look, not what GNOME developers want it to look like. You'll see this type of mentality in a lot of Ubuntu. Also, let's face it GNOME developers are difficult to work with at best. It's very easy to paint the main developers as being the pearly towers (metaphor for someone who dictates how things should happen, but have little to zero real-world experience to back up exactly why that's right.)

2) The choice to use Wayland over X boils down to the same debate that was had on xgl versus aiglx. Mark thinks running direct to the video card is a better method than the way X provides. This has been a common thing that comes up ooo, I'd say every five to six years. Someone comes up with a better way to run direct to the card and someone jumps on the band wagon. Usually there is just too much inertia to make the jump from X to the something else happen and we all go back to using X happily. There's a lot of misconception that Xorg (specifically) and X11 (in general) are bloated, slow, won't run well on older machines. X11 is a pretty hefty "standard," but not everything in it is in every implementation. There are multiple of X11 implementations (I'm given too, Google can help you see more) that target embedded systems that run quite well. Xorg implements a lot of stuff to keep backwards compatibility with older machines. Wayland doesn't. However, don't confuse that because just because it is implemented does not mean that it gets loaded if it is not needed. You aren't going to be using XRender when your video card offers the ability to use OpenGL pixmap to texture. The biggest problem with X is drivers (and that shouldn't surprise anyone) and the low quality those drivers exist in. That problem will not go away with Wayland. The idea is, and to me it's a bad bet, if we make the model more simple (remember the X11 "spec" is a pretty big tome) then vendors will be more incline to write better drivers since the model for those drivers is more simplistic. However, as bets go, that's immaterial to why Canonical wants to go Wayland. It really boils down to the fact that they want to do Window Decorations the way they want to do Window Decora

This one? http://www.phoronix.com/scan.php/images/www.phoronix.com/scan.php?page=news_item&px=MTAyMjk

Wait for 3.3

State of ATI/AMD drivers on Linux is rather poor, much worse than nVidia. My recommendation is to stay away from AMD GPUs if you plan to use Linux. If you are looking for more details about AMD & Linux read this article on Phoronix: http://www.phoronix.com/scan.php?page=article&item=amd_ayir_2011&num=1

That was why head-to-head benchmarks of Linux and FreeBSD on SMP and file-system performance showed FreeBSD coming out ahead pretty consistently.

When overall performance of freebsd is lower, who gives a damn?

One element has me curious about how these benchmarks were prepared: Is the benchmark software compiled on the target platform/cpu combination with all available optimisations of that platform?

Although /. has many haters for the site (ads everywhere), phoronix.com is the only benchmark site I've found that not only tells you, but tests out suggestions & rumors. The link compares AMD's Open64 compiler and gcc4.7 on an FX8150.

I want to believe that the FX series isn't inferior to everything it gets put up against because it is the first CPU with SSE4.1 & SSE4.2 AMD made, and was hoping _some_ benchmark software actually uses it.

This probably makes the texture compression patent (S3TC) invalid. Now it can be safely implemented in Mesa.

Not unlikely. Although there does not seem to be any legal ruling that mandates this, this claim is mentioned here and on Wikipedia.

That is why I stick to the benchmarks on Linux for fair comparisons of AMD and Intel. Not to mention most gaming benchmarks (or real performance) don't give two shits about what cpu it is ran with. The main benchmarks I've seen so far have been from phoronix. It seems like a perfectly decent cpu though maybe the price should drop a bit. My two cents: the AMD A-series is the way to go, especially in laptops like this A6-3400.

Possibly already fixed: "Some drivers (e.g. the e1000 network driver) have already switched off the ASPM where the PCI-E v1.1 feature is known to not work" Phoronix If not, report it and that driver will get ASPM blacklisted.

If the firmware has given us control of PCIe capabilities then it's valid for an operating system to configure ASPM more aggressively than the firmware did. A small number of devices object to this and exhibit various failure modes. Windows provides a mechanism to disable ASPM in the driver, indicated by the Needs=PciASPMOptOut statement in the .inf file. Trawling through Windows drivers has indicated the following set of hardware that disables ASPM in Windows but doesn't currently disable it in Linux. It makes sense for us to mimic Windows in this situation. (V2: send the version that actually builds)

Matthew Garrett, these patches did get noticed by Phoronix.

These benchmarks say that Linux is usually faster than any BSD flavor.

I don't think that's the conclusion to come to from those benchmarks. Only two benchmarks occurred where Linux was significantly faster than FreeBSD; onewas the Himeno Benchmark test doing a "Poisson Pressure Solver" -- and only one of the two systems tested had this issue, not the other. The other benchmark where Debian Linux was faster than BSD was the Threaded I/O tester. For all the other tests the differences were minor, and in several cases BSD was faster. I don't think there's any clear conclusion to draw from these tests.

I don't personally run FreeBSD (thusfar) so I don't have personal experience to draw on for comparing BSD vs Linux speed. However I will say that speed is not the reason I run Linux rather than BSD.

Sorry, but it's not worth the time and whatever "spades" you're getting paid pack in are 99% emotional, not physical.

These benchmarks say that Linux is usually faster than any BSD flavor.

As for stability, I can't find any definite stats on this. Personally, haven't seen a Linux crash since 1997, and that's a pretty damn long time.

Absolutely. Chromium is already being ported and I would love to see Mozilla's Azure optimized for Wayland. I'm anxiously waiting for the speed boost.

Its the same reason I doubt you'll be seeing any companies opening their hardware anytime soon, as AMD bent over backward, even hiring coders to help the FOSS driver guys and opened their specs as wide as they could, and what did they get? every forum filled with guys saying "Herp derp, buy Nvidia"

With regard to GPUs, I currently have a (aged) Nvidia GPU but my next GPU will be the top end Intel Ivy Bridge. I'll be going Intel because I want a newer and faster CPU, the Ivy Bridge GPU will be fast enough for me, and most of all because the open source Sandy Bridge and Ivy Bridge support from Intel is strong now and improving. Intel seem like they'll hit the ground running for Linux support when Ivy Bridge is released. I want strong, out-of-the-box, open source GPU drivers for Linux and that's what Intel will deliver.

Here's a recent article from Phoronix which bencmarks Intel's progress with its Sandy Bridge\Ivy Bridge drivers for Linux: http://www.phoronix.com/scan.php?page=article&item=intel_sna_maturing

Your post got me curious, because I always had the impression that Linux is better than Windows in supporting old hardware. So I did some digging and found, yes, they do drop old stuff, but usually it is really old stuff. So old that few people will use it anymore.

For instance, this article http://www.phoronix.com/scan.php?page=news_item&px=OTg0Mg is about old graphics hardware that will be dropped in upcoming X.org releases. Typically, these chips were released in the late 1990s, so if you have a PC bought around the year 2000, you might have one of those.

But how many people do? I consider myself a bit of a pack rat, but even so I draw the line at keeping the three most recent "sets" of PC hardware.
- a Pentium 4 from 2004, with board/ GPU/ power supply from the same year, now sitting in an old case from 1996. To my best knowledge, none of the components is scheduled for de-supporting in Linux anytime soon.
-an AMD Athlon64 X2 from 2007.
-a new AMD quad core, recently assembled into the (really nice) case from 2004. This one is my new primary PC.

Most geeks change their PCs more often, so by geek standards, I think my oldest PC is rather ancient.
Corporate users seem to have a 5-6 year replacement cycle these years. At my place of work, most PCs are Core2Duos these days, with a few Pentium D still hanging around. Most single-core P4 are already gone.

That leaves underfunded schools and administrations (especially in third world countries) as the most likely candidates to have hardware from 2000 or older. Maybe it would be a good idea for them to maintain a distro for older hardware. The basis could be something like Debian stable (which is a few years behind the bleeding edge anyway ;-).
 

Phoronix has a set of benchmarks showing bulldozer is quite competitive when running under Linux.

http://www.phoronix.com/scan.php?page=article&item=amd_bulldozer_scaling

http://www.phoronix.com/scan.php?page=article&item=amd_fx8150_bulldozer&num=1

That power regression is easily fixed with pcie_aspm=force. I have yet to hear about a laptop that has trouble with that.
http://www.phoronix.com/scan.php?page=news_item&px=OTYwNA

Did you saw this? http://www.phoronix.com/scan.php?page=news_item&px=OTg5Nw

A preview of the types of comments being received was just posted, with predictable results so far (i.e. an onslaught of anger and hate directed towards the GNOME devs)

Hmm, I was aware of the LLNL port, but didn't know about KQ.
http://www.phoronix.com/scan.php?page=article&item=zfs_linux_coming&num=1

While digging deeper, it seems KQ has been bought out and their work stopped:
http://punetech.com/solid-state-storage-company-stec-acquires-punes-kq-infotech/
http://www.osnews.com/comments/24853?view=threaded&sort=&threshold=0

Okay, so the closest thing I can find is this:
http://www.olcf.ornl.gov/wp-content/events/lug2011/4-13-2011/1130-1200_Brian_Benhlendorf_LUG11_ZFS_on_Linux_for_Lustre.pdf

It actually sounds to me more that Sun worked on porting Lustre to integrate ZFS as a backend, not that Sun worked on porting ZFS to Linux?