Article: Hot Chips XXI Preview
By: Richard Cownie (tich.delete@this.pobox.com), August 20, 2009 7:47 am
Room: Moderated Discussions
JasonB (no@spam.com) on 8/19/09 wrote:
---------------------------
>Our current codebase started in 1995 using what was a particularly flaky and non-conformant
>compiler in those days (Visual C++) but even then sort() would have been a pretty
>safe portion to use. It's such a simple algorithm relying on such simple operations
>that if the compiler couldn't compile that right then you wouldn't trust it to compile anything.
Oh, I daresay the STL sort() was *correct* from the
beginning. But when it's a) mixed in with a lot of
other flaky stuff, and b) not particularly fast in
some cases, then the decision to use it is not so obvious.
>I tend to favour standard libraries where-ever possible on the basis that they
>have been more widely deployed and more widely tested than anything I am ever likely
>to write.
And that's a good argument for the *correctness* of such code.
But for uses which are performance-critical, I'm much
more skeptical about picking up "standard" stuff which
necessarily has to cater to the lowest common denominator,
rather than being optimized to the characteristics of your
own particular problem.
>Furthermore, with a sort routine it is obviously trivial to assert() a call to
>a simple function that does a single pass through the data to verify it is in the
>correct order. I wish all operations were that easy to check.
Yeah, that's one way a sort() can go wrong. The other way
is a bus error or segmentation violation ... or maybe a
pathological case that takes hours to run, or even an infinite loop. And if any of those happen,
you can bet it will be at the site of your largest
customer, right while you're negotiating a big order :-(
>of the language. However, ten years is also a long time, and it probably wouldn't
>hurt you to revisit your assumptions to see if there are better ways of doing things
>now -- not just because your tools should have matured a lot during that time, but
>also because being forced to remain single-threaded due to design decisions made
>back then is leaving increasingly large amounts of performance on the table.
Trouble is that "revisiting assumptions" in 1M+ lines of
code could take years. If something shows up in profiling
or other performance analysis, then you look at it, for
sure. But otherwise it's all going to stay just the way
it is.
As for the "single-threaded" issue, I'm actively working
on ways to exploit more parallelism. But my own opinion
is that a scheme based on multiple processes (each
with their own protected address space) is likely to
yield a product-quality solution much earlier than an
approach based on multiple threads in a single address
space (which is the more conventional approach). YMMV.
>could make your software faster just by buying a new PC. Porting it to 64 bits is
>another option that could massively clean up the code and invalidate all the design
>decisions you made back then.
Most of our code is 64bit these days - and the core code
has been 64bit since around 2000 (first on SPARC/Solaris,
then on x86_64 as soon as that became available).
I don't think it made much difference to any of the
design decisions though.
>No. On a conformant implementation you can build an entire program around the assumption
>that malloc() either returns NULL or the address of the start of a block
>of memory at least as large as requested, suitably aligned that it can be assigned
>to a pointer to any type of of object, and then used to access such an object or
>an array of such objects in the space allocated, and that is disjoint from all other
>objects, and you will not be relying on undefined behaviour at all.
Yes you are. You're relying on the undefined behavior of
how much memory malloc() will give you, on a particular
platform, with other processes running, before it craps
out and returns NULL. Which depends on the allocation
algorithm, the pattern of allocations, how much swap space
the machine is configured with, and what other processes
are running. In my trivial example, the answer is
that malloc() is going to crap out right away. But *no*
implementation actually defines the behavior in detail -
fragmentation is too complex, the OS environment is too
complex.
>>And back around 1999, when we were figuring out how to
>>get processes with up to 3.7GB of user-space heap on
>>32bit Solaris, the "undefined behavior" of malloc was
>>a real problem that we had to get round. It didn't
>>want to give you more than 2GB.
>
>I'm a little bit confused. I thought you were relying on particular undefined
>behaviour, not that the behaviour was unsuitable?
Some aspects of the undefined behavior were a pain that
we had to work around; other aspects of the undefined
behavior were helpful, and we started to rely on them.
>We actually came across a problem in the last couple of months where some data
>types not using our own explicit memory management (because it never gets
>large enough to warrant our attention) started failing to allocate memory only after
>24 hours of runtime or so, despite there being huge amounts of physical and virtual address space still available.
There you go, that's just the kind of "undefined behavior"
of malloc that I'm talking about.
>The problem with that is the overhead of copying data into different processes
>rules out a whole class of worthwhile operations that could be profitably threaded.
Maybe it does, maybe it doesn't. The dirty secret about
multi-core and multi-socket machines with caches is that
your threaded program is going to spend a whole lot of
time moving cache lines between the different caches.
It's not completely obvious that moving data explicitly
and in advance will end up costing you a lot more than
having it happen implicitly on demand. And the implicit
case is *definitely* going to be harder to understand
(because the data movement operations that take the time
are not apparent in the source code).
---------------------------
>Our current codebase started in 1995 using what was a particularly flaky and non-conformant
>compiler in those days (Visual C++) but even then sort() would have been a pretty
>safe portion to use. It's such a simple algorithm relying on such simple operations
>that if the compiler couldn't compile that right then you wouldn't trust it to compile anything.
Oh, I daresay the STL sort() was *correct* from the
beginning. But when it's a) mixed in with a lot of
other flaky stuff, and b) not particularly fast in
some cases, then the decision to use it is not so obvious.
>I tend to favour standard libraries where-ever possible on the basis that they
>have been more widely deployed and more widely tested than anything I am ever likely
>to write.
And that's a good argument for the *correctness* of such code.
But for uses which are performance-critical, I'm much
more skeptical about picking up "standard" stuff which
necessarily has to cater to the lowest common denominator,
rather than being optimized to the characteristics of your
own particular problem.
>Furthermore, with a sort routine it is obviously trivial to assert() a call to
>a simple function that does a single pass through the data to verify it is in the
>correct order. I wish all operations were that easy to check.
Yeah, that's one way a sort() can go wrong. The other way
is a bus error or segmentation violation ... or maybe a
pathological case that takes hours to run, or even an infinite loop. And if any of those happen,
you can bet it will be at the site of your largest
customer, right while you're negotiating a big order :-(
>of the language. However, ten years is also a long time, and it probably wouldn't
>hurt you to revisit your assumptions to see if there are better ways of doing things
>now -- not just because your tools should have matured a lot during that time, but
>also because being forced to remain single-threaded due to design decisions made
>back then is leaving increasingly large amounts of performance on the table.
Trouble is that "revisiting assumptions" in 1M+ lines of
code could take years. If something shows up in profiling
or other performance analysis, then you look at it, for
sure. But otherwise it's all going to stay just the way
it is.
As for the "single-threaded" issue, I'm actively working
on ways to exploit more parallelism. But my own opinion
is that a scheme based on multiple processes (each
with their own protected address space) is likely to
yield a product-quality solution much earlier than an
approach based on multiple threads in a single address
space (which is the more conventional approach). YMMV.
>could make your software faster just by buying a new PC. Porting it to 64 bits is
>another option that could massively clean up the code and invalidate all the design
>decisions you made back then.
Most of our code is 64bit these days - and the core code
has been 64bit since around 2000 (first on SPARC/Solaris,
then on x86_64 as soon as that became available).
I don't think it made much difference to any of the
design decisions though.
>No. On a conformant implementation you can build an entire program around the assumption
>that malloc() either returns NULL or the address of the start of a block
>of memory at least as large as requested, suitably aligned that it can be assigned
>to a pointer to any type of of object, and then used to access such an object or
>an array of such objects in the space allocated, and that is disjoint from all other
>objects, and you will not be relying on undefined behaviour at all.
Yes you are. You're relying on the undefined behavior of
how much memory malloc() will give you, on a particular
platform, with other processes running, before it craps
out and returns NULL. Which depends on the allocation
algorithm, the pattern of allocations, how much swap space
the machine is configured with, and what other processes
are running. In my trivial example, the answer is
that malloc() is going to crap out right away. But *no*
implementation actually defines the behavior in detail -
fragmentation is too complex, the OS environment is too
complex.
>>And back around 1999, when we were figuring out how to
>>get processes with up to 3.7GB of user-space heap on
>>32bit Solaris, the "undefined behavior" of malloc was
>>a real problem that we had to get round. It didn't
>>want to give you more than 2GB.
>
>I'm a little bit confused. I thought you were relying on particular undefined
>behaviour, not that the behaviour was unsuitable?
Some aspects of the undefined behavior were a pain that
we had to work around; other aspects of the undefined
behavior were helpful, and we started to rely on them.
>We actually came across a problem in the last couple of months where some data
>types not using our own explicit memory management (because it never gets
>large enough to warrant our attention) started failing to allocate memory only after
>24 hours of runtime or so, despite there being huge amounts of physical and virtual address space still available.
There you go, that's just the kind of "undefined behavior"
of malloc that I'm talking about.
>The problem with that is the overhead of copying data into different processes
>rules out a whole class of worthwhile operations that could be profitably threaded.
Maybe it does, maybe it doesn't. The dirty secret about
multi-core and multi-socket machines with caches is that
your threaded program is going to spend a whole lot of
time moving cache lines between the different caches.
It's not completely obvious that moving data explicitly
and in advance will end up costing you a lot more than
having it happen implicitly on demand. And the implicit
case is *definitely* going to be harder to understand
(because the data movement operations that take the time
are not apparent in the source code).
Topic | Posted By | Date |
---|---|---|
Hot Chips XXI Preview online | David Kanter | 2009/08/12 02:55 PM |
Hot Chips XXI Preview online | Groo | 2009/08/12 05:27 PM |
Hot Chips XXI Preview online | David Kanter | 2009/08/12 06:17 PM |
recent POWER7 info. from IBM | M.Isobe | 2009/08/16 02:04 AM |
Hot Chips XXI Preview online | slacker | 2009/08/12 08:11 PM |
Attending hot chips | David Kanter | 2009/08/12 08:53 PM |
Power7 vs. single threaded performance and licensing | Daniel Bizó | 2009/08/13 12:05 AM |
Power7 vs. single threaded performance and licensing | Wes Felter | 2009/08/13 11:17 AM |
Power7 vs. single threaded performance and licensing | anon | 2009/08/13 03:25 PM |
Power7 vs. single threaded performance and licensing | Linus Torvalds | 2009/08/13 03:48 PM |
How much IPC | E | 2009/08/14 01:16 AM |
How much IPC | hobold | 2009/08/14 03:03 AM |
How much IPC | a reader | 2009/08/15 10:26 AM |
How much IPC | hobold | 2009/08/15 10:58 AM |
How much IPC | Linus Torvalds | 2009/08/15 12:09 PM |
How much IPC | hobold | 2009/08/15 12:45 PM |
How much IPC | Euronymous | 2009/08/15 01:41 PM |
How much IPC | ? | 2009/08/16 01:13 AM |
How much IPC | Anonymous | 2009/08/16 02:07 AM |
How much IPC | ? | 2009/08/16 03:49 AM |
How much IPC | EduardoS | 2009/08/16 07:04 AM |
How much IPC | Anonymous | 2009/08/16 05:26 PM |
How much IPC | Linus Torvalds | 2009/08/16 07:49 AM |
How much IPC | ? | 2009/08/16 09:32 AM |
How much IPC | EduardoS | 2009/08/16 07:09 AM |
How much IPC | Linus Torvalds | 2009/08/16 08:12 AM |
How much IPC | a reader | 2009/08/16 11:41 AM |
How much IPC | Linus Torvalds | 2009/08/16 12:21 PM |
How much IPC | none | 2009/08/16 01:30 PM |
How much IPC | ? | 2009/08/16 11:32 PM |
How much IPC | ? | 2009/08/17 12:09 AM |
How much IPC | none | 2009/08/17 02:29 AM |
How much IPC | ? | 2009/08/17 05:25 AM |
Speculation and waste | David Kanter | 2009/08/17 10:03 AM |
Speculation and waste | ? | 2009/08/18 11:59 AM |
Speculation and waste | David Kanter | 2009/08/18 12:22 PM |
Speculation and waste | anon | 2009/08/19 02:52 AM |
Speculation and waste | TruePath | 2009/09/27 06:23 AM |
How much IPC | none | 2009/08/18 01:55 AM |
How much IPC | anon | 2009/08/18 02:27 AM |
How much IPC | anon | 2009/08/16 10:05 PM |
How much IPC | Linus Torvalds | 2009/08/17 10:17 AM |
How much IPC | _Arthur | 2009/08/17 03:23 PM |
How much IPC | David Kanter | 2009/08/17 03:38 PM |
How much IPC | Michael S | 2009/08/17 03:39 PM |
How much IPC | David Kanter | 2009/08/17 03:48 PM |
How much IPC | Michael S | 2009/08/17 05:03 PM |
How much IPC | _Arthur | 2009/08/17 05:33 PM |
How much IPC | Michael S | 2009/08/17 05:56 PM |
How much IPC | _Arthur | 2009/08/17 08:48 PM |
How much IPC | Michael S | 2009/08/18 03:07 AM |
limits of sorting | hobold | 2009/08/18 04:26 AM |
limits of sorting | Michael S | 2009/08/18 05:26 AM |
limits of sorting | _Arthur | 2009/08/18 06:03 AM |
limits of sorting | Richard Cownie | 2009/08/18 06:32 AM |
limits of sorting | Michael S | 2009/08/18 07:17 AM |
limits of sorting | Richard Cownie | 2009/08/18 08:22 AM |
limits of sorting | _Arthur | 2009/08/18 08:57 AM |
limits of sorting | Richard Cownie | 2009/08/18 09:30 AM |
limits of sorting | Richard Cownie | 2009/08/18 09:45 AM |
limits of sorting | Michael S | 2009/08/18 09:50 AM |
limits of sorting | Richard Cownie | 2009/08/18 10:09 AM |
limits of sorting | Michael S | 2009/08/18 10:33 AM |
limits of sorting | Richard Cownie | 2009/08/18 10:53 AM |
limits of sorting | Michael S | 2009/08/18 11:28 AM |
limits of sorting | Richard Cownie | 2009/08/18 12:01 PM |
limits of sorting | JasonB | 2009/08/18 06:40 PM |
limits of sorting | Richard Cownie | 2009/08/18 07:22 PM |
You work on EDA right Richard? | David Kanter | 2009/08/18 07:49 PM |
You work on EDA right Richard? | Richard Cownie | 2009/08/19 05:56 AM |
You work on EDA right Richard? | David Kanter | 2009/08/19 08:26 AM |
You work on EDA right Richard? | Richard Cownie | 2009/08/19 08:47 AM |
You work on EDA right Richard? | slacker | 2009/08/19 09:52 AM |
You work on EDA right Richard? | Richard Cownie | 2009/08/19 10:10 AM |
You work on EDA right Richard? | slacker | 2009/08/19 11:36 PM |
You work on EDA right Richard? | slacker | 2009/08/19 11:45 PM |
You work on EDA right Richard? | Richard Cownie | 2009/08/20 05:28 AM |
You work on EDA right Richard? | slacker | 2009/08/20 06:32 AM |
You work on EDA right Richard? | Aaron Spink | 2009/08/20 12:08 AM |
You work on EDA right Richard? | Rob Thorpe | 2009/08/20 08:31 AM |
You work on EDA right Richard? | David Kanter | 2009/08/20 09:58 AM |
You work on EDA right Richard? | Rob Thorpe | 2009/08/20 04:10 PM |
limits of sorting | rwessel | 2009/08/18 07:56 PM |
limits of sorting | JasonB | 2009/08/18 11:11 PM |
limits of sorting | JasonB | 2009/08/18 11:25 PM |
limits of sorting | Richard Cownie | 2009/08/19 06:32 AM |
limits of sorting | Rob Thorpe | 2009/08/19 07:12 AM |
limits of sorting | Richard Cownie | 2009/08/19 07:46 AM |
limits of sorting | JasonB | 2009/08/19 08:43 PM |
limits of sorting | Richard Cownie | 2009/08/20 07:47 AM |
limits of sorting | JasonB | 2009/08/20 08:20 PM |
limits of sorting | Richard Cownie | 2009/08/20 11:12 PM |
limits of sorting | JasonB | 2009/08/21 02:08 AM |
limits of sorting | Richard Cownie | 2009/08/21 05:15 AM |
limits of sorting | JasonB | 2009/08/22 06:24 PM |
limits of sorting | Richard Cownie | 2009/08/22 07:27 PM |
limits of sorting | Richard Cownie | 2009/08/22 08:39 PM |
limits of sorting | ? | 2009/08/23 05:07 AM |
limits of sorting | Richard Cownie | 2009/08/23 05:53 AM |
limits of sorting | anonymous | 2009/08/23 11:42 AM |
useful link, thanks | Richard Cownie | 2009/08/23 05:23 PM |
limits of sorting | ? | 2009/09/04 04:05 AM |
limits of sorting | JasonB | 2009/08/23 09:26 AM |
wacky C++ features | Richard Cownie | 2009/08/24 07:13 AM |
wacky C++ features | a reader | 2009/08/24 09:59 PM |
wacky C++ features | Richard Cownie | 2009/08/25 03:18 AM |
wacky C++ features | a reader | 2009/08/25 07:04 AM |
wacky C++ features | Potatoswatter | 2009/08/25 10:21 PM |
wacky C++ features | none | 2009/08/26 05:47 AM |
wacky C++ features | Richard Cownie | 2009/08/26 08:09 AM |
wacky C++ features | Potatoswatter | 2009/08/27 06:25 AM |
wacky C++ features | Andi Kleen | 2009/08/25 12:06 AM |
wacky C++ features | Richard Cownie | 2009/08/25 03:10 AM |
wacky C++ features | Octoploid | 2009/08/25 03:40 AM |
wacky C++ features | Richard Cownie | 2009/08/25 05:15 AM |
wacky C++ features | Andi Kleen | 2009/08/25 07:58 AM |
thanks | Richard Cownie | 2009/08/25 08:07 AM |
thanks | Andi Kleen | 2009/08/25 11:28 AM |
wacky C++ features | anon | 2009/08/25 03:34 PM |
wacky C++ features | Andi Kleen | 2009/08/25 10:25 PM |
wacky C++ features | JasonB | 2009/08/25 01:13 AM |
wacky C++ features | Richard Cownie | 2009/08/25 02:32 AM |
exception | a reader | 2009/08/25 07:32 AM |
exception | Richard Cownie | 2009/08/25 07:57 AM |
exception | Potatoswatter | 2009/08/25 08:30 AM |
wacky C++ features | JasonB | 2009/08/25 08:56 PM |
correction | JasonB | 2009/08/25 09:47 PM |
correction | c++ | 2009/08/26 09:53 AM |
correction | JasonB | 2009/08/26 07:48 PM |
(new char[10]) does not have array type (NT) | Potatoswatter | 2009/08/27 06:27 AM |
correction | Potatoswatter | 2009/08/27 07:52 AM |
correction | c++ | 2009/08/27 09:29 AM |
comeau bugs and gcc features | Potatoswatter | 2009/08/27 09:51 AM |
comeau bugs and gcc features | Potatoswatter | 2009/08/27 11:28 AM |
wacky C++ features | Richard Cownie | 2009/08/26 09:17 AM |
wacky C++ features | JasonB | 2009/08/26 07:46 PM |
wacky C++ features | Richard Cownie | 2009/08/27 09:41 AM |
wacky C++ features | JasonB | 2009/08/27 09:33 PM |
wacky C++ features | Richard Cownie | 2009/08/28 01:24 AM |
wacky C++ features | Richard Cownie | 2009/08/28 01:27 AM |
wacky C++ features | Michael S | 2009/08/28 06:05 AM |
wacky C++ features | EduardoS | 2009/08/28 06:45 AM |
wacky C++ features | Richard Cownie | 2009/08/28 07:50 AM |
wacky C++ features | JasonB | 2009/08/28 04:56 PM |
wacky C++ features | JasonB | 2009/08/28 05:55 PM |
wacky C++ features | Richard Cownie | 2009/08/28 07:44 PM |
wacky C++ features | Konrad Schwarz | 2009/09/07 04:24 AM |
wacky C++ features | EduardoS | 2009/08/26 03:22 PM |
wacky C++ features | JasonB | 2009/08/26 06:47 PM |
wacky C++ features | Jukka Larja | 2009/08/27 12:03 AM |
wacky C++ features | JasonB | 2009/08/27 01:17 AM |
wacky C++ features | EduardoS | 2009/08/27 03:26 PM |
wacky C++ features | JasonB | 2009/08/27 06:31 PM |
wacky C++ features | EduardoS | 2009/08/28 03:25 PM |
wacky C++ features | JasonB | 2009/08/28 06:20 PM |
wacky C++ features | JasonB | 2009/08/27 09:56 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/21 07:33 AM |
Windows vs Unix/Linux culture | Michael S | 2009/08/21 08:07 AM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/21 08:33 AM |
Windows vs Unix/Linux culture | Paul | 2009/08/22 04:12 AM |
Windows vs Unix/Linux culture | anon | 2009/08/21 11:18 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/21 11:45 PM |
Windows vs Unix/Linux culture | anon | 2009/08/22 12:48 AM |
Windows vs Unix/Linux culture | Paul | 2009/08/22 04:25 AM |
Windows vs Unix/Linux culture | Gian-Carlo Pascutto | 2009/08/22 07:02 AM |
Windows vs Unix/Linux culture | Paul | 2009/08/22 08:13 AM |
Windows vs Unix/Linux culture | rwessel | 2009/08/24 03:09 PM |
Windows vs Unix/Linux culture | JasonB | 2009/08/22 05:28 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/22 06:22 PM |
Windows vs Unix/Linux culture | JasonB | 2009/08/22 06:52 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/22 07:47 PM |
Encapsulation | Konrad Schwarz | 2009/09/03 04:49 AM |
Encapsulation | anon | 2009/09/03 10:05 AM |
Encapsulation | ? | 2009/09/03 11:38 AM |
Encapsulation | Andi Kleen | 2009/09/04 01:41 AM |
Encapsulation | anon | 2009/09/04 07:24 AM |
Encapsulation | Richard Cownie | 2009/09/04 07:34 AM |
Encapsulation | Konrad Schwarz | 2009/09/07 03:28 AM |
Encapsulation | Richard Cownie | 2009/09/07 04:04 PM |
Windows vs Unix/Linux culture | ? | 2009/09/03 11:51 AM |
Windows vs Unix/Linux culture | no thanks | 2009/08/23 10:36 AM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/23 04:23 PM |
Windows vs Unix/Linux culture | JasonB | 2009/08/23 08:31 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/24 12:10 AM |
Windows vs Unix/Linux culture | Jukka Larja | 2009/08/24 10:13 PM |
Windows vs Unix/Linux culture | JasonB | 2009/08/24 11:35 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/25 03:04 AM |
Windows vs Unix/Linux culture | JasonB | 2009/08/25 11:48 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/26 08:28 AM |
Windows vs Unix/Linux culture | JasonB | 2009/08/26 10:31 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/26 08:43 AM |
Windows vs Unix/Linux culture | anon | 2009/08/26 01:48 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/26 03:28 PM |
Windows vs Unix/Linux culture | JasonB | 2009/08/26 08:06 PM |
Windows vs Unix/Linux culture | Richard Cownie | 2009/08/27 03:44 AM |
Windows vs Unix/Linux culture | Rob Thorpe | 2009/08/27 05:51 AM |
Windows vs Unix/Linux culture | JasonB | 2009/08/23 09:07 PM |
Windows vs Unix/Linux culture | no thanks | 2009/08/23 09:44 PM |
Windows vs Unix/Linux culture | JasonB | 2009/08/24 12:34 AM |
Windows vs Unix/Linux culture | anon | 2009/08/23 09:46 PM |
limits of sorting | Richard Cownie | 2009/08/20 07:59 AM |
limits of sorting | Richard Cownie | 2009/08/20 09:27 AM |
limits of sorting | JasonB | 2009/08/20 08:55 PM |
limits of sorting | Richard Cownie | 2009/08/20 11:22 PM |
limits of sorting | JasonB | 2009/08/21 12:15 AM |
limits of sorting | Richard Cownie | 2009/08/21 04:47 AM |
limits of sorting | ? | 2009/08/20 11:42 PM |
limits of sorting | Richard Cownie | 2009/08/21 07:51 AM |
limits of sorting | Michael S | 2009/08/21 08:11 AM |
limits of sorting | Richard Cownie | 2009/08/21 08:38 AM |
limits of sorting | dmsc | 2009/08/20 07:56 PM |
limits of sorting | Richard Cownie | 2009/08/20 08:20 PM |
limits of sorting | Rob Thorpe | 2009/08/20 08:09 AM |
limits of sorting | Aaron Spink | 2009/08/20 12:19 AM |
limits of sorting | JasonB | 2009/08/20 01:55 AM |
limits of sorting | Michael S | 2009/08/18 07:12 AM |
limits of sorting | hobold | 2009/08/18 07:55 AM |
limits of sorting | rwessel | 2009/09/08 02:52 PM |
maximal theoretical sorting efficiency | Emil | 2009/09/08 07:06 PM |
maximal theoretical sorting efficiency | rwessel | 2009/09/08 10:04 PM |
maximal theoretical sorting efficiency | hobold | 2009/09/09 04:56 AM |
maximal theoretical sorting efficiency | Richard Cownie | 2009/09/09 09:10 AM |
maximal theoretical sorting efficiency | hobold | 2009/09/10 05:39 AM |
maximal theoretical sorting efficiency | Richard Cownie | 2009/09/10 08:05 AM |
maximal theoretical sorting efficiency | Potatoswatter | 2009/09/10 01:23 PM |
maximal theoretical sorting efficiency | dmsc | 2009/09/13 08:04 AM |
limits of sorting | Potatoswatter is back! | 2009/08/21 06:07 PM |
indeed it doesn't succeed in partitioning at all, but you get the idea ;) (NT) | Potatoswatter is back! | 2009/08/21 06:12 PM |
indeed it doesn't succeed in partitioning at all, but you get the idea ;) (NT) | Jouni Osmala | 2009/08/22 01:01 AM |
limits of sorting | hobold | 2009/08/22 07:25 AM |
limits of sorting | Potatoswatter | 2009/08/22 08:45 AM |
limits of sorting | David Kanter | 2009/08/22 10:16 AM |
limits of sorting | Jouni Osmala | 2009/08/22 12:01 PM |
Oops that was counting sort not bucket sort ;( | Jouni Osmala | 2009/08/22 12:07 PM |
close enough for my purposes | hobold | 2009/08/22 02:15 PM |
select vs. cmove | hobold | 2009/08/22 02:25 PM |
How much IPC | Gian-Carlo Pascutto | 2009/08/18 03:25 AM |
How much IPC | Vincent Diepeveen | 2009/08/19 06:46 AM |
How much IPC | _Arthur | 2009/08/19 09:32 AM |
How much IPC | hobold | 2009/08/18 04:17 AM |
How much IPC | Michael S | 2009/08/18 05:33 AM |
How much IPC | hobold | 2009/08/18 07:35 AM |
How much IPC | ? | 2009/08/18 12:20 PM |
How much IPC | _Arthur | 2009/08/18 12:33 PM |
Nit picking | David Kanter | 2009/08/18 02:17 PM |
Nit picking | _Arthur | 2009/08/18 02:37 PM |
Nit picking | Michael S | 2009/08/18 03:02 PM |
Nit picking | S. Rao | 2009/08/18 05:02 PM |
Nit picking | anon | 2009/08/19 03:03 AM |
Nit picking | Michael S | 2009/08/18 02:53 PM |
Nit picking | JasonB | 2009/08/18 07:16 PM |
How much IPC | ? | 2009/08/18 02:37 PM |
How much IPC | _Arthur | 2009/08/18 04:23 PM |
How much IPC | Matt Sayler | 2009/08/18 06:09 PM |
How much IPC | ? | 2009/08/18 11:59 PM |
nick's testcase | a reader | 2009/08/17 05:47 PM |
How much IPC | TruePath | 2009/09/27 10:00 AM |
Explicit dependency chains | David Kanter | 2009/09/30 07:56 PM |
How much IPC | TruePath | 2009/09/27 10:00 AM |
How much IPC | hobold | 2009/08/17 06:38 AM |
How much IPC | anon | 2009/08/16 09:59 PM |
Speeing Up Single Threads | TruePath | 2009/09/27 08:58 AM |
How much IPC | anon | 2009/08/15 08:01 PM |
How much IPC | EduardoS | 2009/08/16 07:06 AM |
How much IPC | sJ | 2009/08/16 09:48 PM |
Power7 vs. single threaded performance and licensing | anon | 2009/08/14 03:26 PM |
Power7 vs. single threaded performance and licensing | Linus Torvalds | 2009/08/14 04:04 PM |
Power7 vs. single threaded performance and licensing | Jonathan Kang | 2009/08/21 03:43 PM |
Power7 vs. single threaded performance and licensing | Linus Torvalds | 2009/08/21 04:08 PM |
Power7 vs. single threaded performance and licensing | Linus Torvalds | 2009/08/21 04:33 PM |
Power7 vs. single threaded performance and licensing | Jonathan Kang | 2009/08/22 08:57 AM |
Power7 vs. single threaded performance and licensing | Jukka Larja | 2009/08/22 11:04 PM |
Power7 vs. single threaded performance and licensing | Jonathan Kang | 2009/08/25 12:33 PM |
Power7 vs. single threaded performance and licensing | ? | 2009/08/22 12:51 AM |
Power7 vs. single threaded performance and licensing | anon | 2009/08/22 10:56 AM |
Power7 vs. single threaded performance and licensing | Linus Torvalds | 2009/08/22 11:38 AM |
Power7 vs. single threaded performance and licensing | ? | 2009/08/23 04:05 AM |
Power7 vs. single threaded performance and licensing | EduardoS | 2009/08/23 04:28 AM |
Programming Larrabee | ? | 2009/08/23 06:48 AM |
Programming Larrabee | EduardoS | 2009/08/23 07:41 AM |
Programming Larrabee | anon | 2009/08/23 08:29 AM |
Programming Larrabee | Potatoswatter | 2009/08/23 07:47 AM |
Programming Larrabee | Richard Cownie | 2009/08/23 09:11 AM |
Programming Larrabee | Potatoswatter | 2009/08/24 12:49 AM |
Programming Larrabee | ? | 2009/08/23 09:59 AM |
Programming Larrabee | Potatoswatter | 2009/08/24 12:44 AM |
Programming Larrabee | hobold | 2009/08/24 06:41 AM |
Programming Larrabee | none | 2009/08/24 08:15 AM |
Programming Larrabee | Richard Cownie | 2009/08/24 08:33 AM |
Programming Larrabee | Jukka Larja | 2009/08/24 10:30 PM |
Programming Larrabee | none | 2009/08/25 02:53 AM |
Programming Larrabee | mpx | 2009/08/25 09:16 AM |
Power7 vs. single threaded performance and licensing | Joe | 2009/08/24 09:38 AM |
Power7 vs. single threaded performance and licensing | Gabriele Svelto | 2009/08/14 04:35 AM |
Power7 vs. single threaded performance and licensing | anon | 2009/08/14 09:18 AM |
Power7 vs. single threaded performance and licensing | EduardoS | 2009/08/14 05:34 PM |
Power7 vs. single threaded performance and licensing | anon | 2009/08/15 07:30 AM |
Power7 vs. single threaded performance and licensing | anon | 2009/08/15 08:23 AM |
improving Netburst | AM | 2009/08/15 02:36 AM |
improving Netburst | anon | 2009/08/15 08:10 AM |
improving Netburst | Euronymous | 2009/08/15 09:35 AM |
improving Netburst | Michael S | 2009/08/15 02:18 PM |
Power7 vs. single threaded performance and licensing | Jonathan Kang | 2009/08/21 04:10 PM |
Power7 vs. single threaded performance and licensing | anon | 2009/08/22 10:46 AM |
Power7 vs. single threaded performance and licensing | Jonathan Kang | 2009/08/25 10:39 AM |
Power7 vs. single threaded performance and licensing | slacker | 2009/08/26 05:50 AM |
Power7 vs. single threaded performance and licensing | Jonathan Kang | 2009/08/26 09:12 AM |
Power7 vs. single threaded performance and licensing | Jonathan Kang | 2009/08/26 09:45 AM |
Power7 vs. single threaded performance and licensing | someone | 2009/08/26 11:29 AM |
Power7 vs. single threaded performance and licensing | David Kanter | 2009/08/26 11:47 AM |
Not necessarily | Daniel Bizó | 2009/08/14 03:53 AM |
new POWER7 info .. | Thu Nguyen | 2009/08/25 04:05 AM |
new POWER7 info .. | someone | 2009/08/25 06:47 AM |
new POWER7 info .. | hobold | 2009/08/25 07:50 AM |
new POWER7 info .. | G Webb | 2009/08/26 12:49 AM |
new POWER7 info .. | mpx | 2009/08/25 08:36 AM |
new POWER7 info .. | someone | 2009/08/25 09:16 AM |
new POWER7 info .. | Jesper Frimann | 2009/08/27 09:18 AM |
new POWER7 info .. | Linus Torvalds | 2009/08/27 11:53 AM |
new POWER7 info .. | someone | 2009/08/27 01:00 PM |
new POWER7 info .. | a reader | 2009/08/27 04:21 PM |
new POWER7 info .. | David Kanter | 2009/08/27 09:32 PM |
new POWER7 info .. | a reader | 2009/08/28 08:45 AM |
new POWER7 info .. | hobold | 2009/08/28 05:00 AM |
new POWER7 info .. | someone | 2009/08/28 06:51 AM |
new POWER7 info .. | hobold | 2009/08/28 07:44 AM |
new POWER7 info .. | someone | 2009/08/28 08:10 AM |
Non Autopar submissions for Nehalem | IlleglWpns | 2009/08/28 10:41 AM |
Non Autopar submissions for Nehalem | David Kanter | 2009/08/28 11:07 AM |
Non Autopar submissions for Nehalem | someone | 2009/08/28 12:00 PM |
new POWER7 info .. | mas | 2009/08/26 12:25 AM |
An EV8 lite? (NT) | anon | 2009/08/26 09:21 AM |
An EV8 lite? => Piranha? | M. | 2009/08/30 04:54 AM |
new POWER7 info .. | Mark Roulo | 2009/08/27 06:51 AM |
new POWER7 info .. | someone | 2009/08/27 07:03 AM |
new POWER7 info .. | a reader | 2009/08/27 09:55 AM |
new POWER7 info .. | someone | 2009/08/27 11:58 AM |
new POWER7 info .. | a reader | 2009/08/27 04:11 PM |
new POWER7 info .. | Gabriele Svelto | 2009/08/28 12:17 AM |
new POWER7 info .. | someone | 2009/08/28 05:27 AM |
new POWER7 info .. | a reader | 2009/08/28 09:07 AM |
OOOE for low power | David Kanter | 2009/08/28 11:15 AM |
OOOE for low power | someone | 2009/08/28 11:39 AM |
OOOE for low power | David Kanter | 2009/08/28 01:55 PM |
OOOE for low power | Mark Roulo | 2009/08/28 03:16 PM |
OOOE for low power | Mark Roulo | 2009/08/28 03:44 PM |
Atom uarch | David Kanter | 2009/08/28 08:19 PM |
OOOE for low power | David Kanter | 2009/08/28 08:07 PM |
OOOE for low power | someone | 2009/08/28 04:18 PM |
OOOE for low power | David Kanter | 2009/08/29 01:55 AM |
OOOE for low power | someone | 2009/08/29 07:21 AM |
OOOE for low power | a reader | 2009/08/29 09:14 AM |
OOOE for low power | someone | 2009/08/29 09:56 AM |
OOOE for low power | David Kanter | 2009/08/29 10:08 AM |
OOOE for low power | Michael S | 2009/08/29 11:27 AM |
OOOE for low power | a reader | 2009/08/29 04:50 PM |
OOOE for low power | anonymous | 2009/08/29 07:17 PM |
OOOE for low power | Michael S | 2009/08/30 12:07 AM |
OOOE for low power | Jonathan Kang | 2009/09/01 05:44 AM |
OOOE for low power | Michael S | 2009/09/01 04:21 PM |
OOOE for low power | Mark Roulo | 2009/09/01 05:53 PM |
OOOE for low power | Wilco | 2009/09/02 02:27 AM |
OOOE for low power | Mark Roulo | 2009/09/02 08:46 AM |
OOOE for low power | Wilco | 2009/09/02 04:52 PM |
Define "emulate" (NT) | Michael S | 2009/09/02 11:44 PM |
Define "emulate" | Wilco | 2009/09/03 12:33 AM |
Define "emulate" | none | 2009/09/03 04:46 AM |
Define "emulate" | Adrian | 2009/09/03 10:45 AM |
Define "emulate" | Wilco | 2009/09/03 02:20 PM |
Define "emulate" | none | 2009/09/03 10:41 PM |
Define "emulate" | Wilco | 2009/09/04 03:30 AM |
low power ARM chips | Michael S | 2009/10/31 02:32 PM |
low power ARM chips | Gabriele Svelto | 2009/10/31 04:05 PM |
low power ARM chips | Michael S | 2009/10/31 04:45 PM |
low power ARM chips | t | 2009/10/31 05:21 PM |
OOOE for low power | David Kanter | 2009/08/29 10:07 AM |
OOOE for low power | someone | 2009/08/29 12:40 PM |
OOOE for low power | a reader | 2009/08/29 05:03 PM |
OOOE for low power | anonymous | 2009/08/29 07:13 PM |
OOOE for low power | someone | 2009/08/30 07:35 AM |
OOOE for low power | David Kanter | 2009/08/30 02:32 PM |
OOOE for low power | Matt Sayler | 2009/08/31 01:38 PM |
OOOE for low power | David Kanter | 2009/08/30 12:07 PM |
OOOE for low power | Michael S | 2009/08/29 11:44 AM |
TTM | Michael S | 2009/08/29 12:24 PM |
TTM | Foo_ | 2009/08/29 01:40 PM |
TTM | Michael S | 2009/08/29 02:10 PM |
TTM | anon | 2009/08/29 07:33 PM |
TTM | Jukka Larja | 2009/08/29 09:49 PM |
TTM | anon | 2009/08/30 06:07 AM |
TTM | Jukka Larja | 2009/08/30 09:31 PM |
Area, power and Atom | David Kanter | 2009/08/30 10:36 PM |
Area, power and Atom | Michael S | 2009/08/31 12:18 AM |
Area, power and Atom | a reader | 2009/08/31 08:44 AM |
Area, power and Atom | Michael S | 2009/08/31 12:19 PM |
Area, power and Atom | a reader | 2009/08/31 02:53 PM |
Area, power and Atom | anonymous | 2009/08/31 04:17 PM |
Area, power and Atom | Gabriele Svelto | 2009/08/31 03:41 PM |
64-bit disabled Atoms | Foo_ | 2009/09/02 04:38 AM |
64-bit disabled Atoms | Robert David Graham | 2009/09/02 12:56 PM |
64-bit disabled Atoms | anon | 2009/09/02 02:14 PM |
64-bit disabled Atoms | anonymous | 2009/09/02 04:30 PM |
TTM | Michael S | 2009/08/30 11:49 PM |
TTM | Jukka Larja | 2009/08/31 11:23 PM |
TTM | Paul | 2009/08/30 06:38 AM |
TTM | Paul | 2009/08/30 06:40 AM |
TTM | Mark Roulo | 2009/08/30 09:50 AM |
TTM | Paul | 2009/08/30 09:54 AM |
TTM | Mark Roulo | 2009/08/30 10:16 AM |
TTM | Foo_ | 2009/09/02 04:31 AM |
OOOE for low power | Rob Thorpe | 2009/08/30 09:19 AM |
OOOE for low power | Michael S | 2009/08/29 11:16 AM |
OOOE for low power | Jukka Larja | 2009/08/29 09:40 PM |
OOOE for low power | Michael S | 2009/08/30 12:04 AM |
OOOE and cache/mem sizes | Richard Cownie | 2009/08/28 05:30 PM |
OOOE and cache/mem sizes | Linus Torvalds | 2009/08/31 10:53 PM |
OOOE and cache/mem sizes | Richard Cownie | 2009/09/01 04:15 AM |
OOOE and pipe length etc. | AM | 2009/09/01 08:35 AM |
OOOE and pipe length etc. | Jouni Osmala | 2009/09/01 08:57 AM |
OOOE and clock rate | AM | 2009/09/02 01:34 AM |
OOOE and clock rate | Jouni Osmala | 2009/09/02 05:35 AM |
OOOE and clock rate | Martin Høyer Kristiansen | 2009/09/02 06:19 AM |
OOOE and clock rate | anon | 2009/09/02 09:43 PM |
OOOE and clock rate | AM | 2009/09/03 02:52 AM |
OOOE and clock rate | Jouni Osmala | 2009/09/03 07:34 AM |
OOOE impacts | AM | 2009/09/04 02:04 AM |
OOOE impacts | David Kanter | 2009/09/04 10:12 AM |
OOOE impacts | Jouni Osmala | 2009/09/06 12:16 PM |
OOOE impacts | AM | 2009/09/07 03:47 AM |
OOOE impacts | Martin Høyer Kristiansen | 2009/09/07 06:03 AM |
Does IBM lie about PPC603 being OoO chip? | AM | 2009/09/08 03:13 AM |
No, but... | Michael S | 2009/09/08 07:05 AM |
No, but... | hobold | 2009/09/09 05:09 AM |
OOOE impacts | JS | 2009/09/07 06:34 AM |
Are Sandpile and others wrong about 0.28 um? | AM | 2009/09/08 03:12 AM |
OOOE impacts | someone | 2009/09/08 06:43 AM |
OOOE impacts | Jouni Osmala | 2009/09/07 07:48 AM |
OOOE costs | David Kanter | 2009/09/07 12:07 PM |
OOOE impacts | AM | 2009/09/08 03:11 AM |
OOOE impacts | Jouni Osmala | 2009/09/10 01:53 AM |
OOOE impacts | AM | 2009/09/11 04:35 AM |
OOOE impacts | Jouni Osmala | 2009/09/11 08:38 AM |
OOOE impacts | AM | 2009/09/12 05:06 AM |
OOOE impacts | Jouni Osmala | 2009/09/12 11:36 PM |
OOOE impacts | AM | 2009/09/14 04:39 AM |
OOOE impacts | Jouni Osmala | 2009/09/14 06:18 AM |
if-ex distance | AM | 2009/09/15 05:16 AM |
small addendum | AM | 2009/09/19 03:54 AM |
small addendum | Jouni Osmala | 2009/09/19 09:51 PM |
small addendum | AM | 2009/09/20 06:54 AM |
small addendum | Jouni Osmala | 2009/09/20 01:16 PM |
small addendum | Thiago Kurovski | 2009/09/20 04:51 PM |
small addendum | Jouni Osmala | 2009/09/20 09:21 PM |
small addendum | Thiago Kurovski | 2009/09/21 06:59 AM |
small addendum | AM | 2009/09/21 03:14 AM |
small addendum | Jukka Larja | 2009/09/21 10:21 PM |
small addendum | AM | 2009/09/22 03:01 AM |
small addendum | Jukka Larja | 2009/09/22 11:31 PM |
small addendum | AM | 2009/09/23 08:35 AM |
small addendum | Jukka Larja | 2009/09/23 10:31 PM |
small addendum | AM | 2009/09/24 12:13 AM |
OT metadiscussion | Jukka Larja | 2009/09/24 09:39 PM |
OT metadiscussion | AM | 2009/09/25 05:18 AM |
Back to bits | Michael S | 2009/09/25 07:14 AM |
Back to bits | Thiago Kurovski | 2009/09/25 11:24 AM |
Back to bits | Wilco | 2009/09/25 03:18 PM |
Back to bits | Thiago Kurovski | 2009/09/26 09:12 AM |
Back to bits | Michael S | 2009/09/26 08:54 AM |
Back to bits | Thiago Kurovski | 2009/09/26 09:05 AM |
Back to bits | Michael S | 2009/09/26 09:16 AM |
Agree, with very minor change. | Jouni Osmala | 2009/09/25 09:37 PM |
Back to bits | AM | 2009/09/26 06:16 AM |
Back to bits | Michael S | 2009/09/26 09:13 AM |
OT metadiscussion | David Kanter | 2009/09/25 12:23 PM |
OT metadiscussion | AM | 2009/09/26 05:55 AM |
OT metadiscussion | Jukka Larja | 2009/09/25 11:33 PM |
OT metadiscussion | AM | 2009/09/26 05:50 AM |
OT metadiscussion | Jukka Larja | 2009/09/27 02:16 AM |
OT metadiscussion | Michael S | 2009/09/27 04:58 AM |
OT metadiscussion | AM | 2009/09/28 04:07 AM |
OT metadiscussion | AM | 2009/09/28 03:43 AM |
OT metadiscussion | Jukka Larja | 2009/09/29 12:45 AM |
OT metadiscussion | AM | 2009/09/30 03:13 AM |
OT metadiscussion | Jukka Larja | 2009/10/01 01:34 AM |
OT metadiscussion | AM | 2009/10/01 04:05 AM |
OT metadiscussion | Jukka Larja | 2009/10/02 12:38 AM |
OT metadiscussion | AM | 2009/10/03 07:19 AM |
OT metadiscussion | Jukka Larja | 2009/10/04 03:38 AM |
OT metadiscussion | AM | 2009/10/04 08:27 AM |
OT metadiscussion | Jukka Larja | 2009/10/04 11:48 PM |
OT metadiscussion | AM | 2009/10/05 07:13 AM |
About teaching | Jukka Larja | 2009/10/05 11:36 PM |
About teaching | AM | 2009/10/06 04:37 AM |
About teaching | Jukka Larja | 2009/10/07 03:15 AM |
About teaching | anon | 2009/10/07 12:39 PM |
About teaching | AM | 2009/10/08 03:11 AM |
About teaching | Jukka Larja | 2009/10/09 04:10 AM |
About teaching | AM | 2009/10/09 05:40 AM |
About teaching | Jukka Larja | 2009/10/09 09:02 PM |
About teaching | AM | 2009/10/09 11:24 PM |
About teaching | Jukka Larja | 2009/10/10 10:50 PM |
About teaching | AM | 2009/10/12 02:02 AM |
About teaching | Jukka Larja | 2009/10/12 10:51 PM |
About teaching | AM | 2009/10/13 04:06 AM |
About teaching | Jukka Larja | 2009/10/13 11:33 PM |
About teaching | AM | 2009/10/14 03:36 AM |
About teaching | Jukka Larja | 2009/10/14 08:19 PM |
About teaching | AM | 2009/10/15 04:22 AM |
About teaching | Salvatore De Dominicis | 2009/10/12 02:23 AM |
About teaching | Dean Kent | 2009/10/12 12:25 PM |
About teaching | Salvatore De Dominicis | 2009/10/13 02:11 AM |
OT metadiscussion | Seni | 2009/09/26 06:26 AM |
OT metadiscussion | Wilco | 2009/09/26 08:08 AM |
OT metadiscussion | Jukka Larja | 2009/09/27 02:18 AM |
OT metadiscussion | Michael S | 2009/09/27 05:12 AM |
small addendum | Jouni Osmala | 2009/09/24 10:04 PM |
small addendum | AM | 2009/09/25 05:04 AM |
extra stage in EV6 | AM | 2009/09/26 06:29 AM |
PPC603 does OoOE | hobold | 2009/09/08 05:40 AM |
OOOE impacts | someone | 2009/09/08 05:39 AM |
EV6 | AM | 2009/09/09 04:33 AM |
OOOE and clock rate | Seni | 2009/09/02 09:11 AM |
OOOE and clock rate | Linus Torvalds | 2009/09/02 06:48 PM |
OOOE and clock rate | anon | 2009/09/02 11:55 PM |
OOOE and clock rate | Wilco | 2009/09/03 12:44 AM |
OOOE and clock rate | Jouni Osmala | 2009/09/03 01:02 AM |
OOOE and Itanium | AM | 2009/09/03 01:27 AM |
OOOE and clock rate | Martin Høyer Kristiansen | 2009/09/03 03:41 AM |
OOOE and clock rate | anon | 2009/09/03 01:12 AM |
OOOE and clock rate | Wilco | 2009/09/03 02:10 AM |
POWER6 skewed pipeline | Paul A. Clayton | 2009/09/03 11:22 AM |
POWER6 skewed pipeline | Anon4 | 2009/09/03 07:00 PM |
OOOE and clock rate | Mr. Camel | 2009/09/03 03:40 AM |
OOOE and clock rate | Richard Cownie | 2009/09/03 06:42 AM |
OOOE and pipe length etc. | Richard Cownie | 2009/09/01 09:01 AM |
OOOE and pipe length etc. | AM | 2009/09/02 01:32 AM |
OOOE and pipe length etc. | Richard Cownie | 2009/09/02 07:49 AM |
LRB choice of P54 | AM | 2009/09/03 01:40 AM |
LRB choice of P54 | Gian-Carlo Pascutto | 2009/09/03 01:45 AM |
LRB choice of P54 | AM | 2009/09/03 03:18 AM |
LRB choice of P54 | Gian-Carlo Pascutto | 2009/09/03 03:55 AM |
LRB choice of P54 | AM | 2009/09/03 04:28 AM |
LRB choice of P54 | Gian-Carlo Pascutto | 2009/09/03 05:29 AM |
Amount of cache per core matters,and mem bandwith too (NT) | Jouni Osmala | 2009/09/03 07:44 AM |
LRB choice of P54 | rwessel | 2009/09/03 02:31 PM |
LRB choice of P54 | AM | 2009/09/04 02:24 AM |
LRB choice of P54 | anon | 2009/09/03 06:40 AM |
LRB choice of P54 | a reader | 2009/09/03 09:20 AM |
LRB choice of P54 | anon | 2009/09/03 05:57 PM |
LRB choice of P54 | Jonathan Kang | 2009/09/03 02:30 PM |
LRB choice of P54 | David Kanter | 2009/09/03 04:38 PM |
LRB choice of P54 | Jonathan Kang | 2009/09/04 08:16 AM |
LRB choice of P54 | anon | 2009/09/03 06:07 PM |
LRB choice of P54 | AM | 2009/09/04 02:20 AM |
LRB choice of P54 | Jonathan Kang | 2009/09/04 08:13 AM |
LRB choice of P54 | Dan Downs | 2009/09/04 08:38 AM |
LRB choice of P54 | Dan Downs | 2009/09/05 04:36 AM |
LRB choice of P54 | Anon | 2009/09/05 02:44 PM |
LRB choice of P54 | AM | 2009/09/05 12:12 AM |
LRB choice of P54 | AM | 2009/09/04 02:18 AM |
LRB choice of P54 | anon | 2009/09/04 08:18 PM |
LRB choice of P54 | AM | 2009/09/04 11:53 PM |
LRB choice of P54 | anon | 2009/09/05 04:06 AM |
LRB choice of P54 | AM | 2009/09/05 09:14 AM |
LRB choice of P54 - Layout? | Anonymous | 2009/09/03 02:40 PM |
LRB choice of P54 - Layout? | anonymous | 2009/09/03 03:54 PM |
LRB choice of P54 | Jukka Larja | 2009/09/03 09:58 PM |
LRB choice of P54 | mpx | 2009/09/04 04:07 AM |
LRB choice of P54 | anon | 2009/09/03 02:02 AM |
OOOE and pipe length etc. | Gian-Carlo Pascutto | 2009/09/03 01:40 AM |
Larrabee: Pentium vs 486 vs 386 | Mark Roulo | 2009/09/03 04:26 PM |
Larrabee: Pentium vs 486 vs 386 | Michael S | 2009/09/03 05:14 PM |
Larrabee: Pentium vs 486 vs 386 | Mark Roulo | 2009/09/04 10:05 AM |
Larrabee: Pentium vs 486 vs 386 | Jonathan Kang | 2009/09/04 10:59 AM |
Larrabee: Pentium vs 486 vs 386 | Michael S | 2009/09/05 09:58 AM |
Larrabee: Pentium vs 486 vs 386 | James | 2009/09/07 03:15 AM |
Larrabee: Pentium vs 486 vs 386 | Mark Roulo | 2009/09/07 07:44 PM |
OOOE and pipe length etc. | Michael S | 2009/09/03 05:42 PM |
LRB core | AM | 2009/09/04 02:09 AM |
LRB core | Michael S | 2009/09/04 05:07 AM |
LRB core | anon | 2009/09/04 08:27 PM |
LRB core | Michael S | 2009/09/05 10:12 AM |
LRB core | anon | 2009/09/05 11:03 PM |
reasons for split I/D L1 caches | Michael S | 2009/09/06 04:10 AM |
reasons for split I/D L1 caches | anon | 2009/09/06 06:32 AM |
reasons for split I/D L1 caches | ? | 2009/09/06 10:35 AM |
reasons for split I/D L1 caches | megol | 2009/09/06 03:39 PM |
reasons for split I/D L1 caches | ? | 2009/09/07 04:20 AM |
reasons for split I/D L1 caches | anon | 2009/09/07 06:25 AM |
cache hinting | ? | 2009/09/07 07:10 AM |
cache hinting | anon | 2009/09/07 07:35 AM |
cache hinting | ? | 2009/09/07 09:10 AM |
cache hinting | anon | 2009/09/07 09:49 AM |
cache hinting | ? | 2009/09/07 10:37 AM |
Split and unified caches | David Kanter | 2009/09/06 01:38 PM |
Split and unified caches | anon | 2009/09/06 11:15 PM |
Split and unified caches | Michael S | 2009/09/07 12:40 AM |
Split and unified caches | anon | 2009/09/07 02:24 AM |
Split and unified caches | David Kanter | 2009/09/07 12:51 AM |
Split and unified caches | anon | 2009/09/07 02:13 AM |
LRB core | AM | 2009/09/05 12:08 AM |
LRB core | Linus Torvalds | 2009/09/05 10:47 AM |
LRB core | David Kanter | 2009/09/04 01:23 PM |
LRB core | Anon | 2009/09/04 06:32 PM |
LRB core | David Kanter | 2009/09/04 10:15 PM |
LRB core | Michael S | 2009/09/05 10:21 AM |
OOOE and cache/mem sizes | a reader | 2009/09/01 09:19 AM |
OOOE and cache/mem sizes | Richard Cownie | 2009/09/01 09:43 AM |
snapdraon? | Michael S | 2009/08/28 06:10 AM |
snapdraon? | a reader | 2009/08/28 08:51 AM |
Thanks (NT) | Michael S | 2009/08/29 12:53 PM |
snapdraon? | Paul | 2009/08/28 01:12 PM |
new POWER7 info .. | EduardoS | 2009/08/27 03:41 PM |
new POWER7 info .. | Jesper Frimann | 2009/08/28 05:03 AM |
Single threaded performance | David Kanter | 2009/08/28 10:52 AM |
Hot Chips XXI Preview online | hobold | 2009/08/13 07:30 AM |