Displaying 7 results from an estimated 7 matches for "23x".
Did you mean:
23
2004 Apr 27
0
[LLVMdev] LLVM benchmarks against GCC
...ather quicker then GCC code
> some tests are still (moderate) slower,
> but some are much quicker (up to 5 times).
> b) LLC code is still rather slower then GCC code.
> However some tests show up to 5 times speed up
Be careful comparing these numbers. I see that we have a 23x speedup
today over GCC on the "burg" test, but we go from 0.093 -> 0.004s. :)
The shorter the test runs get, the more noisy they get, so unfortunately
we're not getting a realistic 23x speedup here. ;-)
That said, there are quite a few 20%, 40%, and even an 85% speedup here.
>...
2004 Apr 27
2
[LLVMdev] LLVM benchmarks against GCC
Hi all,
i was thinking that this question was not good
right after relese 1.0, but now perhaps it is OK...
if not, then I am sorry.
So, what about current status of benchmarks?
I mean comparison to gcc.
I have looked at
http://llvm.cs.uiuc.edu/testresults/X86/
Unfortunatelly graphs lines are hardly for human eye,
but tables are OK.
I give my own interpretation for April 26, 2004
2017 Aug 16
1
Heroic LLVM optimizations
I'll be interested in seeing the improvements. As a reference, this is
what I get in an Intel 6700K when
I compare gcc 5.4 (Ofast flto) vs published Intel results. 23x in
libquantum, and over 40% in many benchmarks.
I think that it is mostly from AoS vs SoA and loop transformations.
5.4
OfastICCperlbench12.9812.100.93bzip27.647.851.03gcc12.3011.000.89mcf14.0821.781.55gobmk8.308.981.08hmmer9.0727.002.98sjeng8.949.731.09libquantum23.10535.0023.16h264ref15.772...
2004 Apr 29
2
[LLVMdev] LLVM benchmarks against GCC
> Be careful comparing these numbers. I see that we have a 23x speedup
> today over GCC on the "burg" test, but we go from 0.093 -> 0.004s. :)
> The shorter the test runs get, the more noisy they get, so unfortunately
> we're not getting a realistic 23x speedup here. ;-)
> [...]
> These are even more dubious. In particular, on...
2002 Jan 07
0
New package: colSums
...immediately to reals, which is
probably inefficient. Brian Ripley's version seems to do a better job.
- S-Plus does not have "rowStdevs" for reasons unknown, since it is simply
defined as rowStdevs(x, ...) <- function(x, ...) sqrt(rowVars(x, ...)).
- For me, colSums is about 23x faster than apply (on a 400 x 40000 matrix).
--
-- David Brahm (brahm at alum.mit.edu)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-announce mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info"...
2017 Aug 16
2
Heroic LLVM optimizations
Hi Tobias-
The loop fusion you mention is the one in libquantum/cpu2006 ? Or something else in cpu2017 ?
-Thx
Dibyendu
-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tobias Grosser via llvm-dev
Sent: Wednesday, August 16, 2017 10:10 AM
To: renau at uncore.io; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Heroic LLVM optimizations
Hi
2006 Jul 17
28
Big JBOD: what would you do?
ZFS fans,
I''m preparing some analyses on RAS for large JBOD systems such as
the Sun Fire X4500 (aka Thumper). Since there are zillions of possible
permutations, I need to limit the analyses to some common or desirable
scenarios. Naturally, I''d like your opinions. I''ve already got a few
scenarios in analysis, and I don''t want to spoil the brain storming, so