similar to: [LLVMdev] The performance of LLVM vs GCC

[and copy to list] Jianzhou Zhao wrote: > Hi all, > > This talk includes the performance comparison between LLVM and GCC > (page 30/31): LLVM wins a lot for both compilation and execution time. > http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf > That talk and data were in 2008, I was wondering if there is any > updated performance evaluation between the latest LLVM and

And this one, with LLVM ~3.0: http://www.phoronix.com/scan.php?page=article&item=amd_bulldozer_compilers&num=1 -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Martin Whitaker Sent: Thursday, November 03, 2011 11:01 Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] The performance of LLVM vs GCC [and copy to

Hi Martin, > Here's a more recent one: > > http://www.phoronix.com/scan.php?page=article&item=gcc_46_llvm29&num=1 a few comments: (1) The smallpt benchmark uses openmp which dragonegg supports but clang does not. That's why on the machines with N processors the clang compiled binary takes N times as long as the others: it is only using one processor unlike the others.

On Nov 3, 2011, at 3:27 AM, Duncan Sands wrote: > On 11/03/11 10:11, Rotem, Nadav wrote: >> And this one, with LLVM ~3.0: >> >> http://www.phoronix.com/scan.php?page=article&item=amd_bulldozer_compilers&num=1 > > What, no dragonegg?! :) It is worth pointing out that the methodology of Phoronix makes their results basically useless. They willfully test -O0

On 11/03/11 10:11, Rotem, Nadav wrote: > And this one, with LLVM ~3.0: > > http://www.phoronix.com/scan.php?page=article&item=amd_bulldozer_compilers&num=1 What, no dragonegg?! :) Ciao, Duncan.

Hi Jianzhou Zhao, > This talk includes the performance comparison between LLVM and GCC > (page 30/31): LLVM wins a lot for both compilation and execution time. > http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf > That talk and data were in 2008, I was wondering if there is any > updated performance evaluation between the latest LLVM and GCC? Vladimir Makarov did some

AMD is dropping support for the R300-R500 cards in their official drivers: http://www.phoronix.com/scan.php?page=article&item=amd_r500_legacy&num=1 As the current open source drivers do not support 3D, I'd like to know which Compiz effects use 3D and which use 2D. Thanks. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il

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

Hi everyone. I read on a 2011 article - http://www.phoronix.com/scan.php?page=article&item=nouveau_comp_2011&num=19 - that my particular card, GeForce 8400 GS, overheats with nouveau. (So, I never tried using if for long, before, as soon as possible, installing the proprietary drivers...) But, because it's a 2-year-old article, I was wondering if that problem could have been, in the

http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 as of version 2.8, LLVM is generating slower code than the newer GCCs but generates the code more quickly.

Hi Edwin, >> http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 >> as of version 2.8, LLVM is generating slower code than the newer GCCs >> but generates the code more quickly. >> > > I would be more concerned about the 'unable to compile', or 'compiled > code not working correctly' issues. It would help if they

http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1 Regards, Stefano

Hi, this is about kicking-off regular compile-time tracking for LLVM and CLANG on the green dragon: http://lab.llvm.org:8080/green/view/Compile%20Time/ <http://lab.llvm.org:8080/green/view/Compile%20Time/>. The goal is to stay on top of compile-time issues immediately when they occur so they can be assessed rather than creeping in unnoticed. The methodology is simple: form a CTMark suite

On 27 April 2010 08:18, Stefano Delli Ponti <stefano.delliponti at gmail.com> wrote: > FYI > http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1 For Apache and Dhrystone, the performance boost is good (but only the former is really important), but for the rest, especially those with image/sound processing, and HMMR, it's still far behind. Is this only

On Wed, Feb 18, 2015 at 1:39 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Feb 18, 2015 at 12:04:47PM -0500, Jack Howarth wrote: >> My concern is that, without strict enforcement of the triaging >> serious P1-type bugs, the major llvm.org releases will devolve into a >> continual exchange of one set of major regressions for another set.

> On Nov 17, 2016, at 2:55 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi Gerolf, > > This is really cool! > I’m very excited about this initiative and I hope we’ll be able to get to a stage where compile time regression are handled like other regression: if they are not expected / justified by the commit author promptly, the commit should be reverted in the

>>> http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 >>> as of version 2.8, LLVM is generating slower code than the newer GCCs >>> but generates the code more quickly. >>> >> >> I would be more concerned about the 'unable to compile', or 'compiled >> code not working correctly' issues. It

According to http://www.phoronix.com/scan.php?page=article&item=mesa_gallium3d_d3d11&num=1, Direct3D 10 and 11 are supported in Linux natively. Is this only with the open source drivers? Anyone have an approximation as to when Direct3D Windows games will use this instead of having the added overhead of translating to OpenGL? Any input would be appreciated! Thanks in advance!

Dear People I have installed wine 1.3.13 with windows 7 mode. I know that bug is old, but now with the new patch of Wow appear again the Bug is the number 24928 I have one Nvidia Gforce 450 GTS 1 GB ram DDR5 with the drive 270.18 The problem is with wine wow -d3d11 appear the bar in fair mode, and the option good and ultra are not accesible. I want to know if that problem is only mine or

Chandler, Thanks for the reply -- I always included you in libiomp supporters camp; it is good to see I wasn't mistaken! ;-) On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at google.com> wrote: > Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] > No, sorry. libgomp doesn't