Win8 is no more closed than Win7. You can still build / sell Win32 apps. Win8 *adds* a new way to distribute software. Regardless of whether the Windows Marketplace / Store / whatever is good or bad, that's completely independent of the fact that Win8 is still *Windows*, so you can still install Steam, Firefox, or whatever other software you want to download or create.
It's not "mediocre." I defy you to walk into a store and actually play around with a WP7 device, to get some real experience with it, rather than just living in the Slashdot echo chamber. Yeah yeah, I expect cracks about "I can't even find them." But seriously -- judge the product on its merits. The interface is actually pretty damn good.
There are two problems with Windows Phone. 1) The apps market is tiny, compared to iPhone. 2) The poor perception / reputation. But the product *itself* is pretty good. I use a WP7.5 device (Samsung Focus), and I'm very happy with it. Disclaimer: I am a Microsoft employee. However, I have a choice, and I choose Windows Phone. And I plan on buying a Lumia 920 when they're out.
Some of those positions are more specialized than others. For example, for working on compiler technology, there is a requirement for deep experience in compilers. The others are more flexible.
> But, in general, the potential for such abuse is inherent in the system, and there has been plenty of evidence of other companies abusing it that way.
Agreed. Personally, if I had control over things, I would eliminate all H1B limits, and allow American companies to hire as many immigrants as they wanted, while requiring these companies to pay up for INS fees and domestic training and education. Skilled immigrants increase the competitiveness of American companies, and they often become naturalized citizens, anyway. I would drop the requirement that the visa terminate, as well. I'm more than happy to have skilled immigrants come to America, permanently, as full citizens with all rights. The more the merrier.
I completely agree. And that's what my team does. We hire bright people who are willing to learn. Existing knowledge about a specialized field is a benefit, but it's not the most important thing.
Sometimes specialized knowledge is a requirement, but that's the exception, not the rule.
Trust me, I'm all too aware of the reputation Microsoft has, and I'm sure that's part of the problem. I spend a lot of time fighting the poor perception of the company. Some of it is earned, some of it is outdated, and some of it is undeserved.
We offer plenty of money. As I said elsewhere in this thread, the problem I see is the poor quality of candidates. Generally, if my group offers someone a position, they usually accept it. The specific work we are doing is quite compelling.
Oh, also, we usually have anywhere from 3 to 5 interns rotating through, and their ages are usually early 20s. Many of our interns like the position so much they come back for another internship, or they join us full-time after they finish their degree. Note that I'm talking about my particular group -- I'm not talking about the entire company.
So you worked at one group, for a year. I've worked in four different groups, for over fifteen years. I don't dispute your own experience, but generalizing to the entire company is irrational.
Yes, the programs suck. Or to be a little more precise about it, the CS programs are a confusing mixture of things. When you graduate, what are your goals? Do you want to be technology-focused, in the sense that you're involved in machine architecture? For example, working on parallel processing, power efficiency, networking protocols, etc. Or do you want to work at a higher level, where you are mainly applying existing technology to solving real-world problems (business, society, etc.)? These are both worthy pursuits, but many CS programs confuse the two.
I mainly look for CS students who also have a strong EE background. Someone who has been through a VLSI design course is very often a much better programmer (for my particular workplace) than someone who has spent a lot of time working on web sites.
Also, performance analysis is *always* a great way to learn more. Start with any good profiler, and let the data tell you where to go. You'll be amazed what you find. It really doesn't matter that much what particular profiler you use. The important part is to focus on measurement, rather than guessing. The real performance problems are rarely where you think they are. For example, in a lot of programs, basic string manipulation is often the bottleneck. It's tempting to think you can guess where the perf problems are, but after doing perf analysis for many years, I can't exaggerate how humbling perf work is. Even the most experienced engineers rarely guess correctly. To become a great engineer, simply accept some humility -- you don't know, until you measure. Measure, measure, measure. I like to think of this as the difference between "programming" and "engineering". You're not doing engineering until you're guiding your work based on measurement.
1. Willingness to work at any level required in a system. All the way from high-level languages and environments (HTML/JS, UI toolkits, SQL) down through middle-level languages (Java, C#, C/C++), down through assembly language (understanding machine architecture, compilers, assembly-level debugging). You don't have to *start* with those skills, but you need to be willing to *learn* them and be comfortable working at any level.
2. Willingness to learn any new problem. We usually look at your background, and ask you one programming question that is solidly in your "comfort zone," and then ask programming questions that are outside your comfort zone. The first question is designed to see how much you can talk about something that is comfortable and familiar to you (and also frankly to make you feel comfortable -- after all, hiring is *not* adversarial for us, we're trying to see if you can work with us to solve problems). Can you explain a solution well? Can you teach something to someone else? The programming problems that are outside of your comfort zone are all about seeing whether you are able and willing to apply yourself to something new. For example, if your background is in networking, I might ask you a graphics programming problem. Or vice-versa. The goal is not to be a jerk, the goal is to see whether you can apply yourself to something new.
3. Ability to identify the problem, its exceptional cases ("corner cases"), and to identify engineering trade-offs (memory vs. speed, etc.). Just being able to identify what an interviewer is asking, in a programming problem, is an important skill. Very often, candidates will focus on the wrong aspect of a problem. Or they will rush into a problem without understanding it, and will miss the forest for the trees. This is a really basic skill that anyone can develop, and it helps in all job interviews (and in all real-world problem-solving situations).
4. Ability to choose the right tool for the job. If I ask you a question about vector programming for high-performance graphics rendering and you start answering in JavaScript, you've already failed. Conversely, if I ask you to solve a database problem such as "How would you store and search the data for a geo mapping web site?" and you start answering by focusing on low-level concerns like STL templates vs. linked lists, then you obviously are not focused on the core of the problem, which is how to structure the data on disk and how to organize it for efficient queries. (I've had candidates do both of these things.)
5. Ability to communicate your thought processes. If you're working on a programming problem during an interview, then at least half of the interview is about *how* you approach (and maybe solve) a problem. Are you breaking a complex problem into smaller problems? (divide and conquer) Are you making something more complex than it actually needs to be? Can you identify an algorithm that you don't understand, but you understand how to use it? For example, I don't think I could invent the fast Fourier transform, but I think I could identify when to use it, during an interview. If I say to an interviewer, "Here is where I would convert this data from the time domain to the frequency domain, using an FFT library, and then I would use the frequency domain data in such-and-such a way to solve this problem," then that's good. You don't need to invent the FFT in order to apply it.
Unfortunately I'm not allowed to give any info on pay ranges. (I could be fired for doing so.) I will say this, though. The salary is decent, but not overwhelming (as tech jobs go), because the bonuses are huge. The bonuses and stock are where the real money comes from. If you perform well, your bonus could be as much as one third of your base salary. Your stock grant could be worth as much as your entire yearly salary. It's structured so that you are compensated for performance, rather than seniority.
Now, someone is going to attack me for saying that. "OMG, you're paying people
The age distribution in my team is probably something close to this: Ages 25-30: 5, 30-35: 20, 35-40: 30, 40-45: 35, 45-50: 18, 50-60: 4.
So, pretty close to a Gaussian distribution. I'd say of the people I interview, one third are over 40. And they usually do better than the younger candidates.
> From my perspective, it is obvious that employers like you don't WANT good quality
I really don't understand how you managed to distort what I said into this statement. You don't know anything about my team, my hiring qualifications, etc. You're really just doing your best to attack me, without knowing anything about what we do. Your statement that we don't want good quality is simply factually wrong.
I have interviewed over a hundred people in the last few years. And let me tell you, the issue is the quality, not the price. We have *plenty* of money to offer, and we do offer it. But most of the candidates I interview simply do not meet the requirements on intelligence, skills, and problem-solving abilities.
I'm a fairly high-level architect at Microsoft. I have interviewed a metric F-load of people, many of which are international candidates. If we could hire all domestic, we would, because the paperwork is way easier. But the most important thing is, the actual salary that we pay people (and all the paperwork and such) actually rarely figures into the hire / no-hire decision. For us, it's all about that person's skills and what they bring to the team.
I would be very, very happy to see the cost of H1Bs go way up, in order to fund tech education. Companies WILL pay the money. And the best part about that is, it doesn't give any company a competitive advantage over any other company -- it's a level playing-field. Often when I hear companies gripe about some change in laws, I use that to judge whether the griping is legitimate or not -- does a change in law favor one company (or one kind of company) more than other? But in this case, no, it doesn't. All tech companies that need to hire will face the same labor market.
H1B is not slavery. The majority of H1B workers are young and single, usually a few years out of college. H1B gives them an opportunity to come to the states and 1) gain really valuable experience, 2) make a decent amount of money. Most of the H1B workers I meet are Indian, Chinese, or Russian. They make very good money. Good money in US terms, and *fantastic* money by the cost-of-living of where they came from. If they don't like their work conditions, they can leave. Just like any other job on the planet. If they do, they still made a ton of money, and still have a gig with American Mega-Awesome Corp or whatever on their resume. That's hardly slavery.
I would seriously love to see more American candidates. But where *are* they?? Most of the candidates from domestic CS programs are, frankly, very weak candidates. There are exceptions, but they are exceptions. (For example, the Brown CS program is excellent, and produces a steady stream of first-class CS students.) Most of the American candidates I interview know a little web programming, and maybe some Java, but are extremely weak on machine architecture, assembly programming, networking, performance analysis, and problem-solving abilities.
VS is a 32-bit app because VS hosts extensions in-process. Moving VS *itself* to 64-bit would be easy. Moving every extension ever made to 64-bit, and explaining to users that *some* of their extensions will work with it and *some* won't, is just not very appealing.
Because I never, ever want to rely on anything you build this way. You are headed for a disaster, unless you 1) set up a test environment, and 2) use a revision control system.
Really, anything less than that is just a complete waste of everyone's time.
Comparing LINPACK numbers makes sense. But GFLOPS (or TFLOPS or PFLOPS or whatever), by itself, is a meaningless and misleading number. Most people just stop thinking when they see a single metric like GFLOPS, and then they compare GFLOPS in one system to GFLOPS in another system. If those systems *are* comparable, then fine. But often enough, they are not comparable.
Also, it wasn't a rant. A rant would have involved caps lock.
Yes, many problems can be expressed as dense linear algebra, and so measuring and comparing LINPACK perf for these makes sense for those problems. However, many problems don't map well to dense linear algebra. The Berkeley "parallel dwarfs" paper expresses this idea better than I ever could: http://view.eecs.berkeley.edu/wiki/Dwarfs
I really, really wish articles would stop saying that computer X has Y GFLOPS. It's almost meaningless, because when you're dealing with that much CPU power, the real challenge is to make the communications topology match the computational topology. That is, you need the physical structure of the computer to be very similar to the structure of the problem you are working on. If you're doing parallel processing (and of course you are, for systems like this), then you need to be able to break your problem into chunks, and map each chunk to a processor. Some problems are more easily divided into chunks than other problems. (Go read up on the "parallel dwarves" for a description of how things can be divided up, if you're curious.)
I'll drill into an example. If you're doing a problem that can be spatially decomposed (fluid dynamics, molecular dynamics, etc.), then you can map regions of space to different processors. Then you run your simulation by having all the processors run for X time period (on your simulated timescale). At the end of the time period, each processor sends its results to its neighbors, and possibly to "far" neighbors if the forces exceed some threshold. In the worst case, every processor has to send a message to every other processor. Then, you run the simulation for the next time chunk. Depending on your data set, you may spend *FAR* more time sending the intermediate results between all the different processors than you do actually running the simulation. That's what I mean by matching the physical topology to the computational topology. In a system where the communications cost dominates the computation cost, then adding more processors usually doesn't help you *at all*, or can even slow down the entire system even more. So it's really meaningless to say "my cluster can do 500 GFLOPS", unless you are talking about the time that is actually spent doing productive simulation, not just time wasted waiting for communication.
Here's a (somewhat dumb) analogy. Let's say a Formula 1 race car can do a nominal 250 MPH. (The real number doesn't matter.) If you had 1000 F1 cars lined up, side by side, then how fast can you go? You're not going 250,000 MPH, that's for sure.
I'm not saying that this is not a real advance in supercomputing. What I am saying, is that you cannot measure the performance of any supercomputer with a single GFLOPS number. It's not an apples-to-apples comparison, unless you really are working on the exact same problem (like molecular dynamics). And in that case, you need some unit of measurement that is specific to that kind of problem. Maybe for molecular dynamics you could quantify the number of atoms being simulated, the average bond count, the length of time in every "tick" (the simulation time unit). THEN you could talk about how many of that unit your system can do, per second, rather than a meaningless number like GFLOPS.
Jesus, you are dense as all fuck. I did NOT say "break out a C# compiler." I said that was one of your options. Your OTHER options include doing traditional flat-text input/output. You are as dumb as a youtube comment.
Slashdot Mirror
Win8 is no more closed than Win7. You can still build / sell Win32 apps. Win8 *adds* a new way to distribute software. Regardless of whether the Windows Marketplace / Store / whatever is good or bad, that's completely independent of the fact that Win8 is still *Windows*, so you can still install Steam, Firefox, or whatever other software you want to download or create.
It's not "mediocre." I defy you to walk into a store and actually play around with a WP7 device, to get some real experience with it, rather than just living in the Slashdot echo chamber. Yeah yeah, I expect cracks about "I can't even find them." But seriously -- judge the product on its merits. The interface is actually pretty damn good.
There are two problems with Windows Phone. 1) The apps market is tiny, compared to iPhone. 2) The poor perception / reputation. But the product *itself* is pretty good. I use a WP7.5 device (Samsung Focus), and I'm very happy with it. Disclaimer: I am a Microsoft employee. However, I have a choice, and I choose Windows Phone. And I plan on buying a Lumia 920 when they're out.
https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=7&jid=89023&jlang=EN
https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=8&jid=86473&jlang=EN
https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=5&jid=77083&jlang=EN
https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=3&jid=85919&jlang=EN
Some of those positions are more specialized than others. For example, for working on compiler technology, there is a requirement for deep experience in compilers. The others are more flexible.
I'm glad your experience has been a positive one.
> But, in general, the potential for such abuse is inherent in the system, and there has been plenty of evidence of other companies abusing it that way.
Agreed. Personally, if I had control over things, I would eliminate all H1B limits, and allow American companies to hire as many immigrants as they wanted, while requiring these companies to pay up for INS fees and domestic training and education. Skilled immigrants increase the competitiveness of American companies, and they often become naturalized citizens, anyway. I would drop the requirement that the visa terminate, as well. I'm more than happy to have skilled immigrants come to America, permanently, as full citizens with all rights. The more the merrier.
I completely agree. And that's what my team does. We hire bright people who are willing to learn. Existing knowledge about a specialized field is a benefit, but it's not the most important thing.
Sometimes specialized knowledge is a requirement, but that's the exception, not the rule.
> But you won't be hearing from me. No degree, you see. I need not apply as I'm not "qualified."
I interview candidates that don't have degrees. *I* don't have a degree, and Microsoft has hired me, trained me, and promoted me. It's not a barrier.
If you actually read what I wrote, I never said a degree was required. Degree programs are the most common path, but hardly the only path.
Trust me, I'm all too aware of the reputation Microsoft has, and I'm sure that's part of the problem. I spend a lot of time fighting the poor perception of the company. Some of it is earned, some of it is outdated, and some of it is undeserved.
We offer plenty of money. As I said elsewhere in this thread, the problem I see is the poor quality of candidates. Generally, if my group offers someone a position, they usually accept it. The specific work we are doing is quite compelling.
Oh, also, we usually have anywhere from 3 to 5 interns rotating through, and their ages are usually early 20s. Many of our interns like the position so much they come back for another internship, or they join us full-time after they finish their degree. Note that I'm talking about my particular group -- I'm not talking about the entire company.
Thanks for the laughs. I haven't read such a bizarre thing since Time Cube Guy.
So you worked at one group, for a year. I've worked in four different groups, for over fifteen years. I don't dispute your own experience, but generalizing to the entire company is irrational.
Yes, the programs suck. Or to be a little more precise about it, the CS programs are a confusing mixture of things. When you graduate, what are your goals? Do you want to be technology-focused, in the sense that you're involved in machine architecture? For example, working on parallel processing, power efficiency, networking protocols, etc. Or do you want to work at a higher level, where you are mainly applying existing technology to solving real-world problems (business, society, etc.)? These are both worthy pursuits, but many CS programs confuse the two.
I mainly look for CS students who also have a strong EE background. Someone who has been through a VLSI design course is very often a much better programmer (for my particular workplace) than someone who has spent a lot of time working on web sites.
Also, performance analysis is *always* a great way to learn more. Start with any good profiler, and let the data tell you where to go. You'll be amazed what you find. It really doesn't matter that much what particular profiler you use. The important part is to focus on measurement, rather than guessing. The real performance problems are rarely where you think they are. For example, in a lot of programs, basic string manipulation is often the bottleneck. It's tempting to think you can guess where the perf problems are, but after doing perf analysis for many years, I can't exaggerate how humbling perf work is. Even the most experienced engineers rarely guess correctly. To become a great engineer, simply accept some humility -- you don't know, until you measure. Measure, measure, measure. I like to think of this as the difference between "programming" and "engineering". You're not doing engineering until you're guiding your work based on measurement.
1. Willingness to work at any level required in a system. All the way from high-level languages and environments (HTML/JS, UI toolkits, SQL) down through middle-level languages (Java, C#, C/C++), down through assembly language (understanding machine architecture, compilers, assembly-level debugging). You don't have to *start* with those skills, but you need to be willing to *learn* them and be comfortable working at any level.
2. Willingness to learn any new problem. We usually look at your background, and ask you one programming question that is solidly in your "comfort zone," and then ask programming questions that are outside your comfort zone. The first question is designed to see how much you can talk about something that is comfortable and familiar to you (and also frankly to make you feel comfortable -- after all, hiring is *not* adversarial for us, we're trying to see if you can work with us to solve problems). Can you explain a solution well? Can you teach something to someone else? The programming problems that are outside of your comfort zone are all about seeing whether you are able and willing to apply yourself to something new. For example, if your background is in networking, I might ask you a graphics programming problem. Or vice-versa. The goal is not to be a jerk, the goal is to see whether you can apply yourself to something new.
3. Ability to identify the problem, its exceptional cases ("corner cases"), and to identify engineering trade-offs (memory vs. speed, etc.). Just being able to identify what an interviewer is asking, in a programming problem, is an important skill. Very often, candidates will focus on the wrong aspect of a problem. Or they will rush into a problem without understanding it, and will miss the forest for the trees. This is a really basic skill that anyone can develop, and it helps in all job interviews (and in all real-world problem-solving situations).
4. Ability to choose the right tool for the job. If I ask you a question about vector programming for high-performance graphics rendering and you start answering in JavaScript, you've already failed. Conversely, if I ask you to solve a database problem such as "How would you store and search the data for a geo mapping web site?" and you start answering by focusing on low-level concerns like STL templates vs. linked lists, then you obviously are not focused on the core of the problem, which is how to structure the data on disk and how to organize it for efficient queries. (I've had candidates do both of these things.)
5. Ability to communicate your thought processes. If you're working on a programming problem during an interview, then at least half of the interview is about *how* you approach (and maybe solve) a problem. Are you breaking a complex problem into smaller problems? (divide and conquer) Are you making something more complex than it actually needs to be? Can you identify an algorithm that you don't understand, but you understand how to use it? For example, I don't think I could invent the fast Fourier transform, but I think I could identify when to use it, during an interview. If I say to an interviewer, "Here is where I would convert this data from the time domain to the frequency domain, using an FFT library, and then I would use the frequency domain data in such-and-such a way to solve this problem," then that's good. You don't need to invent the FFT in order to apply it.
Unfortunately I'm not allowed to give any info on pay ranges. (I could be fired for doing so.) I will say this, though. The salary is decent, but not overwhelming (as tech jobs go), because the bonuses are huge. The bonuses and stock are where the real money comes from. If you perform well, your bonus could be as much as one third of your base salary. Your stock grant could be worth as much as your entire yearly salary. It's structured so that you are compensated for performance, rather than seniority.
Now, someone is going to attack me for saying that. "OMG, you're paying people
The age distribution in my team is probably something close to this: Ages 25-30: 5, 30-35: 20, 35-40: 30, 40-45: 35, 45-50: 18, 50-60: 4.
So, pretty close to a Gaussian distribution. I'd say of the people I interview, one third are over 40. And they usually do better than the younger candidates.
> From my perspective, it is obvious that employers like you don't WANT good quality
I really don't understand how you managed to distort what I said into this statement. You don't know anything about my team, my hiring qualifications, etc. You're really just doing your best to attack me, without knowing anything about what we do. Your statement that we don't want good quality is simply factually wrong.
I have interviewed over a hundred people in the last few years. And let me tell you, the issue is the quality, not the price. We have *plenty* of money to offer, and we do offer it. But most of the candidates I interview simply do not meet the requirements on intelligence, skills, and problem-solving abilities.
I'm a fairly high-level architect at Microsoft. I have interviewed a metric F-load of people, many of which are international candidates. If we could hire all domestic, we would, because the paperwork is way easier. But the most important thing is, the actual salary that we pay people (and all the paperwork and such) actually rarely figures into the hire / no-hire decision. For us, it's all about that person's skills and what they bring to the team.
I would be very, very happy to see the cost of H1Bs go way up, in order to fund tech education. Companies WILL pay the money. And the best part about that is, it doesn't give any company a competitive advantage over any other company -- it's a level playing-field. Often when I hear companies gripe about some change in laws, I use that to judge whether the griping is legitimate or not -- does a change in law favor one company (or one kind of company) more than other? But in this case, no, it doesn't. All tech companies that need to hire will face the same labor market.
H1B is not slavery. The majority of H1B workers are young and single, usually a few years out of college. H1B gives them an opportunity to come to the states and 1) gain really valuable experience, 2) make a decent amount of money. Most of the H1B workers I meet are Indian, Chinese, or Russian. They make very good money. Good money in US terms, and *fantastic* money by the cost-of-living of where they came from. If they don't like their work conditions, they can leave. Just like any other job on the planet. If they do, they still made a ton of money, and still have a gig with American Mega-Awesome Corp or whatever on their resume. That's hardly slavery.
I would seriously love to see more American candidates. But where *are* they?? Most of the candidates from domestic CS programs are, frankly, very weak candidates. There are exceptions, but they are exceptions. (For example, the Brown CS program is excellent, and produces a steady stream of first-class CS students.) Most of the American candidates I interview know a little web programming, and maybe some Java, but are extremely weak on machine architecture, assembly programming, networking, performance analysis, and problem-solving abilities.
VS is a 32-bit app because VS hosts extensions in-process. Moving VS *itself* to 64-bit would be easy. Moving every extension ever made to 64-bit, and explaining to users that *some* of their extensions will work with it and *some* won't, is just not very appealing.
Everyone will be required to perform surgery every week.
Because I never, ever want to rely on anything you build this way. You are headed for a disaster, unless you 1) set up a test environment, and 2) use a revision control system.
Really, anything less than that is just a complete waste of everyone's time.
Next question.
Comparing LINPACK numbers makes sense. But GFLOPS (or TFLOPS or PFLOPS or whatever), by itself, is a meaningless and misleading number. Most people just stop thinking when they see a single metric like GFLOPS, and then they compare GFLOPS in one system to GFLOPS in another system. If those systems *are* comparable, then fine. But often enough, they are not comparable.
Also, it wasn't a rant. A rant would have involved caps lock.
Yes, many problems can be expressed as dense linear algebra, and so measuring and comparing LINPACK perf for these makes sense for those problems. However, many problems don't map well to dense linear algebra. The Berkeley "parallel dwarfs" paper expresses this idea better than I ever could: http://view.eecs.berkeley.edu/wiki/Dwarfs
Earth escape velocity is ~25,000 MPH. But 1000 F1 cars cannot reach orbit. Adding up numbers does not always give you a meaningful number.
I really, really wish articles would stop saying that computer X has Y GFLOPS. It's almost meaningless, because when you're dealing with that much CPU power, the real challenge is to make the communications topology match the computational topology. That is, you need the physical structure of the computer to be very similar to the structure of the problem you are working on. If you're doing parallel processing (and of course you are, for systems like this), then you need to be able to break your problem into chunks, and map each chunk to a processor. Some problems are more easily divided into chunks than other problems. (Go read up on the "parallel dwarves" for a description of how things can be divided up, if you're curious.)
I'll drill into an example. If you're doing a problem that can be spatially decomposed (fluid dynamics, molecular dynamics, etc.), then you can map regions of space to different processors. Then you run your simulation by having all the processors run for X time period (on your simulated timescale). At the end of the time period, each processor sends its results to its neighbors, and possibly to "far" neighbors if the forces exceed some threshold. In the worst case, every processor has to send a message to every other processor. Then, you run the simulation for the next time chunk. Depending on your data set, you may spend *FAR* more time sending the intermediate results between all the different processors than you do actually running the simulation. That's what I mean by matching the physical topology to the computational topology. In a system where the communications cost dominates the computation cost, then adding more processors usually doesn't help you *at all*, or can even slow down the entire system even more. So it's really meaningless to say "my cluster can do 500 GFLOPS", unless you are talking about the time that is actually spent doing productive simulation, not just time wasted waiting for communication.
Here's a (somewhat dumb) analogy. Let's say a Formula 1 race car can do a nominal 250 MPH. (The real number doesn't matter.) If you had 1000 F1 cars lined up, side by side, then how fast can you go? You're not going 250,000 MPH, that's for sure.
I'm not saying that this is not a real advance in supercomputing. What I am saying, is that you cannot measure the performance of any supercomputer with a single GFLOPS number. It's not an apples-to-apples comparison, unless you really are working on the exact same problem (like molecular dynamics). And in that case, you need some unit of measurement that is specific to that kind of problem. Maybe for molecular dynamics you could quantify the number of atoms being simulated, the average bond count, the length of time in every "tick" (the simulation time unit). THEN you could talk about how many of that unit your system can do, per second, rather than a meaningless number like GFLOPS.
Jesus, you are dense as all fuck. I did NOT say "break out a C# compiler." I said that was one of your options. Your OTHER options include doing traditional flat-text input/output. You are as dumb as a youtube comment.