Article: Hot Chips XXI Preview
By: JasonB (no.delete@this.spam.com), August 25, 2009 8:56 pm
Room: Moderated Discussions
Richard Cownie (tich@pobox.com) on 8/25/09 wrote:
---------------------------
>JasonB (no@spam.com) on 8/25/09 wrote:
>---------------------------
>
>>Strictly speaking you can use separate compilation of templates with definitions
>>in a separate .cpp file (and only declarations in the header,
>
>Yes. But that's a homebrew method.
I wouldn't call it "homebrew", it's a perfectly valid and legal way of separating implementation from interface, it's just not very practical.
>The standard defines
>a "standard" way to do it. Which turns out to useless,
>because no-one implements it.
Apparently Comeau C++ and Borland C++ Builder X implement it. But export is an attempt to extend a nice principle (namely compilation of implementation only once) to templates, and the lack of it is hardly a show-stopper.
For readability purposes we often separate interface from implementation by declaring the implementation outside of the class, in a separate file, that is #included at the end of the header. The only real downside to this compared to the normal separation is that the template will be recompiled for each cpp file it is used in rather than just once, i.e. it's a compilation performance issue -- but even then it's not a big one because VC++ supports precompiled headers anyway. Importantly it does not affect the final result in any way because the linker will automatically remove all duplicate copies of the same instantiation (i.e. if you use a vector of ints in every compilation unit in your project you will still only have exactly one implementation of vector for ints in your final exe; of course if the compiler chooses to inline some of the routines then they could be all over the place, but whether a method is inlined is completely orthogonal to whether it was declared inline, and in VC++ even routines compiled into separate compilation units can be ultimately inlined with Whole Program Optimisation enabled. Conversely, the compiler will generally not inline recursive functions, "large" functions, or functions that you take the address of, even if they are declared inline).
>It's a question of
>"culture", i.e. the body of experience and knowledge
>about techniques and tools. If a super-intelligent
>alien came to Earth and tried to write programs simply
>by reading the C++ standard, they'd write programs that
>wouldn't even compile, let alone run correctly.
If they happened to make the mistake of using the export keyword with the majority of compilers, yes. What is your point? It's one feature added at the last minute in the current standard that almost nobody uses and very few vendors implement because it's not really necessary. The C++ standards committee even put removing it to a vote and ended up deciding to leave it in there since there were now implementations and some people using it, although most would probably agree it was a mistake to include it in the first place. So? Sometimes that happens, it doesn't invalidate everything else.
>>>dynamic_cast (because it
>>>didn't - maybe still doesn't ? - work correctly in g++),
>>
>>dynamic_cast isn't needed all that often, but when it is needed there is no substitute.
>
>The substitute is that you put a whole bunch of extra
>virtual methods on every class in your hierarchy for
>casting to every other class. Which is N-squared in
>the number of classes, so it's really ugly.
Should I have said "there is no practical substitute"?
>>In keeping with C++'s general philosophy, however, you >need to have RTTI enabled in order for it to work.
>
>I think you're talking specifically about MSVC++ there ?
I don't think so -- I imagine most compilers allow RTTI (and exception support) to be enabled or disabled because enabling them imposes a cost and if you don't use dynamic_cast (or exceptions) in your code at all you can avoid paying that cost, which is one of the main principles of C++ (i.e. you don't pay for what you don't use; cf. methods not being virtual by default). In g++ at least the switch to disable RTTI appears to be "-fno-rtti".
I just searched through our code and we never use dynamic_cast for any of our own code -- properly designed application-level OO code has very few uses for casting. The OTT use of casting in Java, for example, is because in earlier versions all containers had to contain Objects and you always had to use a cast every time you retrieved something from the container; in C++ you just use templated containers that check at compile time that you're only inserting and retrieving objects of the specified type.
We only ever use it to cast pointers returned by the MFC framework that should always be what it is expected but it's just making sure. We also have our own cast that does a dynamic_cast in debug mode and a static_cast in release mode for the same types of things.
>>Exceptions, when only used for exceptional stuff (i.e. not for routine errors,
>>like Java does), are useful. As I mentioned before, we put try-catch blocks at the
>>"user level" of individual operations and do the work off to the side so that if
>>anything goes wrong with the operation itself no damage is done and we can simply
>>tell the user the operation couldn't be performed.
>
>Sure, but used like that it doesn't add much beyond
>what setjmp/longjmp give you.
Well, off the top of my head I can see two serious obstacles to using setjmp/longjmp as a substitute for exceptions.
The first is practicality: the amount of housekeeping you would need to do and the unacceptable level of coupling and co-operation between completely different levels of your program would be a nightmare to both implement and maintain.
With exceptions you can freely choose at any level to handle any subset of any possible exceptions without ever having to worry about anything falling through the cracks, and without having intimate knowledge of the implementation of the code that you are calling. It might be perfectly reasonable, for example, to handle an out-of-memory exception at a relatively low level in a certain case, but want to let an illegal access violation pass up to a much higher level where your "I'm sorry, please let me submit this bug report for you" handler can take care of it and then continue on.
The second is functionality: throwing an exception guarantees the destruction of all objects on the stack from the thrower to the catcher, allowing RAII to be used to guarantee no resources leak and the program to be exception safe (to the point where it is possible to file a bug report with the server related to the particular operation that was attempted, and then allow the user to continue on in exactly the same state they were in prior to attempting that operation with a warning that they probably should not attempt that particular operation again until the bug has been fixed).
>And mediocre developers
>tend to say "we'll use exceptions" as a *substitute* for
>actually designing an error-handling strategy.
I really don't care what mediocre developers will do. Mediocre developers will always find ways to do things wrong. If I wanted to limit my options by excluding anything mediocre programmers might get wrong I'd be using Java, not C++, and even then I wouldn't have achieved much. (Find me an exception-safe Java program...)
>>Writing exception-safe code is hard, but doing so is worth it.
>
>Possibly, if you design it in from the beginning. But
>taking millions of lines of exception-unsafe code and
>trying to make it exception-safe is infeasible. And
>I *really* don't like features that require a global
>change in assumptions and coding practices: that makes
>it a big cost.
Actually, it wasn't all that hard for us. For the most part we have exception handlers around the user-level operations and we make those high-level routines exception safe -- in the worst case we simply report the problem to the user and the program is in exactly the same state it was in before.
>>Note that, on Windows at least, underlying CPU and OS exceptions can be mapped
>>into the language (structured exceptions) and handled just like any other exception.
>>Even if you don't use exceptions yourself, writing exception-safe code means you
>>can automatically do something nicer than core dump when there's a bug in your code.
>
>Up to a point. If the exception is saying "something
>really screwy just happened in your code", then trying
>to catch it with an exception handler that does a lot
>of complicated stuff may not be robust.
Our exception handlers are of the form:
structured_exception handles the following errors:
"Access violation", "Array bounds exceeded", "Datatype misalignment", "Float: Denormal operand", "Float: Divide by zero", "Float: Inexact result", "Float: Invalid operation", "Float: Overflow", "Float: Stack check", "Float: Underflow", "Illegal instruction", "In page error", "Integer: Divide by zero", "Integer: Overflow", "Privileged instruction", "Stack overflow", "Breakpoint"*, "Single step"*, "Noncontinuable exception", "Invalid disposition", "Guard page", and "Invalid handle". (The two with *'s are actually invoked when you're running the program in the debugger; we actually don't try to catch those.)
It contains the value of every register, the full stack trace, and extra values related to the type of error. So, for example, our code for handling an access violation extracts the location that the code attempted to write to thus:
Although having a bug in your code is undesirable, we've found it's better to be upfront about it and not having the program die taking all of the data generated so far with it goes a long way to overcoming the negative impression. If you encapsulate the operation properly so that no matter what went wrong at what stage, everything else is still OK, the biggest problem from the user's point of view is that they are unable to perform that particular operation (at least with the parameters or data they attempted to perform it with).
The std::exception stuff is more "normal" and can include things like running out of memory (although you may well have a "catch (const std::bad_alloc& e)" closer to the site where the memory was actually being used if there's a chance something else can be done about it, while letting all other standard exceptions through to the keeper).
>I don't see a compelling argument for exceptions
>compared to setjmp/longjmp (and signal handling for the
>OS stuff). Exceptions fit better in languages with
>garbage collection.
On the contrary, I think languages with GC are far worse for exception handling.
GC typically implies non-deterministic object destruction. Non-deterministic object destruction implies RAII cannot be used. Not being able to use RAII makes it nearly impossible to write exception-safe code.
To give you an example using C-style code (because the standard C++ equivalents use RAII internally already), consider the following code using scopeguard:
This not only simplifies code (no nested if statements to handle resource acquisition and release -- e.g. you can safely return or throw if you fail to open the file in the second case without having to worry about the memory being freed) but it also makes it more robust, because (as the comments suggest) the "undo" operations (free and fclose) are guaranteed to be called no matter what -- even if you trigger a CPU exception.
(Of course, the C++ equivalent would be:
because, as I said, the standard library classes already use RAII themselves.)
>And even the benefit is questionable:
>with modern cpu's, checking a return code and taking an
>extremely-predictable branch usually costs nothing,
>so exceptions don't make the code any faster.
It's not about speed. It's about making errors hard to ignore (e.g. failing to allocate memory in the C++ example above will cause an exception to be thrown) and taking care of the housekeeping should you wish to handle the error at a much different level to the one that caused the error.
In the coffee making example, if anything goes wrong with the coffee making operation the important result is that the user does not get a cup of coffee, so it's reasonable to put a catch-all at the top level of that operation that apologises profusely and suggests a cup of tea instead. However, if there is an error in the coffee-making process that can be recovered from at a lower level, then the programmer can selectively handle that case at the appropriate level and the high-level code will be none the wiser.
Importantly, nobody has to get all the error handling and propagating code just right at all the levels between where the error occurred and where the error can be reasonably handled because the compiler will take care of the tedious and error-prone housekeeping for you.
>And the
>frequent - maybe usual - consequence of separating out
>the "exceptional" case from the normal case is that the
>code for the "exceptional" case never gets written at
>all ...
And how is that more likely than the return value from the function not being checked every single time it is called? You have to make sure you check the result of every malloc or risk undefined behaviour; with new, you can safely have a whole series of allocations handled by a single catch if all of them should be considered "atomic" in the success of the operation (i.e. you only bother dealing with a particular one at the location it occurs if there is something useful you can do to recover in that instance).
>>Not surprisingly, then, I actually find it quite useful. :-) The two big benefits
>>over the old equivalents are type safety (mismatching format specifiers with actual
>>parameter types)
>
>gcc/g++ can provide warnings for printf format-vs-type
>mismatches, which is handy.
That is nice. There is also a Boost Format library that implements a type-safe replacement for printf, although I don't really like the syntax.
>>as built-in classes (you can't add support for your class >to printf's format string).
>
>No, but you could write a char* Foo::Text(void); method
>and use a %s string format specifier. So the difference
>is minimal.
But there. I like languages where user-defined classes are indistinguishable from build-in classes, and if we ignore the legacy C portions of C++ then C++ has that.
Besides, I like lexical_cast as a way of transferring data between types, and that's built on streams.
---------------------------
>JasonB (no@spam.com) on 8/25/09 wrote:
>---------------------------
>
>>Strictly speaking you can use separate compilation of templates with definitions
>>in a separate .cpp file (and only declarations in the header,
>
>Yes. But that's a homebrew method.
I wouldn't call it "homebrew", it's a perfectly valid and legal way of separating implementation from interface, it's just not very practical.
>The standard defines
>a "standard" way to do it. Which turns out to useless,
>because no-one implements it.
Apparently Comeau C++ and Borland C++ Builder X implement it. But export is an attempt to extend a nice principle (namely compilation of implementation only once) to templates, and the lack of it is hardly a show-stopper.
For readability purposes we often separate interface from implementation by declaring the implementation outside of the class, in a separate file, that is #included at the end of the header. The only real downside to this compared to the normal separation is that the template will be recompiled for each cpp file it is used in rather than just once, i.e. it's a compilation performance issue -- but even then it's not a big one because VC++ supports precompiled headers anyway. Importantly it does not affect the final result in any way because the linker will automatically remove all duplicate copies of the same instantiation (i.e. if you use a vector of ints in every compilation unit in your project you will still only have exactly one implementation of vector for ints in your final exe; of course if the compiler chooses to inline some of the routines then they could be all over the place, but whether a method is inlined is completely orthogonal to whether it was declared inline, and in VC++ even routines compiled into separate compilation units can be ultimately inlined with Whole Program Optimisation enabled. Conversely, the compiler will generally not inline recursive functions, "large" functions, or functions that you take the address of, even if they are declared inline).
>It's a question of
>"culture", i.e. the body of experience and knowledge
>about techniques and tools. If a super-intelligent
>alien came to Earth and tried to write programs simply
>by reading the C++ standard, they'd write programs that
>wouldn't even compile, let alone run correctly.
If they happened to make the mistake of using the export keyword with the majority of compilers, yes. What is your point? It's one feature added at the last minute in the current standard that almost nobody uses and very few vendors implement because it's not really necessary. The C++ standards committee even put removing it to a vote and ended up deciding to leave it in there since there were now implementations and some people using it, although most would probably agree it was a mistake to include it in the first place. So? Sometimes that happens, it doesn't invalidate everything else.
>>>dynamic_cast (because it
>>>didn't - maybe still doesn't ? - work correctly in g++),
>>
>>dynamic_cast isn't needed all that often, but when it is needed there is no substitute.
>
>The substitute is that you put a whole bunch of extra
>virtual methods on every class in your hierarchy for
>casting to every other class. Which is N-squared in
>the number of classes, so it's really ugly.
Should I have said "there is no practical substitute"?
>>In keeping with C++'s general philosophy, however, you >need to have RTTI enabled in order for it to work.
>
>I think you're talking specifically about MSVC++ there ?
I don't think so -- I imagine most compilers allow RTTI (and exception support) to be enabled or disabled because enabling them imposes a cost and if you don't use dynamic_cast (or exceptions) in your code at all you can avoid paying that cost, which is one of the main principles of C++ (i.e. you don't pay for what you don't use; cf. methods not being virtual by default). In g++ at least the switch to disable RTTI appears to be "-fno-rtti".
I just searched through our code and we never use dynamic_cast for any of our own code -- properly designed application-level OO code has very few uses for casting. The OTT use of casting in Java, for example, is because in earlier versions all containers had to contain Objects and you always had to use a cast every time you retrieved something from the container; in C++ you just use templated containers that check at compile time that you're only inserting and retrieving objects of the specified type.
We only ever use it to cast pointers returned by the MFC framework that should always be what it is expected but it's just making sure. We also have our own cast that does a dynamic_cast in debug mode and a static_cast in release mode for the same types of things.
>>Exceptions, when only used for exceptional stuff (i.e. not for routine errors,
>>like Java does), are useful. As I mentioned before, we put try-catch blocks at the
>>"user level" of individual operations and do the work off to the side so that if
>>anything goes wrong with the operation itself no damage is done and we can simply
>>tell the user the operation couldn't be performed.
>
>Sure, but used like that it doesn't add much beyond
>what setjmp/longjmp give you.
Well, off the top of my head I can see two serious obstacles to using setjmp/longjmp as a substitute for exceptions.
The first is practicality: the amount of housekeeping you would need to do and the unacceptable level of coupling and co-operation between completely different levels of your program would be a nightmare to both implement and maintain.
With exceptions you can freely choose at any level to handle any subset of any possible exceptions without ever having to worry about anything falling through the cracks, and without having intimate knowledge of the implementation of the code that you are calling. It might be perfectly reasonable, for example, to handle an out-of-memory exception at a relatively low level in a certain case, but want to let an illegal access violation pass up to a much higher level where your "I'm sorry, please let me submit this bug report for you" handler can take care of it and then continue on.
The second is functionality: throwing an exception guarantees the destruction of all objects on the stack from the thrower to the catcher, allowing RAII to be used to guarantee no resources leak and the program to be exception safe (to the point where it is possible to file a bug report with the server related to the particular operation that was attempted, and then allow the user to continue on in exactly the same state they were in prior to attempting that operation with a warning that they probably should not attempt that particular operation again until the bug has been fixed).
>And mediocre developers
>tend to say "we'll use exceptions" as a *substitute* for
>actually designing an error-handling strategy.
I really don't care what mediocre developers will do. Mediocre developers will always find ways to do things wrong. If I wanted to limit my options by excluding anything mediocre programmers might get wrong I'd be using Java, not C++, and even then I wouldn't have achieved much. (Find me an exception-safe Java program...)
>>Writing exception-safe code is hard, but doing so is worth it.
>
>Possibly, if you design it in from the beginning. But
>taking millions of lines of exception-unsafe code and
>trying to make it exception-safe is infeasible. And
>I *really* don't like features that require a global
>change in assumptions and coding practices: that makes
>it a big cost.
Actually, it wasn't all that hard for us. For the most part we have exception handlers around the user-level operations and we make those high-level routines exception safe -- in the worst case we simply report the problem to the user and the program is in exactly the same state it was in before.
>>Note that, on Windows at least, underlying CPU and OS exceptions can be mapped
>>into the language (structured exceptions) and handled just like any other exception.
>>Even if you don't use exceptions yourself, writing exception-safe code means you
>>can automatically do something nicer than core dump when there's a bug in your code.
>
>Up to a point. If the exception is saying "something
>really screwy just happened in your code", then trying
>to catch it with an exception handler that does a lot
>of complicated stuff may not be robust.
Our exception handlers are of the form:
try {
MakeCoffee(options);
} catch (const structured_exception& e){
// Ooh, this shouldn't happen. Most likely a bug.
RequestPermissionToLodgeReport(e);
} catch (const std::exception& e){
// A standard problem
ReportException(e);
}
structured_exception handles the following errors:
"Access violation", "Array bounds exceeded", "Datatype misalignment", "Float: Denormal operand", "Float: Divide by zero", "Float: Inexact result", "Float: Invalid operation", "Float: Overflow", "Float: Stack check", "Float: Underflow", "Illegal instruction", "In page error", "Integer: Divide by zero", "Integer: Overflow", "Privileged instruction", "Stack overflow", "Breakpoint"*, "Single step"*, "Noncontinuable exception", "Invalid disposition", "Guard page", and "Invalid handle". (The two with *'s are actually invoked when you're running the program in the debugger; we actually don't try to catch those.)
It contains the value of every register, the full stack trace, and extra values related to the type of error. So, for example, our code for handling an access violation extracts the location that the code attempted to write to thus:
if (record.ExceptionCode == EXCEPTION_ACCESS_VIOLATION && record.NumberParameters == 2){
os << ": Attempted to " << (record.ExceptionInformation[0] == 0 ? "read from" : "write to") <<
" address 0x" << setw(8) << record.ExceptionInformation[1];
}
Although having a bug in your code is undesirable, we've found it's better to be upfront about it and not having the program die taking all of the data generated so far with it goes a long way to overcoming the negative impression. If you encapsulate the operation properly so that no matter what went wrong at what stage, everything else is still OK, the biggest problem from the user's point of view is that they are unable to perform that particular operation (at least with the parameters or data they attempted to perform it with).
The std::exception stuff is more "normal" and can include things like running out of memory (although you may well have a "catch (const std::bad_alloc& e)" closer to the site where the memory was actually being used if there's a chance something else can be done about it, while letting all other standard exceptions through to the keeper).
>I don't see a compelling argument for exceptions
>compared to setjmp/longjmp (and signal handling for the
>OS stuff). Exceptions fit better in languages with
>garbage collection.
On the contrary, I think languages with GC are far worse for exception handling.
GC typically implies non-deterministic object destruction. Non-deterministic object destruction implies RAII cannot be used. Not being able to use RAII makes it nearly impossible to write exception-safe code.
To give you an example using C-style code (because the standard C++ equivalents use RAII internally already), consider the following code using scopeguard:
char* ptr = (char*) malloc(10);
if (ptr == NULL)
return false; // or throw, or whatever
ON_BLOCK_EXIT(free, ptr); // free(ptr) is *guaranteed* to be called when this block exits, no matter what.
FILE* fp = fopen("test","r");
if (fp == NULL)
return false; //or throw, or whatever
ON_BLOCK_EXIT(fclose, fp); // fclose(fp) is *guaranteed* to be called when this block exist, no matter what.
This not only simplifies code (no nested if statements to handle resource acquisition and release -- e.g. you can safely return or throw if you fail to open the file in the second case without having to worry about the memory being freed) but it also makes it more robust, because (as the comments suggest) the "undo" operations (free and fclose) are guaranteed to be called no matter what -- even if you trigger a CPU exception.
(Of course, the C++ equivalent would be:
auto_ptrap(new char[10]);
ifstream ifs("test");
if (!ifs)
return false; //or throw, or whatever
because, as I said, the standard library classes already use RAII themselves.)
>And even the benefit is questionable:
>with modern cpu's, checking a return code and taking an
>extremely-predictable branch usually costs nothing,
>so exceptions don't make the code any faster.
It's not about speed. It's about making errors hard to ignore (e.g. failing to allocate memory in the C++ example above will cause an exception to be thrown) and taking care of the housekeeping should you wish to handle the error at a much different level to the one that caused the error.
In the coffee making example, if anything goes wrong with the coffee making operation the important result is that the user does not get a cup of coffee, so it's reasonable to put a catch-all at the top level of that operation that apologises profusely and suggests a cup of tea instead. However, if there is an error in the coffee-making process that can be recovered from at a lower level, then the programmer can selectively handle that case at the appropriate level and the high-level code will be none the wiser.
Importantly, nobody has to get all the error handling and propagating code just right at all the levels between where the error occurred and where the error can be reasonably handled because the compiler will take care of the tedious and error-prone housekeeping for you.
>And the
>frequent - maybe usual - consequence of separating out
>the "exceptional" case from the normal case is that the
>code for the "exceptional" case never gets written at
>all ...
And how is that more likely than the return value from the function not being checked every single time it is called? You have to make sure you check the result of every malloc or risk undefined behaviour; with new, you can safely have a whole series of allocations handled by a single catch if all of them should be considered "atomic" in the success of the operation (i.e. you only bother dealing with a particular one at the location it occurs if there is something useful you can do to recover in that instance).
>>Not surprisingly, then, I actually find it quite useful. :-) The two big benefits
>>over the old equivalents are type safety (mismatching format specifiers with actual
>>parameter types)
>
>gcc/g++ can provide warnings for printf format-vs-type
>mismatches, which is handy.
That is nice. There is also a Boost Format library that implements a type-safe replacement for printf, although I don't really like the syntax.
>>as built-in classes (you can't add support for your class >to printf's format string).
>
>No, but you could write a char* Foo::Text(void); method
>and use a %s string format specifier. So the difference
>is minimal.
But there. I like languages where user-defined classes are indistinguishable from build-in classes, and if we ignore the legacy C portions of C++ then C++ has that.
Besides, I like lexical_cast as a way of transferring data between types, and that's built on streams.
int i = lexical_cast(str);
string s = lexical_cast(i);
// s == str
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 |