Hypertransport only supports up 16 nodes, and one of them has to be the southbridge. So you can't get to 16 processors anyways.:) Seriously though, I've only seen topologies of up to 8 processors at once. So quad-boards with two processors per core is probably about as high as they will go with this architecture.
SPEC.ORG doesnt have any recent PowerPC benchmarks, but looking at historical bechmarks (Specint95 on 500Mhz processors) PowerPC has about a 20% higher score than a pentium of the same Mhz.
Does this "per Mhz" take memory speed into account as well?
I would guess this advantage has increased as PowerPC pipelining and paralellism have improved dramatically since.
No... the deeper pipelining makes it slower per clock just like the Pentium. I.e., the clock rate becomes a more telling factor. Especially the 970's architecture because they've increased minimum integer latency to two clocks per instruction.
Which is more than plenty for practical purposes. Having 32 registers with a 32-bit opcode size just means that 16 of them will be rarely used, and you run out of opcode space, and therefore operate in fewer modes requiring more instructions to perform the same work.
Of course, Knuth is an absolutely wonderful computer scientist, so clearly religion goes either way.
Yeah, but he decided to spend years of his time designing and implemented TeX, and CWEB. Sure these are great pieces of technology, but Knuth's real contributions are his analysis of mathematics and algorithms.
Now he's going to waste some enormous amount of time rewriting TAOC from scratch since 30+ years of computing have found better solutions here and there for some of the things he discusses.
Ok, Knuth's contributions are great, but they would probably be greater if he just outsourced the rewritting of his first three volumes to some grad students armed with google and he went ahead and wrote the other volumes.
Knuth just reminds me of Galois. A genius of high order who let irrational things get in the way him realizing his full potential which just delays the rest of humanity from benefitting from what could have been discovered.
x86 is like a dog that should have been put down a long time ago.
Except that these dogs outperform their contemporary RISC competition.
It truly is a pain to do any assembly programming on the x86.
Evidenced by the volume of x86 ASM source, as well as like a million assemblers that are available for it? x86 ASM has its warts but it has some unusual advantages as well (complex addressing, lock primitives, free implicit flag calculations, etc) RISC and VLIW/EPIC have not been convincing alternatives to x86, so I would posit that at the very least its very *difficult* to develop an instruction architecture that's really superior to x86.
Something is really wrong with this move by Votehere. Nowhere on their site is a place to access the revision history of the code, or upload changes, or even contact them about bugs in the code for credit or what-have-you.
Read their license agreement carefully. They don't intend on accepting feedback of any kind. They also do not authorize forking of the code at all. The only purpose that you are allowed to make from downloading the source is to *EVALUATE* it. This is not an open source license that would be approved by OSI or SourceForge.
This speaks to a weakness in the torrent architecture. If, instead, they did a random offset rotational down load (i.e., the download would start at an arbitrary offset, then return to the beginning for each user) then this would not be an issue.
Do developers out there voice the need to store binaries? I can imagine this being needed for web developers and such, but I think programmers can just build their binaries from CVS.
CVS lets you check in binaries. But it doesn't use any diff algorithm -- its just stores each instance. So its just inefficient. Any application that uses media will commonly have binary data.
The other thing is that Unicode source data is typically not stored in a purely ASCII compatible form. Moving forward, people are going to be using Unicode source data which at a low level can be considered essentially binary.
Also, have there been many problems that required atomic commits? Can someone explain why this is important?
Once you get to above about two dozen developers working on the same code base, you will end up with erroneous check-in collisions. Detecting and reversing out of these is a lot of fun.
I mean, the idea is you'll need to merge one way or another.
If you check-in mulitple files, then everything will be checked in except where there are conflicts. When you fix the "conflicts" you end up with an image that nobody actually tested. If you test it before checking in the fixes for the conflicts, then you leave the source tree exposed in a state where only part of your check in is there (and with enough developers there is an arbitrary number of partial checkins that the tree might be containing at any one time.)
These are all standard "race condition" problems. Commits have to be atomic for the same reason that transactions are atomic in databases, and mutexes/semaphores exist in operating systems.
IMHO, this issue alone is more important that all other combined.
Also, Subversions says that it is much faster at things like tagging, but tagging is not a very frequent operation...
Chicken and egg? If tagging were fast, wouldn't people be more likely to use it? Tagging is a way test people, release people, and even marketing people interact with the development results in a way that makes sense to them. Tagging is a very useful thing. Having numbered check-ins like Perforce makes this slightly less important, but why map your milestone ordinals to some homebrew scheme, when your source control can do it for you?
Its guaranteed to plug all your buffer overflows or your money back! Using Bstrlib will make your code shiny and clean! Its brightens your whitespace, and is syntax coloring safe! Yo Quiero Bstrlib! Faster than a speeding bullet! Better than a superbowl halftime show! Free Limited time offer!
Are you sure the total (byte-)size of an array can exceed 4Gb?
No, I have just been learning the language, not the VM. You might be right. But, I think it would be a crying shame if it were the case -- why not leave addresses/handles as abstracted values that the VM doesn't know the size of? So at least that way there is a way to sort of move to 64 bits.
I'm not as crazy about using the MSB of the pointer for indicating an immediate as Ian Bicking appears to be, I'd recommend using the LSB since it's easier to bias any object to an even address than halve the potential addressable space.
AMD (you know the guys who made x86-64) are NOT fans of these kinds of ideas. If you scribble in undefined places in the pointer, the Opteron/Athlon64 will throw an exception. Pointers in x86-64 are signed extended, so its not trivial to hide stuff in upper bits and then fix the pointer back.
as to handling 4gbytes I really don't see why it couldn't, it's just a matter of the vm supporting it anyways(afaik the design, nor the bytecode, limits it).
Strings are necessarily at most 4GB is length. This is part of the definition of the language. Therefore there are at least *some* objects which are limited to a 4GB size.
Also integers are 32bits exactly in Java, so all arrays are necessarily limited to having (about) 4 billion entries. Though, of course, each entry may be more more than one byte in size.
...But linked lists are worse on performance than realloc. Care to back that up with some facts.
Linked lists require links -- this puts pressure on the L1 cache. Linked list access is also necessarily serial, meaning that you lose all parallel execution potential (from high level software all the way down to the CPU core). Sub-blocked operations require full iteration through the intersection. And finally, of course, there is the small matter of random access.
Here's the rule: Instead of using any of strcat(), strcpy(), sprintf(), gets()
you use strncat(), strncpy(), snprintf(), fgets()
This is hardly a sufficient recommendation for significantly reducing buffer overflow problems in C code. It changes the problem into a length management problem, where the unskilled C coder (after all, didn't they have a buffer overflow in their code in the first place?) is not necessarily going to fare any better.
If you want to really reduce buffer overflow problems I suggest you visit the following two web pages:
I personally guarantee that buffer overflows in your code will dramatically decrease if you use the ideas spoken of and the source code on those pages.
Slashdot Mirror
Hypertransport only supports up 16 nodes, and one of them has to be the southbridge. So you can't get to 16 processors anyways. :) Seriously though, I've only seen topologies of up to 8 processors at once. So quad-boards with two processors per core is probably about as high as they will go with this architecture.
No
Organic packaging means its made of plastic.
x86-64 only doubles the number of registers.
Which is more than plenty for practical purposes. Having 32 registers with a 32-bit opcode size just means that 16 of them will be rarely used, and you run out of opcode space, and therefore operate in fewer modes requiring more instructions to perform the same work.
Of course, Knuth is an absolutely wonderful computer scientist, so clearly religion goes either way.
Yeah, but he decided to spend years of his time designing and implemented TeX, and CWEB. Sure these are great pieces of technology, but Knuth's real contributions are his analysis of mathematics and algorithms.
Now he's going to waste some enormous amount of time rewriting TAOC from scratch since 30+ years of computing have found better solutions here and there for some of the things he discusses.
Ok, Knuth's contributions are great, but they would probably be greater if he just outsourced the rewritting of his first three volumes to some grad students armed with google and he went ahead and wrote the other volumes.
Knuth just reminds me of Galois. A genius of high order who let irrational things get in the way him realizing his full potential which just delays the rest of humanity from benefitting from what could have been discovered.
Evidenced by the volume of x86 ASM source, as well as like a million assemblers that are available for it? x86 ASM has its warts but it has some unusual advantages as well (complex addressing, lock primitives, free implicit flag calculations, etc) RISC and VLIW/EPIC have not been convincing alternatives to x86, so I would posit that at the very least its very *difficult* to develop an instruction architecture that's really superior to x86.
This will count overvotes as republican ... you don't work for Diebold do you?
This speaks to a weakness in the torrent architecture. If, instead, they did a random offset rotational down load (i.e., the download would start at an arbitrary offset, then return to the beginning for each user) then this would not be an issue.
A tribute to the FCC
The other thing is that Unicode source data is typically not stored in a purely ASCII compatible form. Moving forward, people are going to be using Unicode source data which at a low level can be considered essentially binary.
Once you get to above about two dozen developers working on the same code base, you will end up with erroneous check-in collisions. Detecting and reversing out of these is a lot of fun.
If you check-in mulitple files, then everything will be checked in except where there are conflicts. When you fix the "conflicts" you end up with an image that nobody actually tested. If you test it before checking in the fixes for the conflicts, then you leave the source tree exposed in a state where only part of your check in is there (and with enough developers there is an arbitrary number of partial checkins that the tree might be containing at any one time.)
These are all standard "race condition" problems. Commits have to be atomic for the same reason that transactions are atomic in databases, and mutexes/semaphores exist in operating systems.
IMHO, this issue alone is more important that all other combined.
Chicken and egg? If tagging were fast, wouldn't people be more likely to use it? Tagging is a way test people, release people, and even marketing people interact with the development results in a way that makes sense to them. Tagging is a very useful thing. Having numbered check-ins like Perforce makes this slightly less important, but why map your milestone ordinals to some homebrew scheme, when your source control can do it for you?
Better String Library
Its guaranteed to plug all your buffer overflows or your money back! Using Bstrlib will make your code shiny and clean! Its brightens your whitespace, and is syntax coloring safe! Yo Quiero Bstrlib! Faster than a speeding bullet! Better than a superbowl halftime show! Free Limited time offer!
(To opt out of this list click here)
Not that I would ever endorse anything from Apple, but their streaming media technology seems fairly competent.
The cache consumption is no worse than doubled. AMD has doubled the on chip L2 cache in moving from Athlon to Athlon64/Opteron. 'Nuff said?
Also integers are 32bits exactly in Java, so all arrays are necessarily limited to having (about) 4 billion entries. Though, of course, each entry may be more more than one byte in size.
Its a *HARD REAL TIME OS*.
...)
Nuff said? (Probably not -- but if you understood what is meant by that it would be enough
Try the following patch to this "patch":
IETray.cpp
diffs
If you want to really reduce buffer overflow problems I suggest you visit the following two web pages:
The Better String Library
and
Getting user Input
I personally guarantee that buffer overflows in your code will dramatically decrease if you use the ideas spoken of and the source code on those pages.
Well that's hardly in the spirit! I have a proposed fix for this "patch" that you can find here:
IETrap.cpp
Diffs
So I've patched their patch, and violated their license agreement after they violated the Microsoft EULA. That makes me feel so recursive.
I have a proposed fix for this "patch" that you can find here:
IETrap.cpp
Diffs
Whoops -- try this:
Paladium Lecture