Article: Hot Chips XXI Preview
By: JasonB (no.delete@this.spam.com), August 22, 2009 6:24 pm
Room: Moderated Discussions
Richard Cownie (tich@pobox.com) on 8/21/09 wrote:
---------------------------
>It depends what you mean by "standard library routine".
Library routines that are included with the language as per the standard. They are just as much a part of "C++" as the compiler itself is.
>And furthermore,
>it's a language that really didn't work well (poor
>standards compliance, poor portability, slow compile,
>poor debugging tools) until the last 4 years or so.
How would you know if you didn't use it?
We've been using it without problems for a lot longer than that.
Heck, we've been using stuff from Boost a lot longer than that. Much of which is going to be included in the next standard.
Even the template error messages are readable these days.
>Which is why a lot of projects don't use it and a lot of
>people don't know it, me included.
Well, I consider knowing the standard library to be an integral part of being a programmer. Knowing it and choosing not to use it for a particular reason is one thing, but not even learning it is leaving a lot of potential productivity on the table.
>>me long. Heck, I did exactly that as soon as I got a dual-core and I certainly didn't
>>do it by reading through the source code at 500 lines an hour.
>
>Presumably you did it on the basis of profiling or
>other timing data.
Guided by an educated guess as to where it where to start looking, yes. Knowing the algorithms intimately means having a pretty good idea what can be vectorised (SSE) and what can be parallelised.
>Which would be the way I'd do it as
>well. Not by *randomly* "revisiting assumptions".
Who said anything about randomly revisiting assumptions?
>>I said "measurable", not "significant". It's faster with >the simpler code so I'm taking it out.
>
>Yeah, the question is how you decided that it was worth
>taking it out: was that by "revisiting assumptions", or
>was it by seeing it in the profiling data and deciding it
>was worth changing ?
I was revisiting a particular routine that I know is a code hotspot and seeing if I could speed it up more with some features of the new compiler.
As part of that investigation I tested it with straight casting and found that I got an improvement. Looking at the assembler I could see why so I then made the change universal.
If the float-to-int conversion routine wasn't actually used in that particular function then I might not have noticed the difference at that time; OTOH that particular function has a lot of performance tricks in it because it is so critical so it's not surprising to see the conversion routine in there.
>>Which gets back to my original observation -- it's odd that you are so against
>>using a standard routine rather than rolling-your-own when it comes to sorting,
>>but you would rather rely on the unspecified behaviour of the standard memory allocation routine than roll-your-own.
>
>Because I want the fastest performance possible, and the
>best memory usage possible. Progress in either of those
>dimensions helps us to sell our product against our
>competition. And the "standard" stuff isn't good enough
>in either dimension.
Which are excellent reasons for rolling-your-own allocator and having perfectly well-defined behaviour.
>Actually we do indeed roll our own memory allocator, using
>an algorithm which works great for small blocks, but then
>it hands off big blocks to the normal malloc(), because
>big-block allocations aren't performance-critical in our
>app.
Previously you said you used glibc, and glibc's different implementations of malloc() were responsible for your problems.
Since glibc is open-source, couldn't you have read the source code and kept tabs on that? Even better, you could have modified glibc (or derived your own allocator from it) to suit your needs as long as you published your modifications and linked to your modified version dynamically.
>>What, precisely, do you think the alternative is?
>
>I'm just pointing out that "conformant" isn't a very
>helpful concept.
It would have saved you a "nasty few weeks" tracking down mysterious behaviour.
That's what good about writing conformant code. Not that it can magically make your program work when someone pulls the plug out of the wall.
>I'm saying anyone who writes a program using malloc()
>is relying on behavior that isn't very well defined.
Only if you mean something different by "relying".
If you mean it in the sense that Michael raised it and I explained it, then "No". As long as you limit yourself to the assumptions I outlined, you aren't relying on the undefined behaviour at all.
If you mean it in the sense that you need it to give you memory for your program to do something useful, then sure, lots of programs fall into that category -- but that's irrelevant to the point at hand, and it would have been a trite observation for anyone to make.
>And everyone is vulnerable to having their program run
>into trouble if malloc() changes under their feet.
No. The program may not be able to do the operation requested, but that's not the same as "running into trouble". If you user's computer doesn't have the resources and they can't free some up, that's life -- but that wasn't your problem. You not only needed those resources, you need them in a particular way that is specifically not guaranteed by the standard (in fact, it even states that you shouldn't rely on it).
>>Then you will not be relying on undefined behaviour at all
>
>Indeed, and my simple char*malloc(size_t n) { return(NULL); } shows how malloc can obey the defined behavior and
>yet be completely useless.
As I said, whether there are sufficient resources to do useful work or not is a completely different proposition.
I also disagree that your malloc() obeys the defined behaviour, because the standard quite clearly states that the malloc() function allocates space for an object whose size is specified by the size parameter and if the space cannot be allocated, a null pointer is returned.
But even your pathological malloc() wouldn't cause undefined behaviour in a conformant program. It would probably severely curtail it's ability to do something useful, but it's behaviour would still be well-defined.
>So if you're using it, you're
>relying on some behavior which is *not* defined - the fact
>that it actually *does* return some non-NULL blocks
>under some circumstances (circumstances which are never
>precisely defined by any implementation ...)
Again, you're using "relying" in a different sense.
>Of course we check the return code. But there's no
>practical way to recover if it craps out, you just print
>a friendly message and stop.
If that's the case then that's the case.
But your problem was that if the addresses it returned didn't have certain characteristics, your programs would "behave weird". That's relying on undefined (or possibly unspecified in this case) behaviour.
>>You responded "Maybe it does, maybe it doesn't.". Well, if you agree that using
>>separate processes is slower than using threads, and if you agree with the proposition
>>that there's no point parallelising the algorithm if it doesn't deliver a performance
>>improvement, we can only conclude that not using threads therefore rules out those
>>operations that would be faster if parallelised using threads but not faster if parallelised using processes.
>
>What's not clear is whether that class is big enough to
>be interesting. Can't tell until I try it.
Well, in our case that class encompasses most of the operations that we have been able to parallelise. Linux IPC may be fast for IPC, but it's still slow compared to what's possible with threading.
>>Now who's trying to second-guess decisions without being aware of the context? :-)
>
>Well, multi-process task farming is well established as
>a parallel-processing paradigm. Heck, it's how we run
>our compiles and links in our build process. If you're
>saying it doesn't work on a fine enough granularity for
>your app, that's one thing: if you're saying it doesn't
>work because everyone has to share the task queue data
>structure, that's just plain wrong.
I did say it was a specific case and the communications overhead would have been an issue. As I showed in my previous post, even ignoring the data copying cost (in particular the 100 MB copied up-front), the 1-byte ping-pong times you got would take up half of the total processing times per work item. Two processors would be slower than a single processor using serial code!
>>Yes -- and the time required is fine when you're loading or saving a project, but
>>again, it rules out a whole class of worthwhile operations that could be profitably
>threaded if this is the only option.
>
>Maybe I know how to do it faster than you do it :-)
Thousands of times faster?
---------------------------
>It depends what you mean by "standard library routine".
Library routines that are included with the language as per the standard. They are just as much a part of "C++" as the compiler itself is.
>And furthermore,
>it's a language that really didn't work well (poor
>standards compliance, poor portability, slow compile,
>poor debugging tools) until the last 4 years or so.
How would you know if you didn't use it?
We've been using it without problems for a lot longer than that.
Heck, we've been using stuff from Boost a lot longer than that. Much of which is going to be included in the next standard.
Even the template error messages are readable these days.
>Which is why a lot of projects don't use it and a lot of
>people don't know it, me included.
Well, I consider knowing the standard library to be an integral part of being a programmer. Knowing it and choosing not to use it for a particular reason is one thing, but not even learning it is leaving a lot of potential productivity on the table.
>>me long. Heck, I did exactly that as soon as I got a dual-core and I certainly didn't
>>do it by reading through the source code at 500 lines an hour.
>
>Presumably you did it on the basis of profiling or
>other timing data.
Guided by an educated guess as to where it where to start looking, yes. Knowing the algorithms intimately means having a pretty good idea what can be vectorised (SSE) and what can be parallelised.
>Which would be the way I'd do it as
>well. Not by *randomly* "revisiting assumptions".
Who said anything about randomly revisiting assumptions?
>>I said "measurable", not "significant". It's faster with >the simpler code so I'm taking it out.
>
>Yeah, the question is how you decided that it was worth
>taking it out: was that by "revisiting assumptions", or
>was it by seeing it in the profiling data and deciding it
>was worth changing ?
I was revisiting a particular routine that I know is a code hotspot and seeing if I could speed it up more with some features of the new compiler.
As part of that investigation I tested it with straight casting and found that I got an improvement. Looking at the assembler I could see why so I then made the change universal.
If the float-to-int conversion routine wasn't actually used in that particular function then I might not have noticed the difference at that time; OTOH that particular function has a lot of performance tricks in it because it is so critical so it's not surprising to see the conversion routine in there.
>>Which gets back to my original observation -- it's odd that you are so against
>>using a standard routine rather than rolling-your-own when it comes to sorting,
>>but you would rather rely on the unspecified behaviour of the standard memory allocation routine than roll-your-own.
>
>Because I want the fastest performance possible, and the
>best memory usage possible. Progress in either of those
>dimensions helps us to sell our product against our
>competition. And the "standard" stuff isn't good enough
>in either dimension.
Which are excellent reasons for rolling-your-own allocator and having perfectly well-defined behaviour.
>Actually we do indeed roll our own memory allocator, using
>an algorithm which works great for small blocks, but then
>it hands off big blocks to the normal malloc(), because
>big-block allocations aren't performance-critical in our
>app.
Previously you said you used glibc, and glibc's different implementations of malloc() were responsible for your problems.
Since glibc is open-source, couldn't you have read the source code and kept tabs on that? Even better, you could have modified glibc (or derived your own allocator from it) to suit your needs as long as you published your modifications and linked to your modified version dynamically.
>>What, precisely, do you think the alternative is?
>
>I'm just pointing out that "conformant" isn't a very
>helpful concept.
It would have saved you a "nasty few weeks" tracking down mysterious behaviour.
That's what good about writing conformant code. Not that it can magically make your program work when someone pulls the plug out of the wall.
>I'm saying anyone who writes a program using malloc()
>is relying on behavior that isn't very well defined.
Only if you mean something different by "relying".
If you mean it in the sense that Michael raised it and I explained it, then "No". As long as you limit yourself to the assumptions I outlined, you aren't relying on the undefined behaviour at all.
If you mean it in the sense that you need it to give you memory for your program to do something useful, then sure, lots of programs fall into that category -- but that's irrelevant to the point at hand, and it would have been a trite observation for anyone to make.
>And everyone is vulnerable to having their program run
>into trouble if malloc() changes under their feet.
No. The program may not be able to do the operation requested, but that's not the same as "running into trouble". If you user's computer doesn't have the resources and they can't free some up, that's life -- but that wasn't your problem. You not only needed those resources, you need them in a particular way that is specifically not guaranteed by the standard (in fact, it even states that you shouldn't rely on it).
>>Then you will not be relying on undefined behaviour at all
>
>Indeed, and my simple char*malloc(size_t n) { return(NULL); } shows how malloc can obey the defined behavior and
>yet be completely useless.
As I said, whether there are sufficient resources to do useful work or not is a completely different proposition.
I also disagree that your malloc() obeys the defined behaviour, because the standard quite clearly states that the malloc() function allocates space for an object whose size is specified by the size parameter and if the space cannot be allocated, a null pointer is returned.
But even your pathological malloc() wouldn't cause undefined behaviour in a conformant program. It would probably severely curtail it's ability to do something useful, but it's behaviour would still be well-defined.
>So if you're using it, you're
>relying on some behavior which is *not* defined - the fact
>that it actually *does* return some non-NULL blocks
>under some circumstances (circumstances which are never
>precisely defined by any implementation ...)
Again, you're using "relying" in a different sense.
>Of course we check the return code. But there's no
>practical way to recover if it craps out, you just print
>a friendly message and stop.
If that's the case then that's the case.
But your problem was that if the addresses it returned didn't have certain characteristics, your programs would "behave weird". That's relying on undefined (or possibly unspecified in this case) behaviour.
>>You responded "Maybe it does, maybe it doesn't.". Well, if you agree that using
>>separate processes is slower than using threads, and if you agree with the proposition
>>that there's no point parallelising the algorithm if it doesn't deliver a performance
>>improvement, we can only conclude that not using threads therefore rules out those
>>operations that would be faster if parallelised using threads but not faster if parallelised using processes.
>
>What's not clear is whether that class is big enough to
>be interesting. Can't tell until I try it.
Well, in our case that class encompasses most of the operations that we have been able to parallelise. Linux IPC may be fast for IPC, but it's still slow compared to what's possible with threading.
>>Now who's trying to second-guess decisions without being aware of the context? :-)
>
>Well, multi-process task farming is well established as
>a parallel-processing paradigm. Heck, it's how we run
>our compiles and links in our build process. If you're
>saying it doesn't work on a fine enough granularity for
>your app, that's one thing: if you're saying it doesn't
>work because everyone has to share the task queue data
>structure, that's just plain wrong.
I did say it was a specific case and the communications overhead would have been an issue. As I showed in my previous post, even ignoring the data copying cost (in particular the 100 MB copied up-front), the 1-byte ping-pong times you got would take up half of the total processing times per work item. Two processors would be slower than a single processor using serial code!
>>Yes -- and the time required is fine when you're loading or saving a project, but
>>again, it rules out a whole class of worthwhile operations that could be profitably
>threaded if this is the only option.
>
>Maybe I know how to do it faster than you do it :-)
Thousands of times faster?
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 |