For one thing, I doubt you grasp the "x86" architecture as it is known today. You think you know what you're talking about due to slashdot and Apple ads.
The x86 architecture doesn't really exist. No modern processor executes x86 instructions. The overhead of doing translation is minimal. And Intel and AMD have shown that doing their own cores and the translation from x86 to them produces amazingly fast chips. Intel and AMD can continue to do x86-ish architectures (and will; I think hammer will be big and turn out to perform better than Intel's IA64 chips) and the performance will be as good as an architecture without the x86ish syntax.
For another thing, for someone who claims to know about PCs, how can you not get the parts to work together correctly? Get revision 2, non-cutting edge motherboard, CPU, hard drive(s), graphics card and a $10 NIC and you have my computer, which has had no problems during either configuration or while running. And those "wal-mart shitboxes" that you speak of are pretty much the same. They're not top-of-the-line, but the parts -- standard motherboard chipset, standard cpu, generic video, PCI bus -- are well supported by free unices and pretty darn stable.
My experience has been: I can put together parts that, for the most part, are the cheapest ones available (or close to it) and get a computer that works seamlessly and flawlessly. (Maybe not in Windows, though)
is generated, not by the garbage collector, but by the JVM when it trys to access a method from a null object, a pointer vers a non initialzed object. This has nothing to do with the memory management. If you had said:
java.lang.OutOfMemoryError, I would have aplaud you. But, You missed the mark by a mile.
Sorry, what I meant was that the object paradigm allows for invalid references. In Java I can have a reference that doesn't point to a valid object, and if I dereference it I can get a NullPointerException. This is, of course, a separate issue from the garbage collector.
"Memory management" from the point of view of the programmer, not that of the environment. That of how you manage your storage.
People act as though C and C++ are the top of the language evolutionary scale--sheer nonsense. C and all of the "C-alikes" have held back decent software engineering now for decades...we get to enjoy buffer and stack
overflows, pointers wandering through address space and other idiocies.
You act as though C is responsible for a stack overflow or pointer pointing problems.
You wanna know something: IT'S THE PROGRAMMER.
You can write huge applicatations in plain ANSI C. They can run flawlessly. As long as you use good programming practices and have good programmers.
Excepting buggy compilers or libraries (very rare in my experience), when you write something in C and it doesn't work, it's your fault. C is very simple, elegant, and deterministic. For examples of C programs that work very well, see UNIX OS kernels, most of the system tools on UNIX, and especially TeX.
You can write perfect programs in some "more modern" languages ("safe" languages like Java) that will crash, because the environment is so complex that many environments are buggy. This is unacceptable. Not only that, most of these languages aren't any better than C as far as memory management (That's why all the Java programs I see crash with "NullPointerException").
These new languages, however, do increase the overhead of a program running, to make things slower. As a computer engineer, I do like that feature, as it means that people will go out to buy more complex hardware.
There are some programming languages that really do have features that help write very very stable, unbuggy code. I would say ADA, ML, and LISP fall in these catagories. But even in these languages, the language can only do so much. In the end, your program will only be as good as your programmer.
We STILL live in the dungeon of ancient functional thought. And sadly, attitudes like yours ("why not just use C?") help promote this.
Actually, we have gotten out of the use of functional languages like LISP and replaced them with procedural languages like C. Which is good! That's what your computer does anyway. Though most functional languages do a very good job of implementing themselves in a procedural system... stacks are pretty simple things.
But I bet you're one of those OO people. You think that OO is the greatest thing and that if everyone used it to write their programs, the world would be a fantastic place.
There's a place for OO languages. They do some things well. Some things they do very badly. And in the end, OO languages are still only as good as the programmer. And they have enough problems and complexities that for things like flight control, they aren't always appropriate.
Let me tell you a little story. There was once a class that was trying to make a robot arm play ping-pong. There was a camera that could see the ball, and then the software computed where the paddle should be, then was supposed to move there so that the ball would return to the other side. The software was written in a "safe" language.
When they went to test the robot arm, the ball flew straight past it. The arm didn't budge. They looked at each other, wondering what the bug was, until a few seconds later the arm moved to where it should have gone.
The problem was the environment. After doing the complex computations, the garbage collector decided it needed to clean up all the memory used for the calculations. Once the garbage collector had finished, the arm was allowed to move, but by that time it was too late.
And to finish off, let me tell you the one thing that bugs me about most languages: THEY DON'T HAVE BUILTIN MACRO PROCESSORS. Macros in C are the most useful thing about the language, in my opinion. Not having them is a horrible travesty.
Nobody cares. That's not how people use numbers.
Sure, it's easy to figure out that there are 100,000 cm in a km. But when was the last time you referred to the distance between two cities or two houses in terms of centemeters? "Oh yeah, he's 23,000 cm down the road."
Not to say that the US system is logical. For "everyday use", however, the metric system doesn't really have any advantages. On the one hand, you have fewer units to use. On the other hand, you have fewer units to use. Just think about the units used in cooking. Lots of units help you remember recipies... and even in metric you still use non-standard measurements (chickens don't lay standard 100g eggs, and "dash" and "clove" aren't SI units).
Have a part of the event where students who have written their own video games or video game mods can demo them... it'd be encouragement to do something educational!
The GNU Project says, "Please give our project equal mention," but Linus says, "Don't give them a share of the credit; call the whole thing after my name alone!"
To my knowledge, Linus hasn't really said this.
He has, I believe, said that the kernel should be called "linux" (and that you can pronounce it however you like, just use it).
I think he thinks (and is correct that) GNU/XFree86/KDE/Linux doesn't have the same ring to it that "linux" has; I also think he thinks that it's fine when people say "I run debian" or "I run redhat" instead of "I run Debian Linux" or "I run Debian GNU/Linux".
Linus has always seemed much more laied-back than RMS. RMS gets angry when things aren't done his way, because he is convicted about his beliefs. Many people who are extremely convicted about good things are difficult to get along with, even with they are "right".
The theory is:
If the ice caps recede, so will glaciers, releasing land for use.
I've seen the figure that if all the ice caps and glacial areas melted, the ocean levels would rise
only a few inches, not enough to be overly problematic.
It is true that most ice is floating, and so wouldn't cause the sea levels to rise any (don't believe me? Fill up a glass of ice water so that the ice cube is sticking out the top and the water is at the brim... and let it melt. The water level will remain constant (minus evaporation).
Another theory is that we're coming off of an ice age and so the warming is natural. Given the quality of information I think that probably saying the Truth of being at the end of an ice age or overdue for another one is probably more hype than science.
My theory is: Polluting isn't a good idea, but on the other hand, there's no reason to go shoot myself immediately because Waterworld won't happen next year.
EPIC/VLIW and superscalar architectures boil down to the same thing. However, with a sinle thread of execution, you are still extremely limited; typically you have only a few instructions in a loop and are very limited in how much parallelism you can actually do.
The idea behind chip multiprocessors is that instead of trying to execute a single execution thread really fast (which is what current chips do) you should try to execute many threads slower.
This has lots of advantages, but the big disadvantage is it's very hard for most applications that demand lots of performance. And you need lots of memory bandwith.
Think about 2- and 4-processor PCs. They don't help you very much for your video game, because it's typically one thread of execution. Where do 2-way and 4-way (and 64-way) systems really help out? When you are running many seperate processes. If you can divide things up into many tasks you can get great benefit over a sinle core, but if you have a single thread that needs to go fast it (usually) doesn't go fast.
To a certain extent, this is done in game systems... there are different parts to do audio, video, and "general". They use "distributed processing" in that they distribute the tasks to different parts. My guess is that they are investigating how to do this type of thing on a much larger scale.
The PS2 is a highly parallel machine, however it's
explicitly ILP and DLP-parallel. So, you have DLP-type instructions
(like MMX or AltiVec or whatnot) and you also have it executing several instructions per execution set (VLIW).
This parallelism is typically very different than
thread-level parallelism, as it isn't as easy to
communicate over a network to another processor as it is to just pass
things from one instruction to another throug a register.
However there is interestin research in doing fun stuff with multiprocessors. So who knows what will happen...
Generating fast traditional processors is getting harder and harder to do. Look how fast a P4 is compared to a P3 or a P2, in terms of actual performance per transistor count. It sucks. In fact, per transistor count, smaller, simpler chips (386) do better. Since most of the performance improvement in chips comes from process migration instead of architecture (386s would run a lot faster in a.13 micron process...) one idea is to put a bunch of simple processors on a single chip.
There are several problems with this. Memory bandwith, power consumption, etc... but the main one is that most normal applications are written for a single thread.
Imagine how many MIPS 4K cores you can fit in 300mm^2 in 4-5 years. That's a lot of power. Sure, they might only run at 1-2Ghz, but there will be 64 of them on a die. If you can harness that power, it might give your game developers much of that huge performance boost they want.
Think beowulf-cluster-on-a-chip. As with multiple-workstation distributed computing clusters, the trick is not in setting the thing up, but in figuring out how to distribute your work.
This has great potential in the realm of practical jokes.
Imagine sucking this to the underside of someone's desk way back in the knee well. Then attach it to a radio and a timer device that will randomly turn on the radio for a few seconds every few hours.
Imagine attaching this to the door of the person who was making loud, annoying noises with a POTAS whilst you were trying to sleep, and waking them up when you have to go to your 8:00 class!
The possibilities for this device are truely limitless.
I don't agree with this author's assessment. The type of "parallelism" involved in the AltiVec is SIMD -- single instruction, multiple data.
Right, DLP (Data Level Parallelism) instructions. Exploiting parallelism in the data rather than the instructions. The G4 actually has a really nice set of DLP instructions, and some of the "Single Instructions" (from what I understand) actually allow you to do different operations on different parts of data -- wich is nice.
The G4 also has ILP features -- it's a superscalar architecture can issue several instructions in a given cycle.
But the ILP features are done automatically in hardware, and hardware doesn't have the "big picture" that the compiler (or person writing assembly code) has. Architectures that define parallelism explicitly (like VLIW (EPIC) architectures) tell the hardware what can go in parallel and what can't. Unfortunately, the compilers for VLIW architectures have a hard enough time doing good ILP code; DLP code is even harder.
For instance, you have c code:
c = a+b;
d = e+f;
Say that these are in packed words in the register file. Perhaps the compiler can write "add2 r0,r1,r2" and do both of the adds at the same time. It should be even easier to not keep track of packed words and say "add r0,r1,r2 & add r3,r4,r5", where add instructions are explicitly defined as running at the same time. And compilers can usually do this OK. It's very hard for compilers to software pipeline loops and such, which is what provides the biggest benefit.
You could get very reasonable vectorized performance for most numerically intensive codes straight out of the compiler, without any modifications at all. With a bit of profiling and additional compiler
directives, you could get excellent performance indeed.
But GNU C isn't designed to be a vector compiler, it's designed for single-issue, non-DLP (SIMD == DLP) architectures. Sure, giving it vector and DLP or ILP resources might let it use the things once in a while, but for the most part it will go unused.
Don't expect huge speedups everywhere without hand-tuned libraries.
Parallelism is really, really, really hard to
do in a compiler. Intel has a hard time doing it
even after spending millions for a compiler on
their VLIW architecture. DLP is typically even
harder than ILP for a compiler to do.
Compilers can typically do a pretty good job on
sequential machines, but there is still a long
way to go for getting good parallel code. Hand
coding things is still the way to go for maximum
performance.
That being said, the compiler can probably use it some, and having a resource available is typically better than not having the resource at all.
Abortions in the third trimester are generally considered unethical (if it could have been avoided) because the (baby|fetus) is to the "viability" point... it is possible that it could survive on its own outside of the mother.
This device makes it possible for (baby|fetus)s to reach this "viability" mark much earlier...
I don't want to start a flame war, but what effect do you think technological advances such as these will have on ethics relating to unborn children/fetuses?
So much for your insane idea of having to update 1024 machines.
Instead your 'easy' linux solution becomes 1024 times more work than the mac solution.
Having been an administrator for an environment involving thousands of diverse UNIX machines in use as desktops, I think I know a bit or two about keeping systems updated.
Netbooting machines is alright, however in the High Performance Cluster I worked with we were very bandwith constrained, and having the machines not netboot eased the network congestion considerably.
Anyway, It's not hard to update your unix machines every day... just put an update script in root's crontab. Need to do something for every host?
Thanks to Apple's Software Upgrade control panel program, this can all take place automatically according to any schedule you desire. Two clicks of a mouse is all it takes to set this up
My point exactly.
Two clicks in a control panel for 1024 computers is too hard to manage, you need better remote access.
However, I am sorry. I was under the impression that you had to pay for the OS X.1 upgrade and that it came on a CD.
The PDF tells you to set up all your machines on the network, install their utility on all the machines, and then "simply" use a program that is designed to run on their infrastructure.
Comparatively, the Beowulf books talk about what kind of network infrastructure you'll want for different types of applications, different standard communication libraries to use between the nodes, automatic administration of nodes, how to make redundant nodes, etc.
You also want to have an infrastructure for automatically loading software on computers, perhaps booting off the network... none of this is available on that PDF. Perhaps even not possible.
And you won't get very far telling me that it's easier to upgrade OS X to OS X.1 or whatever where you have to go around with a CD and reboot every computer on a 1024-node cluster, compared with just having them all "apt-get dist-upgrade"
In a nutshell: if you need a high-performance computing cluster, you need to go with a Linux-based beowulf cluster. Perhaps on Apple hardware, perhaps on Alpha, probably on x86. If, on the other hand, you want a toy that can run a fractal program really fast (perhaps povray too) and don't have a real application then this Mac cluster is probably what you need.
I have one application that I use that I compile with a target-specific compiler. I use SparcWorks at Work to compile our development tool when I need to do big, long jobs. We do most of the main development with GCC. Why?
GCC is a good compiler. It has some handy extra features (macro varargs), produces sensible warnings, and works "good enough" for most development. It also works nicely with gdb.
The GNU tools are extremely robust. There have been several times when I've had to go in and change things due to bugs (limitations) with Solaris sed or cc. Like trying to get sed to work on the really long lines of text that the preprocessor generates sometimes.
The GNU tools are there on all platforms. I can, without modifying the Makefile significantly, compile the same tool on my Windows box, or a Linux or Mac box that someone might have at home.
And, the most important reason why I, like most people, don't need Intel's CC on a regular basis:
Usually, SPEED DOESN'T MATTER. Okay, so you compile your kernel and all your apps with intel's compiler. My computer (duron 600) is fast enough for what I need to do: editing files with vim, browsing the web with Galeon, playing music and video clips, SSHing to other computers. rc5des gets most of my CPU time. If I needed a perforance boost in the CPU, I could easily get one with 2x the performance for cheap. But for now I don't.
Sure, there are applications where speed is important, and for those having a platform-specific fast compiler can help. For most things, though, the advances in CPU performance has made the need for an ultra-optimized compiler somewhat useless for most applications that people use.
If your vim is slow, it's probably due to a slow disk or insufficient memory on your long file. If your galeon is slow, it's probably due to insufficient memory or low bandwith. A new compiler probably won't help you.
Hyper-threading allows two threads to run on the same pipeline. It has some advantages and some disadvantages. I believe the poster was referring to more along the lines of a CMP (Chip MultiProcessor) where there are actually destinct cores, caches, etc.
I'm just amazed that an introductory class for _everyone_ manages to get as far as non-trivial assignments -- unless Georgia Tech simply accepts that certain freshman aren't going to
make it..
Georgia Tech is a great school. It does things the right way. It's fairly easy to get in, but it's non-trivial to pass. Those who don't put in the effort don't pass.
About 1/3 of the freshmen fail out or transfer out.
Contrast this to Harvard (note: I haven't gone to Harvard, but my friend did and this is what she told me) where they are very selective for admissions, but they make it much easier to pass -- it's still hard to do well, but easier to slide by. At GT they curve around a C in many classes (as many people get Fs as As), instead of a B (more people get As than Fs-Cs).
Because you're completely wrong. The bug is with the Athlon processors not performing to spec regarding 4M pages. There was a workaround patch by AMD for Windows 2000 because Win2k was the only OS AMD knew about that used 4M pages. Linux uses them in some situations as well, and (until now) the developers were unaware of the bug.
Slashdot Mirror
haha... your sig. they say "moof" :-)
For one thing, I doubt you grasp the "x86" architecture as it is known today. You think you know what you're talking about due to slashdot and Apple ads. The x86 architecture doesn't really exist. No modern processor executes x86 instructions. The overhead of doing translation is minimal. And Intel and AMD have shown that doing their own cores and the translation from x86 to them produces amazingly fast chips. Intel and AMD can continue to do x86-ish architectures (and will; I think hammer will be big and turn out to perform better than Intel's IA64 chips) and the performance will be as good as an architecture without the x86ish syntax.
For another thing, for someone who claims to know about PCs, how can you not get the parts to work together correctly? Get revision 2, non-cutting edge motherboard, CPU, hard drive(s), graphics card and a $10 NIC and you have my computer, which has had no problems during either configuration or while running. And those "wal-mart shitboxes" that you speak of are pretty much the same. They're not top-of-the-line, but the parts -- standard motherboard chipset, standard cpu, generic video, PCI bus -- are well supported by free unices and pretty darn stable.
My experience has been: I can put together parts that, for the most part, are the cheapest ones available (or close to it) and get a computer that works seamlessly and flawlessly. (Maybe not in Windows, though)
Oh well... what do you expect from a f lamer
Sorry, what I meant was that the object paradigm allows for invalid references. In Java I can have a reference that doesn't point to a valid object, and if I dereference it I can get a NullPointerException. This is, of course, a separate issue from the garbage collector.
"Memory management" from the point of view of the programmer, not that of the environment. That of how you manage your storage.
You act as though C is responsible for a stack overflow or pointer pointing problems.
You wanna know something: IT'S THE PROGRAMMER.
You can write huge applicatations in plain ANSI C. They can run flawlessly. As long as you use good programming practices and have good programmers.
Excepting buggy compilers or libraries (very rare in my experience), when you write something in C and it doesn't work, it's your fault. C is very simple, elegant, and deterministic. For examples of C programs that work very well, see UNIX OS kernels, most of the system tools on UNIX, and especially TeX.
You can write perfect programs in some "more modern" languages ("safe" languages like Java) that will crash, because the environment is so complex that many environments are buggy. This is unacceptable. Not only that, most of these languages aren't any better than C as far as memory management (That's why all the Java programs I see crash with "NullPointerException").
These new languages, however, do increase the overhead of a program running, to make things slower. As a computer engineer, I do like that feature, as it means that people will go out to buy more complex hardware.
There are some programming languages that really do have features that help write very very stable, unbuggy code. I would say ADA, ML, and LISP fall in these catagories. But even in these languages, the language can only do so much. In the end, your program will only be as good as your programmer.
Actually, we have gotten out of the use of functional languages like LISP and replaced them with procedural languages like C. Which is good! That's what your computer does anyway. Though most functional languages do a very good job of implementing themselves in a procedural system... stacks are pretty simple things.
But I bet you're one of those OO people. You think that OO is the greatest thing and that if everyone used it to write their programs, the world would be a fantastic place.
There's a place for OO languages. They do some things well. Some things they do very badly. And in the end, OO languages are still only as good as the programmer. And they have enough problems and complexities that for things like flight control, they aren't always appropriate.
Let me tell you a little story. There was once a class that was trying to make a robot arm play ping-pong. There was a camera that could see the ball, and then the software computed where the paddle should be, then was supposed to move there so that the ball would return to the other side. The software was written in a "safe" language.
When they went to test the robot arm, the ball flew straight past it. The arm didn't budge. They looked at each other, wondering what the bug was, until a few seconds later the arm moved to where it should have gone.
The problem was the environment. After doing the complex computations, the garbage collector decided it needed to clean up all the memory used for the calculations. Once the garbage collector had finished, the arm was allowed to move, but by that time it was too late.
And to finish off, let me tell you the one thing that bugs me about most languages: THEY DON'T HAVE BUILTIN MACRO PROCESSORS. Macros in C are the most useful thing about the language, in my opinion. Not having them is a horrible travesty.
Nobody cares. That's not how people use numbers. Sure, it's easy to figure out that there are 100,000 cm in a km. But when was the last time you referred to the distance between two cities or two houses in terms of centemeters? "Oh yeah, he's 23,000 cm down the road."
Not to say that the US system is logical. For "everyday use", however, the metric system doesn't really have any advantages. On the one hand, you have fewer units to use. On the other hand, you have fewer units to use. Just think about the units used in cooking. Lots of units help you remember recipies... and even in metric you still use non-standard measurements (chickens don't lay standard 100g eggs, and "dash" and "clove" aren't SI units).
Have a part of the event where students who have written their own video games or video game mods can demo them... it'd be encouragement to do something educational!
To my knowledge, Linus hasn't really said this.
He has, I believe, said that the kernel should be called "linux" (and that you can pronounce it however you like, just use it).
I think he thinks (and is correct that) GNU/XFree86/KDE/Linux doesn't have the same ring to it that "linux" has; I also think he thinks that it's fine when people say "I run debian" or "I run redhat" instead of "I run Debian Linux" or "I run Debian GNU/Linux".
Linus has always seemed much more laied-back than RMS. RMS gets angry when things aren't done his way, because he is convicted about his beliefs. Many people who are extremely convicted about good things are difficult to get along with, even with they are "right".
The theory is: If the ice caps recede, so will glaciers, releasing land for use. I've seen the figure that if all the ice caps and glacial areas melted, the ocean levels would rise only a few inches, not enough to be overly problematic. It is true that most ice is floating, and so wouldn't cause the sea levels to rise any (don't believe me? Fill up a glass of ice water so that the ice cube is sticking out the top and the water is at the brim... and let it melt. The water level will remain constant (minus evaporation). Another theory is that we're coming off of an ice age and so the warming is natural. Given the quality of information I think that probably saying the Truth of being at the end of an ice age or overdue for another one is probably more hype than science. My theory is: Polluting isn't a good idea, but on the other hand, there's no reason to go shoot myself immediately because Waterworld won't happen next year.
The idea behind chip multiprocessors is that instead of trying to execute a single execution thread really fast (which is what current chips do) you should try to execute many threads slower.
This has lots of advantages, but the big disadvantage is it's very hard for most applications that demand lots of performance. And you need lots of memory bandwith.
Think about 2- and 4-processor PCs. They don't help you very much for your video game, because it's typically one thread of execution. Where do 2-way and 4-way (and 64-way) systems really help out? When you are running many seperate processes. If you can divide things up into many tasks you can get great benefit over a sinle core, but if you have a single thread that needs to go fast it (usually) doesn't go fast.
To a certain extent, this is done in game systems... there are different parts to do audio, video, and "general". They use "distributed processing" in that they distribute the tasks to different parts. My guess is that they are investigating how to do this type of thing on a much larger scale.
This parallelism is typically very different than thread-level parallelism, as it isn't as easy to communicate over a network to another processor as it is to just pass things from one instruction to another throug a register.
However there is interestin research in doing fun stuff with multiprocessors. So who knows what will happen...
Anyway, regardless of actual chip area, the theory is the same... in general, several tiny processors can be better than a single big one.
There are several problems with this. Memory bandwith, power consumption, etc... but the main one is that most normal applications are written for a single thread.
Imagine how many MIPS 4K cores you can fit in 300mm^2 in 4-5 years. That's a lot of power. Sure, they might only run at 1-2Ghz, but there will be 64 of them on a die. If you can harness that power, it might give your game developers much of that huge performance boost they want.
Think beowulf-cluster-on-a-chip. As with multiple-workstation distributed computing clusters, the trick is not in setting the thing up, but in figuring out how to distribute your work.
Imagine sucking this to the underside of someone's desk way back in the knee well. Then attach it to a radio and a timer device that will randomly turn on the radio for a few seconds every few hours.
Imagine attaching this to the door of the person who was making loud, annoying noises with a POTAS whilst you were trying to sleep, and waking them up when you have to go to your 8:00 class!
The possibilities for this device are truely limitless.
Do they count the day that Christians profess faith or something?
Maybe they have conception day on there, too?
Or does it hold other people's birthdays?
Can it beep to remind you that it's your friend's birthday and you're a big slacker and didn't get them a present?
It would be like an ID card and PDA in one!
Right, DLP (Data Level Parallelism) instructions. Exploiting parallelism in the data rather than the instructions. The G4 actually has a really nice set of DLP instructions, and some of the "Single Instructions" (from what I understand) actually allow you to do different operations on different parts of data -- wich is nice.
The G4 also has ILP features -- it's a superscalar architecture can issue several instructions in a given cycle.
But the ILP features are done automatically in hardware, and hardware doesn't have the "big picture" that the compiler (or person writing assembly code) has. Architectures that define parallelism explicitly (like VLIW (EPIC) architectures) tell the hardware what can go in parallel and what can't. Unfortunately, the compilers for VLIW architectures have a hard enough time doing good ILP code; DLP code is even harder.
For instance, you have c code:
Say that these are in packed words in the register file. Perhaps the compiler can write "add2 r0,r1,r2" and do both of the adds at the same time. It should be even easier to not keep track of packed words and say "add r0,r1,r2 & add r3,r4,r5", where add instructions are explicitly defined as running at the same time. And compilers can usually do this OK. It's very hard for compilers to software pipeline loops and such, which is what provides the biggest benefit.But GNU C isn't designed to be a vector compiler, it's designed for single-issue, non-DLP (SIMD == DLP) architectures. Sure, giving it vector and DLP or ILP resources might let it use the things once in a while, but for the most part it will go unused.
Don't expect huge speedups everywhere without hand-tuned libraries.
Compilers can typically do a pretty good job on sequential machines, but there is still a long way to go for getting good parallel code. Hand coding things is still the way to go for maximum performance.
That being said, the compiler can probably use it some, and having a resource available is typically better than not having the resource at all.
This device makes it possible for (baby|fetus)s to reach this "viability" mark much earlier...
I don't want to start a flame war, but what effect do you think technological advances such as these will have on ethics relating to unborn children/fetuses?
Having been an administrator for an environment involving thousands of diverse UNIX machines in use as desktops, I think I know a bit or two about keeping systems updated.
Netbooting machines is alright, however in the High Performance Cluster I worked with we were very bandwith constrained, and having the machines not netboot eased the network congestion considerably.
Anyway, It's not hard to update your unix machines every day... just put an update script in root's crontab. Need to do something for every host?
for host in `cat /etc/host_list` ; do ; done.
My point exactly.
Two clicks in a control panel for 1024 computers is too hard to manage, you need better remote access.
However, I am sorry. I was under the impression that you had to pay for the OS X.1 upgrade and that it came on a CD.
Comparatively, the Beowulf books talk about what kind of network infrastructure you'll want for different types of applications, different standard communication libraries to use between the nodes, automatic administration of nodes, how to make redundant nodes, etc.
You also want to have an infrastructure for automatically loading software on computers, perhaps booting off the network... none of this is available on that PDF. Perhaps even not possible.
And you won't get very far telling me that it's easier to upgrade OS X to OS X.1 or whatever where you have to go around with a CD and reboot every computer on a 1024-node cluster, compared with just having them all "apt-get dist-upgrade"
In a nutshell: if you need a high-performance computing cluster, you need to go with a Linux-based beowulf cluster. Perhaps on Apple hardware, perhaps on Alpha, probably on x86. If, on the other hand, you want a toy that can run a fractal program really fast (perhaps povray too) and don't have a real application then this Mac cluster is probably what you need.
- GCC is a good compiler. It has some handy extra features (macro varargs), produces sensible warnings, and works "good enough" for most development. It also works nicely with gdb.
- The GNU tools are extremely robust. There have been several times when I've had to go in and change things due to bugs (limitations) with Solaris sed or cc. Like trying to get sed to work on the really long lines of text that the preprocessor generates sometimes.
- The GNU tools are there on all platforms. I can, without modifying the Makefile significantly, compile the same tool on my Windows box, or a Linux or Mac box that someone might have at home.
And, the most important reason why I, like most people, don't need Intel's CC on a regular basis:Sure, there are applications where speed is important, and for those having a platform-specific fast compiler can help. For most things, though, the advances in CPU performance has made the need for an ultra-optimized compiler somewhat useless for most applications that people use.
If your vim is slow, it's probably due to a slow disk or insufficient memory on your long file. If your galeon is slow, it's probably due to insufficient memory or low bandwith. A new compiler probably won't help you.
Hyper-threading allows two threads to run on the same pipeline. It has some advantages and some disadvantages. I believe the poster was referring to more along the lines of a CMP (Chip MultiProcessor) where there are actually destinct cores, caches, etc.
You still working out there in Hades?
I've got a nice cushy architecture job! w00t!
Georgia Tech is a great school. It does things the right way. It's fairly easy to get in, but it's non-trivial to pass. Those who don't put in the effort don't pass.
About 1/3 of the freshmen fail out or transfer out.
Contrast this to Harvard (note: I haven't gone to Harvard, but my friend did and this is what she told me) where they are very selective for admissions, but they make it much easier to pass -- it's still hard to do well, but easier to slide by. At GT they curve around a C in many classes (as many people get Fs as As), instead of a B (more people get As than Fs-Cs).
Get back in your hole, you troll!