Many algorithms don't scale using a message-passing paradigm. They can be implemented and will produce correct results, but the overhead of passing around the messages overwhelms the benefits of parallelism. Message passing is fine for coarse-grain parallelism, but it's not practical for fine-grain parallelism.
But they have it ranked as C, which I assume is average entry difficulty. According to their numbers, there are about 95,000 professor positions open every year. But that's not the whole picture: only a small fraction of that 95,000 are positions open to a particular person. In order to be a professor, you need to have a relatively narrow expertise. There will be few professor positions open in the country that want your particular expertise.
I also think they underestimate the stress level of getting tenure. Getting tenure is a cutthroat process.
For the record, I am a Computer Science graduate student.
Yes, Dell has to engineer the system itself as well. Not much has to go into a desktop, but a laptop or all-in-one is not simply a matter of slapping parts together. Apple probably puts more time and money into it than Dell, though. The iMac required a significant amount of engineering and design, probably more than a typical laptop.
Apple's move to Intel hardware, and especially its decision to use off-the-shelf Intel chipsets, demonstrates that Apple has decided to leave the heavy hardware engineering to someone else, and concentrate instead on software.
I don't understand your point. All they did was switch IBM's G5s for Intel's Core. I don't see how this changes their focus as a company; they still have to engineer the system itself.
OOOE has amazing potential Which has been realized for about the past 20 years. Exploiting Instruction Level Parallelism (which requires an out-of-order-execution processor) has gotten us to where we are today. We're reaching the limits of what ILP can buy us, so the solution is to put more cores on a chip.
It may be possible to integrate OOOE into a multicore. It is possible, and every single Intel multicore chip has done it. Same with IBM's Power5s. For general-purpose multicore processors, that is the norm.
Well, I think there are experts who claim Linux violates our intellectual property. I'm not going to comment. But to the degree that that's the case, of course we owe it to our shareholders to have a strategy. And when there is something interesting to say, you'll be the first to hear it.
is not a threat. Balmer was directly asked if what Microsoft would do if their IP showed up in Linux, and he gave a typical non-answer.
Re:Webmail is a technological step backwards
on
Gmail vs Pine
·
· Score: 1
If anybody but those that know me read my Gmail account, they would be very, very bored. It's not worth the troulbe to encrypt my personal email. I don't gain any worthwhile "power" by using a fat email client.
I use Gmail for convenience. I can check my personal email from anywhere, home, office, friend's houses or public labs. There is no feature in a fat client that trumps that convenience.
But I do not for a second believe that the Revolution is a replacement for the XBOX 360 or the PS3.
Nintendo's stated goal is to not compete with the PS3 and the 360. With a rumored initial price of $100, they might actually be able to achieve that goal.
You're missing the point. They didn't intend to come up with a model that could predict the outcome of individual relationships. They wanted to see if they could come up with a mathematical model that exhibited the same characteristics of social networks - that is, a large number of social interactions, not invidivual relationships.
Re:The nature of friendship changes over time.
on
The Physics of Friendship
·
· Score: 2, Insightful
I have very close friends from high school (one is actually from my middle school days) that as far as I'm concerned, are family. I also formed very close friendships in college. Your high school experiences don't necessarily map to others.
I disagree that science is arbitrary. It's the only system we have which works reliabley for figuring out how the universe works. That grants it a special status. Special enough, in fact, that we think it's important enough to teach from elementary school on up to high school.
I think his point is more that if you're going to ascribe to the "teach the debate" line, then you should first teach what science is. How can they understand a scientific debate if they don't even know what science really is?
Just because some guy on website finds it hard doesn't mean nobody can do it.
It's not just some guy on a website. The main problem he's talking about - taking high level code without explicit parallelization and discovering parallelism during compilation - is a difficult research problem.
It's not that it's can't be done, it's more that it hasn't been done. I'm not aware of any particular proof of why it's impossible, but I am aware of many of the reasons why it's extremely difficult. The most I've seen a compiler do on its own is recognize that a simple loop could be vectorized (Intel's compiler does this). But other than that, if you want parallel code, you need to parallelize it yourself.
Auto-parallelizing compilers have been a holy-grail type problem for a while. On the other hand, there are facilities such as OpenMP which can buy you a lot of power with little programmer cost. Doing complex tasks in OpenMP is complex just like any other programming model, but simple parallelization remains simple. There are many, many parallel languages, but I think OpenMP might become the standard shared-memory programming model because it fits on top of a language (C and Fortran) instead of supplanting it.
Re:The e-mail I sent to the editor was ignored.
on
No Time Travel, Sorry
·
· Score: 1
I read some of the article and some of the site. I was trying to figure out if the guy was being sincere or satiric. I never got an indication that anything was said tongue-in-cheek. If he is being satiric, he's not doing a good job of it.
Publicly traded corporations have one duty -- to make profit.
We (as in the public, which the government represents) allow corporations to exist because, in theory, they are good for society. So, no, their sole goal is not to make a profit. They also have a responsibility to the public. While I'm not aware of it ever happening in practice, the government has the power to revoke a corporation's charter if it does not act in the interest of the public.
I understand and share your cynicism, but nowhere does it say that corporations must pursue profit to the deteriment of all else.
I think the problem here is that people are attributing the wrong meaning to the statistics the kernel is reporting. Nowhere does it (or the man pages for ps or top) claim that the memory statistics it reports for a process is the same amount of memory you'll get back when you kill that process. The information is not deceptive; it's an accurate representation of the sate of the system.
I don't know how your jvm implements threads, but if it's like LinuxThreads and each thread gets its own PID, then yes, naively looking at top or ps won't tell you the whole story because each thread is reported as a seperate process when it's not. You have to account for the fact that all of those threads are sharing the same address space.
Keep in mind that when you say "ps is at best deceptive, if not actually wrong" that you're implying that the Linux kernel is at best deceptive, if not wrong, about the memory usage it reports. All ps and top do is query the kernel; they're not coming up with these numbers on their own. The kernel, and by extension ps and top, are reporting the correct numbers for a Linux system. If you attribute different meaning to those numbers, then that's your fault, not the fault of the tools you're using.
Each thread in a process shows up as consuming the same amount of memory (either this only happens under Linuxthreads or I don't have any threaded applications running on my system).
Under LinuxThreads, each thread had its own PID. Under NPTL (Native POSIX Thread Library) all threads from the same process share the same PID, but each thread has a unique TID (which you can get with the Linux specific call gettid()). Calling getconf GNU_LIBPTHREAD_VERSION from a prompt should tell you what library and version you're running for pthread support.
Anyway, this is a round-a-bout way of saying you're right. Since LinuxThreads uses a unique PID for each thread, if you queried the kernel for memory info, it would tell you that each process (thread) was invidivually consuming xKb. That's non-intuitive behavior, but I think the blame belonged to LinuxThreads, not the kernel; LinuxThreads was abusing the concept of a PID. Thankfully this has been changed in NPTL.
It is clear and concise, assuming you have a basic understanding of how virtual memory works in an operating system. The kernel is simply reporting the statistics it keeps track of for use in memory management policies. Your analogy doesn't work because you're just comparing human-intuitive units to non-intuitive units. However, the concept of "How fast am I going?" is simpler than "What is the memory usage of a process?" A more complex question requires a more involved answer.
Run top. Check out the column that says SHR. Subtract it from VIRT if you want to know the virtual memory usage of a process excluding shared libraries, or subtract it from RES if you want to know the physical memory usage of a process excluding shared libraries. Problem solved.
I don't like how he phrases that what ps reports is "wrong." It's not wrong, or even "wrong." It reports exactly what Linux tells it (through the proc filesystem). It's just might not be what you expect it to be, which means you don't understand the tools and the system. When ps reports that a process' virtual memory usage is xKb, that is correct. In the address space for the process, xKb have been allocated. Shared or not, they're still in the address space.
I care because being able to multithread an application like gcc would be a very big deal. The parent did mention multithreaded compilers, only he did it implicity and without understanding what was actually happening.
Those are not "parallel gcc's". They are sequential (sequential meaning non-multithreaded) gcc processes spawned at the same time. This is different from gcc itself being parallel.
make is different than gcc. One is a compiler. The other is a program which takes a dependecy file and calls the compiler in the correct way such as to maintain the dependencies. Parallelizing make is trivial: whoever wrote the makefile has already written out the dependencies for you. If two rules don't depend on each other, they can execute at the same time. This is an entirely different beast from parallelizing the compiler itself.
Slashdot Mirror
Many algorithms don't scale using a message-passing paradigm. They can be implemented and will produce correct results, but the overhead of passing around the messages overwhelms the benefits of parallelism. Message passing is fine for coarse-grain parallelism, but it's not practical for fine-grain parallelism.
But they have it ranked as C, which I assume is average entry difficulty. According to their numbers, there are about 95,000 professor positions open every year. But that's not the whole picture: only a small fraction of that 95,000 are positions open to a particular person. In order to be a professor, you need to have a relatively narrow expertise. There will be few professor positions open in the country that want your particular expertise.
I also think they underestimate the stress level of getting tenure. Getting tenure is a cutthroat process.
For the record, I am a Computer Science graduate student.
Yes, Dell has to engineer the system itself as well. Not much has to go into a desktop, but a laptop or all-in-one is not simply a matter of slapping parts together. Apple probably puts more time and money into it than Dell, though. The iMac required a significant amount of engineering and design, probably more than a typical laptop.
Apple's move to Intel hardware, and especially its decision to use off-the-shelf Intel chipsets, demonstrates that Apple has decided to leave the heavy hardware engineering to someone else, and concentrate instead on software.
I don't understand your point. All they did was switch IBM's G5s for Intel's Core. I don't see how this changes their focus as a company; they still have to engineer the system itself.
OOOE has amazing potential
Which has been realized for about the past 20 years. Exploiting Instruction Level Parallelism (which requires an out-of-order-execution processor) has gotten us to where we are today. We're reaching the limits of what ILP can buy us, so the solution is to put more cores on a chip.
It may be possible to integrate OOOE into a multicore.
It is possible, and every single Intel multicore chip has done it. Same with IBM's Power5s. For general-purpose multicore processors, that is the norm.
If anybody but those that know me read my Gmail account, they would be very, very bored. It's not worth the troulbe to encrypt my personal email. I don't gain any worthwhile "power" by using a fat email client.
I use Gmail for convenience. I can check my personal email from anywhere, home, office, friend's houses or public labs. There is no feature in a fat client that trumps that convenience.
But I do not for a second believe that the Revolution is a replacement for the XBOX 360 or the PS3.
Nintendo's stated goal is to not compete with the PS3 and the 360. With a rumored initial price of $100, they might actually be able to achieve that goal.
You're missing the point. They didn't intend to come up with a model that could predict the outcome of individual relationships. They wanted to see if they could come up with a mathematical model that exhibited the same characteristics of social networks - that is, a large number of social interactions, not invidivual relationships.
I have very close friends from high school (one is actually from my middle school days) that as far as I'm concerned, are family. I also formed very close friendships in college. Your high school experiences don't necessarily map to others.
I disagree that science is arbitrary. It's the only system we have which works reliabley for figuring out how the universe works. That grants it a special status. Special enough, in fact, that we think it's important enough to teach from elementary school on up to high school.
I think his point is more that if you're going to ascribe to the "teach the debate" line, then you should first teach what science is. How can they understand a scientific debate if they don't even know what science really is?
Just because some guy on website finds it hard doesn't mean nobody can do it.
It's not just some guy on a website. The main problem he's talking about - taking high level code without explicit parallelization and discovering parallelism during compilation - is a difficult research problem.
You missed the point. By using threads, you parallelized the program already. You can get the same effect by using, say, C and POSIX threads.
Although in Java applications, using multiple threads is often more about good design rather than good performance.
It's not that it's can't be done, it's more that it hasn't been done. I'm not aware of any particular proof of why it's impossible, but I am aware of many of the reasons why it's extremely difficult. The most I've seen a compiler do on its own is recognize that a simple loop could be vectorized (Intel's compiler does this). But other than that, if you want parallel code, you need to parallelize it yourself.
Auto-parallelizing compilers have been a holy-grail type problem for a while. On the other hand, there are facilities such as OpenMP which can buy you a lot of power with little programmer cost. Doing complex tasks in OpenMP is complex just like any other programming model, but simple parallelization remains simple. There are many, many parallel languages, but I think OpenMP might become the standard shared-memory programming model because it fits on top of a language (C and Fortran) instead of supplanting it.
I read some of the article and some of the site. I was trying to figure out if the guy was being sincere or satiric. I never got an indication that anything was said tongue-in-cheek. If he is being satiric, he's not doing a good job of it.
Publicly traded corporations have one duty -- to make profit.
We (as in the public, which the government represents) allow corporations to exist because, in theory, they are good for society. So, no, their sole goal is not to make a profit. They also have a responsibility to the public. While I'm not aware of it ever happening in practice, the government has the power to revoke a corporation's charter if it does not act in the interest of the public.
I understand and share your cynicism, but nowhere does it say that corporations must pursue profit to the deteriment of all else.
I think the problem here is that people are attributing the wrong meaning to the statistics the kernel is reporting. Nowhere does it (or the man pages for ps or top) claim that the memory statistics it reports for a process is the same amount of memory you'll get back when you kill that process. The information is not deceptive; it's an accurate representation of the sate of the system.
I don't know how your jvm implements threads, but if it's like LinuxThreads and each thread gets its own PID, then yes, naively looking at top or ps won't tell you the whole story because each thread is reported as a seperate process when it's not. You have to account for the fact that all of those threads are sharing the same address space.
Keep in mind that when you say "ps is at best deceptive, if not actually wrong" that you're implying that the Linux kernel is at best deceptive, if not wrong, about the memory usage it reports. All ps and top do is query the kernel; they're not coming up with these numbers on their own. The kernel, and by extension ps and top, are reporting the correct numbers for a Linux system. If you attribute different meaning to those numbers, then that's your fault, not the fault of the tools you're using.
Each thread in a process shows up as consuming the same amount of memory (either this only happens under Linuxthreads or I don't have any threaded applications running on my system).
Under LinuxThreads, each thread had its own PID. Under NPTL (Native POSIX Thread Library) all threads from the same process share the same PID, but each thread has a unique TID (which you can get with the Linux specific call gettid()). Calling getconf GNU_LIBPTHREAD_VERSION from a prompt should tell you what library and version you're running for pthread support.
Anyway, this is a round-a-bout way of saying you're right. Since LinuxThreads uses a unique PID for each thread, if you queried the kernel for memory info, it would tell you that each process (thread) was invidivually consuming xKb. That's non-intuitive behavior, but I think the blame belonged to LinuxThreads, not the kernel; LinuxThreads was abusing the concept of a PID. Thankfully this has been changed in NPTL.
It is clear and concise, assuming you have a basic understanding of how virtual memory works in an operating system. The kernel is simply reporting the statistics it keeps track of for use in memory management policies. Your analogy doesn't work because you're just comparing human-intuitive units to non-intuitive units. However, the concept of "How fast am I going?" is simpler than "What is the memory usage of a process?" A more complex question requires a more involved answer.
Run top. Check out the column that says SHR. Subtract it from VIRT if you want to know the virtual memory usage of a process excluding shared libraries, or subtract it from RES if you want to know the physical memory usage of a process excluding shared libraries. Problem solved.
I don't like how he phrases that what ps reports is "wrong." It's not wrong, or even "wrong." It reports exactly what Linux tells it (through the proc filesystem). It's just might not be what you expect it to be, which means you don't understand the tools and the system. When ps reports that a process' virtual memory usage is xKb, that is correct. In the address space for the process, xKb have been allocated. Shared or not, they're still in the address space.
I care because being able to multithread an application like gcc would be a very big deal. The parent did mention multithreaded compilers, only he did it implicity and without understanding what was actually happening.
Yes, it runs faster, and I explained why.
Those are not "parallel gcc's". They are sequential (sequential meaning non-multithreaded) gcc processes spawned at the same time. This is different from gcc itself being parallel.
make is different than gcc. One is a compiler. The other is a program which takes a dependecy file and calls the compiler in the correct way such as to maintain the dependencies. Parallelizing make is trivial: whoever wrote the makefile has already written out the dependencies for you. If two rules don't depend on each other, they can execute at the same time. This is an entirely different beast from parallelizing the compiler itself.