The main sign that a company is about to go under is when they get the law involved. For some examples see the record labels, film studios and patent trolls. Even Apple is infamous for being excessively litigious prior to their current windfall.
Normally business arrangements are reciprocal and it's in the best interests of a company to avoid publicizing that their partners are in breach of a contract. There are plenty of collections agencies in the private sector that they could have consulted instead, but instead it's being treated as a criminal matter. This is the sort of behavior you see when a company realizes that their business model is flawed.
Really? I'm posting this comment from a workstation running a commercial UNIX. I'm using a Mac.
Colloquially, when someone talks about commercial UNIX, they're talking about the descendants of System V - Xenix, IRIX, AIX, HP-UX, Solaris/SunOS and the like. OSX is based on FreeBSD.
Small game companies can make a decent game for a pittance because they have no choice. They either make do with what they have, or they pack up and go home.
Huge game companies spend a lot of money because there is no pressure for frugality. Usually this total lack of moderation takes the form of having hundreds more developers working on a game than they need to. The extra labor goes into go-nowhere projects like the EASTL, an utterly bizarre version of the STL for low-memory consoles, or trying to integrate all of the obscenely expensive middleware that's needed to be advertised on the box.
This is why software companies have to resort to trivia games, quizzes on software minutiae, fizzbuzz and goddamn *riddles* to find out if someone is actually capable of doing the job.
Computer science is not a code writin' certificate, it's a degree in the science of studying computation. If you want to be successful in writing software and getting paid for it, you have to take responsibility for your own success. It's vital to study independently: teach *yourself* how to use the theoretical concepts you learn in class. Track down summer internships, so you have a chance to prove that you have these abilities later on.
Here's the simple, terrifying fact: America cannot produce enough technical workers of a sufficient level of skill to satisfy America's demand.
Now, I infer from your statement that you believe all American technical workers are automatically better than all foreign technical workers, or at least that all American technical workers are equal. Basically what you are suggesting is that Microsoft would lose nothing by hiring some Colorado kid with a degree from DeVry over a 24 year old Alan Turing.
So here's the real question for you: if Microsoft weren't allowed to use H-1Bs anymore, would their domestic employment really increase? Given that the people Microsoft isn't hiring now can't actually do the job? Or do you think it's more likely that they'll just open up a new campus 100 miles north?
I don't believe you know what the word 'anecdote' means.
However, you did correctly point out a fallacy. I didn't know this until I looked it up just now, but H-1B employers are legally required to pay the higher of:
1.) the prevailing wage for the job (as stated by the government), or 2.) the actual wage, which is the wage the company would pay the foreign applicant's naturalized co-workers.
So my point remains valid: H-1B visas are not taking jobs away from Americans because they're less expensive.
IIRC, Microsoft is the largest H-1B employer in the United States. Microsoft has publicly (and repeatedly) stated that they do not maintain separate salary tracks for their foreign employees - that is, they pay foreigners the exact same amount they could pay someone born in the United States.
Payroll statistics are made available to the DHS/USCIS and these statistics corroborate Microsoft's statements.
So, now that you understand that there isn't some great demon lurking across the border waiting to devour your jobs and your womenfolk, you have the opportunity (and, from your outburst, the free time) to investigate why Americans aren't as competitive in the same jobs as someone from another country.
Here's a hint: it might start with the fact that you automatically blame others for your own problems.
I'm going to disagree with your argument in letter but not in spirit.
Grants are a form of investment. The government is paying a company money to encourage development that they believe will improve all of society. They are no more entitled to free use of the resulting innovation any more than another investor or venture capitalist would be. Unlike most investment, a grant is essentially a gift, but they do come with certain obligations that may offset the value of the "free" money.
Good examples of this system working can be seen in the cable franchises. Local governments give a grant and monopoly to a selected cable company, with the obligation that service is made available to every single household in the region. Without the grant, the cable company may have never entered the region because the profit might have never paid off the cost of running the cable.
I'm not going to disagree with you in spirit, however, because this particular area of research has nothing to offer society. Biometrics, until we have computers above the intelligence of a human security guard, are no more secure than a plain metal key (but a whole lot more gory).
If Jimmy Carter's kindergarten logic was enough for him to win the nobel peace prize, my kindergarten logic should be enough to win the nobel prize in physics.
Cross-platform GUI libraries are inadequate given the wide variety of devices, platforms, user expectations, usability standards and the extreme disparity in basic user interface elements, layout engines and even programming languages.
HTML is currently the most ideal because it offers a cross-platform and largely-standardized way of expressing both content and layout. Using a browser GUI solves a lot of difficult issues, including look-and-feel and specialized layout for peculiar form factors (like cell phones).
Essentially what I'm suggesting is that we are looking at the situation backwards. We should be using HTML to lay out GUIs locally, rather than have clients connect to these applications remotely.
I guess it's too much to expect you to leave your own country and explore the world when you don't even leave your own mother's basement to get a job.:P
The Mac Pro's memory strategy is a fairly radical departure from normal desktop computers. Mac Pros use DDR2-800 FB-DIMMs (Fully-Buffered DIMMs). The difference is that, instead of connecting to a conventional memory controller on a parallel bus, FB-DIMMs connect to a combination memory controller/buffer via a serial bus. This allows for large memory capacities while maintaining low complexity on the memory controller, but it increases memory latency by as much as 50%.
Maximum theoretical throughput is also 16 GB/s with a matched pair compared to 25 GB/s for dual-channel DDR3 running at the same clock rate.
It's a good machine and the limits will never interfere with normal or workstation use (I have one too) but it's definitely not meant for this application.
I don't know specifically what you're doing, but it still sounds to me like you're trying to make a square peg fit in a round hole. You're fighting the scheduler instead of using built-in facilities for this sort of work (thread pools), and you're running an ordinary operating system where your application demands a level of determinism only granted by a real-time operating system. And to make things even more confusing, you have this application running on a Mac Pro - which has really bad memory latency, poor bandwidth and 8 processors to feed with it?
What's the big difference in IPC? I mean... shared memory is shared memory.
Let's say you write a message queue. You think "welp, my cpu has a 32 bit word so it can probably write a 32 bit word in one cycle:D," stick a volatile in front of it and you think you're done. Then you get odd bugs.
So you read up on your CPU and discover that it's only possible to read or write a 32 bit word in one cycle if the word is on an 8-byte boundary. So you manually specify alignment and the problem seems to go away. Then you get odd bugs.
So you read up more on your CPU, bang your head against your desk and read some more. Eventually you'll remember that your CPU thinks it's much smarter than you are and it's reordering your read and write instructions. So you add a memory barrier and the problem seems to go away. Then you get odd bugs.
Occasionally you get duplicates of old messages or corruption. So you repeat the above steps and finally learn that your CPU has decided it's much smarter than you are, and it has decided that it's better to update the read pointer in your message queue before the memory you're writing to the queue finishes leaving the L1 cache.
Yes, indeed, shared memory is shared memory. I have no idea why Google might be taking a long time to port their multithreaded Windows applications to Linux and OSX which run on several different and totally alien architectures.
I am looking at developing an application that utilizes multiple cores (on Apple Mac Pro) and I have questions like how do you keep the OS hands off the cores you want to delegate to the application.
What exactly are you trying to do? Are you just trying to get as much CPU time as possible? If you're writing it for OSX you could try NSOperation and NSOperationQueue. Or you could grab a C++ compiler with support for OpenMP and do a lot of loop-level parallelization. That would be the easiest route for most uses. Or if you really actually want dedicated access to a processor you could always write it for Windows 3.1 and just never call GetMessage.
You cannot guarantee exclusive access to a processor. Modern schedulers are specifically designed to prevent applications from doing this: all you can do is ask the operating system to return to your thread more often.
Programmers don't like to remember this, but our code probably isn't the most important code running on a machine. And even if it really, truly is, the OS has absolutely no way of telling the difference between you and some third-rate tray application that would take over an entire CPU just because it can.
And having multithreading "dumped" on us isn't as huge a deal as you make it. It's perfectly possible to develop multithreaded code using existing C interfaces and the various OS-specific synchronization primitives, and virtually every nontrivial application has done this ever since Windows got a preemptive scheduler. Read/write reordering is much more inconvenient.
The most important thing to understand is that these aren't actually 'cores' in the same sense that your Core 2 Duo has two of them. They're shader units. It works more like SIMD than parallelization, only instead of something like SSE that can perform a single operation per clock across 4 packed floating point values it performs the operation on thousands of them.
If they could slap a billion or a million or even a thousand shader units on a card without actually reducing performance they would, but they can't. At a certain point the bottleneck becomes link length. You can overcome it by increasing voltage but then heat becomes the issue. This is a large part of the reason transistor count is tied to transistor size. NVIDIA isn't "failing" in this respect, they're just succumbing to the laws of physics.
If they could improve performance by slapping 20 or 4 or even 2 of the *actual* cores on each card they would, but they can't. Because it's not an actual processor, it doesn't have fancy features like three levels of cache and a TLB and branch prediction and out-of-order execution. But even if they were engineered to work this way, you can't improve PC performance by slapping in a thousand Core 2 Quads either. A part of the reason Xeons have so much cache is so you can mitigate the penalty of having 8 processors using commodity RAM, but eventually you run up against that bottleneck. Shared resources become saturated much faster than most people expect.
The most efficient way of improving graphics performance is with SLI because you are replicating all of the hardware, the memory and the bus the *actual* core depends on. For the exact same reason, you can extract the most performance out of each CPU core by putting each one in a different machine.
This is more a case of *Microsoft* not being ACPI compliant. The different versions of Windows have historically broken ACPI in hilariously random and catastrophic ways. You can decompile any BIOS on the market and find a similar table.
If you're willing to rule out malicious sabotage on the part of Foxconn (which would be a pretty ballsy move given that they manufacture Intel's reference motherboards), the fault can probably be traced back to their BIOS vendor - either AMI or Award, if memory serves.
Re:It only works in the top slot
on
Inside Steve's Brain
·
· Score: 4, Interesting
...Rome wasn't built by MBAs at all. When Rome was built, the Romans were a very pragmatic people who probably wouldn't have wasted their time on a group of incompetent middle-men telling professional builders and engineers what to do.
All filesystems suffer from defragmentation. Many Linux users, for example, take the lack of defragmentation utilities to mean that the filesystems are immune to the problem. This assumption is incorrect. Even a commonly-used filesystem like ext3, which is every bit as vulnerable to fragmentation as NTFS, does not have a defragmentation tool: you are first required to convert the partition to ext2. There are very few problems with the bazaar mentality and this is a rather stunning example of one of them.
These were C++ programmers...
on
Head First C#
·
· Score: 1
...and I guess someone who uses a wood chisel to open a paint can is a handyman.
The differences between C++ polymorphism and C# interfaces are extreme and I find it baffling that someone who could claim even a passing familiarity with both languages could genuinely confuse the two.
Ocean-going vessels also require much more robust reactor and pump designs. While I can't say for certain that there have been no incidents, there have been zero non-communism-related accidents. The technology for compact and extremely safe nuclear reactors exists and would be prevalent if it weren't for SUV-driving suburban soccer moms trying to convince us to think of the children.
See, this is the thing:
It's in the collective good for creeps and pedophiles to distribute illegal material in what is essentially the public eye. By limiting access (however slightly) they are only encouraging the distribution of child pornography via services that are even more decentralized. If alt.* becomes the great worldwide child porn warehouse it would be a good thing because that way it would be a whole lot easier to find out where the new material is coming from.
But a politician is a politician and a corporation is a corporation. Neither of them are even slightly interested in what's reasonable or what's good for society. Ultimately the AG and Verizon want to do the same thing as pedophiles, only somewhat more metaphorically. Next up: IRC.
If Blizzard wants to stop people from using bots they should be talking to their designers, not to their legal team. The real culprit behind the issue is the fact that World of Warcraft is a dull chore. Just more whining from the makers of MMO Wonderbread.
Slashdot Mirror
The main sign that a company is about to go under is when they get the law involved. For some examples see the record labels, film studios and patent trolls. Even Apple is infamous for being excessively litigious prior to their current windfall.
Normally business arrangements are reciprocal and it's in the best interests of a company to avoid publicizing that their partners are in breach of a contract. There are plenty of collections agencies in the private sector that they could have consulted instead, but instead it's being treated as a criminal matter. This is the sort of behavior you see when a company realizes that their business model is flawed.
Really? I'm posting this comment from a workstation running a commercial UNIX. I'm using a Mac.
Colloquially, when someone talks about commercial UNIX, they're talking about the descendants of System V - Xenix, IRIX, AIX, HP-UX, Solaris/SunOS and the like. OSX is based on FreeBSD.
Small game companies can make a decent game for a pittance because they have no choice. They either make do with what they have, or they pack up and go home.
Huge game companies spend a lot of money because there is no pressure for frugality. Usually this total lack of moderation takes the form of having hundreds more developers working on a game than they need to. The extra labor goes into go-nowhere projects like the EASTL, an utterly bizarre version of the STL for low-memory consoles, or trying to integrate all of the obscenely expensive middleware that's needed to be advertised on the box.
This is why software companies have to resort to trivia games, quizzes on software minutiae, fizzbuzz and goddamn *riddles* to find out if someone is actually capable of doing the job.
Computer science is not a code writin' certificate, it's a degree in the science of studying computation. If you want to be successful in writing software and getting paid for it, you have to take responsibility for your own success. It's vital to study independently: teach *yourself* how to use the theoretical concepts you learn in class. Track down summer internships, so you have a chance to prove that you have these abilities later on.
Here's the simple, terrifying fact: America cannot produce enough technical workers of a sufficient level of skill to satisfy America's demand.
Now, I infer from your statement that you believe all American technical workers are automatically better than all foreign technical workers, or at least that all American technical workers are equal. Basically what you are suggesting is that Microsoft would lose nothing by hiring some Colorado kid with a degree from DeVry over a 24 year old Alan Turing.
So here's the real question for you: if Microsoft weren't allowed to use H-1Bs anymore, would their domestic employment really increase? Given that the people Microsoft isn't hiring now can't actually do the job? Or do you think it's more likely that they'll just open up a new campus 100 miles north?
I don't believe you know what the word 'anecdote' means.
However, you did correctly point out a fallacy. I didn't know this until I looked it up just now, but H-1B employers are legally required to pay the higher of:
1.) the prevailing wage for the job (as stated by the government), or
2.) the actual wage, which is the wage the company would pay the foreign applicant's naturalized co-workers.
So my point remains valid: H-1B visas are not taking jobs away from Americans because they're less expensive.
IIRC, Microsoft is the largest H-1B employer in the United States. Microsoft has publicly (and repeatedly) stated that they do not maintain separate salary tracks for their foreign employees - that is, they pay foreigners the exact same amount they could pay someone born in the United States.
Payroll statistics are made available to the DHS/USCIS and these statistics corroborate Microsoft's statements.
So, now that you understand that there isn't some great demon lurking across the border waiting to devour your jobs and your womenfolk, you have the opportunity (and, from your outburst, the free time) to investigate why Americans aren't as competitive in the same jobs as someone from another country.
Here's a hint: it might start with the fact that you automatically blame others for your own problems.
I'm going to disagree with your argument in letter but not in spirit.
Grants are a form of investment. The government is paying a company money to encourage development that they believe will improve all of society. They are no more entitled to free use of the resulting innovation any more than another investor or venture capitalist would be. Unlike most investment, a grant is essentially a gift, but they do come with certain obligations that may offset the value of the "free" money.
Good examples of this system working can be seen in the cable franchises. Local governments give a grant and monopoly to a selected cable company, with the obligation that service is made available to every single household in the region. Without the grant, the cable company may have never entered the region because the profit might have never paid off the cost of running the cable.
I'm not going to disagree with you in spirit, however, because this particular area of research has nothing to offer society. Biometrics, until we have computers above the intelligence of a human security guard, are no more secure than a plain metal key (but a whole lot more gory).
If Jimmy Carter's kindergarten logic was enough for him to win the nobel peace prize, my kindergarten logic should be enough to win the nobel prize in physics.
Cross-platform GUI libraries are inadequate given the wide variety of devices, platforms, user expectations, usability standards and the extreme disparity in basic user interface elements, layout engines and even programming languages.
HTML is currently the most ideal because it offers a cross-platform and largely-standardized way of expressing both content and layout. Using a browser GUI solves a lot of difficult issues, including look-and-feel and specialized layout for peculiar form factors (like cell phones).
Essentially what I'm suggesting is that we are looking at the situation backwards. We should be using HTML to lay out GUIs locally, rather than have clients connect to these applications remotely.
I know you're joking but it still gave me a headache.
Since when is Canada a first world country, EH?
I guess it's too much to expect you to leave your own country and explore the world when you don't even leave your own mother's basement to get a job. :P
The Mac Pro's memory strategy is a fairly radical departure from normal desktop computers. Mac Pros use DDR2-800 FB-DIMMs (Fully-Buffered DIMMs). The difference is that, instead of connecting to a conventional memory controller on a parallel bus, FB-DIMMs connect to a combination memory controller/buffer via a serial bus. This allows for large memory capacities while maintaining low complexity on the memory controller, but it increases memory latency by as much as 50%.
Maximum theoretical throughput is also 16 GB/s with a matched pair compared to 25 GB/s for dual-channel DDR3 running at the same clock rate.
It's a good machine and the limits will never interfere with normal or workstation use (I have one too) but it's definitely not meant for this application.
I don't know specifically what you're doing, but it still sounds to me like you're trying to make a square peg fit in a round hole. You're fighting the scheduler instead of using built-in facilities for this sort of work (thread pools), and you're running an ordinary operating system where your application demands a level of determinism only granted by a real-time operating system. And to make things even more confusing, you have this application running on a Mac Pro - which has really bad memory latency, poor bandwidth and 8 processors to feed with it?
What's the big difference in IPC? I mean... shared memory is shared memory.
Let's say you write a message queue. You think "welp, my cpu has a 32 bit word so it can probably write a 32 bit word in one cycle :D," stick a volatile in front of it and you think you're done. Then you get odd bugs.
So you read up on your CPU and discover that it's only possible to read or write a 32 bit word in one cycle if the word is on an 8-byte boundary. So you manually specify alignment and the problem seems to go away. Then you get odd bugs.
So you read up more on your CPU, bang your head against your desk and read some more. Eventually you'll remember that your CPU thinks it's much smarter than you are and it's reordering your read and write instructions. So you add a memory barrier and the problem seems to go away. Then you get odd bugs.
Occasionally you get duplicates of old messages or corruption. So you repeat the above steps and finally learn that your CPU has decided it's much smarter than you are, and it has decided that it's better to update the read pointer in your message queue before the memory you're writing to the queue finishes leaving the L1 cache.
Yes, indeed, shared memory is shared memory. I have no idea why Google might be taking a long time to port their multithreaded Windows applications to Linux and OSX which run on several different and totally alien architectures.
I am looking at developing an application that utilizes multiple cores (on Apple Mac Pro) and I have questions like how do you keep the OS hands off the cores you want to delegate to the application.
What exactly are you trying to do? Are you just trying to get as much CPU time as possible? If you're writing it for OSX you could try NSOperation and NSOperationQueue. Or you could grab a C++ compiler with support for OpenMP and do a lot of loop-level parallelization. That would be the easiest route for most uses. Or if you really actually want dedicated access to a processor you could always write it for Windows 3.1 and just never call GetMessage.
You cannot guarantee exclusive access to a processor. Modern schedulers are specifically designed to prevent applications from doing this: all you can do is ask the operating system to return to your thread more often.
Programmers don't like to remember this, but our code probably isn't the most important code running on a machine. And even if it really, truly is, the OS has absolutely no way of telling the difference between you and some third-rate tray application that would take over an entire CPU just because it can.
And having multithreading "dumped" on us isn't as huge a deal as you make it. It's perfectly possible to develop multithreaded code using existing C interfaces and the various OS-specific synchronization primitives, and virtually every nontrivial application has done this ever since Windows got a preemptive scheduler. Read/write reordering is much more inconvenient.
Apart from, you know, link length.
The most important thing to understand is that these aren't actually 'cores' in the same sense that your Core 2 Duo has two of them. They're shader units. It works more like SIMD than parallelization, only instead of something like SSE that can perform a single operation per clock across 4 packed floating point values it performs the operation on thousands of them.
If they could slap a billion or a million or even a thousand shader units on a card without actually reducing performance they would, but they can't. At a certain point the bottleneck becomes link length. You can overcome it by increasing voltage but then heat becomes the issue. This is a large part of the reason transistor count is tied to transistor size. NVIDIA isn't "failing" in this respect, they're just succumbing to the laws of physics.
If they could improve performance by slapping 20 or 4 or even 2 of the *actual* cores on each card they would, but they can't. Because it's not an actual processor, it doesn't have fancy features like three levels of cache and a TLB and branch prediction and out-of-order execution. But even if they were engineered to work this way, you can't improve PC performance by slapping in a thousand Core 2 Quads either. A part of the reason Xeons have so much cache is so you can mitigate the penalty of having 8 processors using commodity RAM, but eventually you run up against that bottleneck. Shared resources become saturated much faster than most people expect.
The most efficient way of improving graphics performance is with SLI because you are replicating all of the hardware, the memory and the bus the *actual* core depends on. For the exact same reason, you can extract the most performance out of each CPU core by putting each one in a different machine.
This is more a case of *Microsoft* not being ACPI compliant. The different versions of Windows have historically broken ACPI in hilariously random and catastrophic ways. You can decompile any BIOS on the market and find a similar table. If you're willing to rule out malicious sabotage on the part of Foxconn (which would be a pretty ballsy move given that they manufacture Intel's reference motherboards), the fault can probably be traced back to their BIOS vendor - either AMI or Award, if memory serves.
...Rome wasn't built by MBAs at all. When Rome was built, the Romans were a very pragmatic people who probably wouldn't have wasted their time on a group of incompetent middle-men telling professional builders and engineers what to do.
All filesystems suffer from defragmentation. Many Linux users, for example, take the lack of defragmentation utilities to mean that the filesystems are immune to the problem. This assumption is incorrect. Even a commonly-used filesystem like ext3, which is every bit as vulnerable to fragmentation as NTFS, does not have a defragmentation tool: you are first required to convert the partition to ext2. There are very few problems with the bazaar mentality and this is a rather stunning example of one of them.
...and I guess someone who uses a wood chisel to open a paint can is a handyman. The differences between C++ polymorphism and C# interfaces are extreme and I find it baffling that someone who could claim even a passing familiarity with both languages could genuinely confuse the two.
Ocean-going vessels also require much more robust reactor and pump designs. While I can't say for certain that there have been no incidents, there have been zero non-communism-related accidents. The technology for compact and extremely safe nuclear reactors exists and would be prevalent if it weren't for SUV-driving suburban soccer moms trying to convince us to think of the children.
See, this is the thing: It's in the collective good for creeps and pedophiles to distribute illegal material in what is essentially the public eye. By limiting access (however slightly) they are only encouraging the distribution of child pornography via services that are even more decentralized. If alt.* becomes the great worldwide child porn warehouse it would be a good thing because that way it would be a whole lot easier to find out where the new material is coming from. But a politician is a politician and a corporation is a corporation. Neither of them are even slightly interested in what's reasonable or what's good for society. Ultimately the AG and Verizon want to do the same thing as pedophiles, only somewhat more metaphorically. Next up: IRC.
If Blizzard wants to stop people from using bots they should be talking to their designers, not to their legal team. The real culprit behind the issue is the fact that World of Warcraft is a dull chore. Just more whining from the makers of MMO Wonderbread.
I was not aware that I was expressing my own personal opinion. Thank you for clarifying that.