Vaccines are not 100%, many require herd immunity to even work on a whole. Vaccines don't keep you from getting infected, they typically keep it from spreading and reduces the severity of the person who gets sick.
There's a lot of Indian and Chinese women who hate their programming job but do the work because it pays well compared to other jobs in their areas. More recent research is showing that interest in STEM is nearly identical for women of all cultures, and it's a very low rate compared to men. This is on going research that has been going on for well over a decade and multiple different different well known universities.
Ask yourself why women in Iran have the same interest in STEM that women in India or China.
He's not talking about women, he's talking about people wanting to force women into our city. The geek city is open to any geek, but F those people and their money trying to change the fundamentals of what made the city great in the first place. Throwing money at a problem is generally not a good idea.
It's a desk job. No one cares about getting more women in dangerous jobs, but if there is a job that involves being safely contained in an office setting and doesn't involve being a servant type roll, they want more women./sarc
Women in tech: 10%
Women in tech who enjoy tech: 1%
Men in tech: 90%
Men in tech who enjoy tech: 1%
I predict that there are roughly the same number of good tech people of both male and female, the rest are in it because they're confused about what they wanted to do with their life or picked a random career that was "cool".
We're reaching a point where we have more transistors than we can turn on without melting the chip. You can have a lot of spare cores that are turned off and can be turned back on for the occasion jitter inducing burst of work. The extra cores act as a buffer to absorb unexpected work, while allowing your target core utilization as your average.
Traffic shapers already have this notion of "real time" traffic, where the packet scheduler can pretty much guarantee that latency sensitive traffic can get scheduled up to 80% of the link speed. Non latency sensitive traffic can use the other 20%, but that 20% cannot be used by real time traffic because it's too close to saturation to guarantee that the packet can get scheduled in time.
Collisions with Ethernet are because more than one thing are trying to send at the same time, which means there is too much going on. The issue with blocking and the whole back-off things is the problem they're trying to solve is keeping these cores from having to back-off in the first place. The backing off is making them sit idle for way too long.
I agree, the classic throughput vs latency. In the case of a high throughput 80 core CPU, I assume the trade-off is worth it, but for the quad-core desktop CPU, they might care more about not having their game stuttering.
They might be able to do a hybrid design where the break up latency sensitive tasks into smaller groups, where each group has a max number of shared cores to reduce contention, and the cores can be close to each other, because physical distance becomes an issue with large many core CPUs. Essentially two different schedulers to monitor.
Round Robbin is bad because it can have synchronization issues. What if a task takes hours or day to complete? Pre-populating a task can cause a task to never complete because you assigned a task to the "wrong" core.
They're not pushing or keeping a back-log of work to be done. Each core only accesses the task list once it's done with its current task, but it grabs a task random from a range of tasks at the beginning of the queue instead of just the first task.
"Distributing" requires something to push. You don't want to push because you might send a task to an already overloaded core. You could keep track of which core has the least amount of work remaining, assuming that's even possible to know, but then you're back to keeping a central data structure up to date with core information, and you've gained nothing.
You could break up cores into groups and have groups of cores share a common task pool, then have a central distribution logic monitor those pools. Everything comes with a trade off and random just works very well. Fewer corner cases and typically graceful degradation, compared to catastrophic performance lost due to an unforeseen interaction of task run-time patterns and the pool and the distribution algorithm.
I wonder just how many fibers they ran to the pole in the first place. With the tech they're using, you only need one fiber or fiber pair to the node, then the node uplinks to the fiber. With modern fiber networks, each customer gets their own separate strand of fiber. They may need to re-run the fiber or use a sub-optimal fiber design of having a fiber node. Modern fiber networks have no nodes. Fiber strait back to the trunk.
A lot of people say "if the remote server supports it". Huge numbers of remote servers support it, assuming they're something other than a small company or don't purposefully traffic shape. I've done quite a few trace routes on different ISPs during file transfers, and in my experience over half of the time that I got below line rate transfers was because a trace route showed latency and jitter on a peering link with the ISP, not an issue with the remote server.
My biggest issue tends to be server related and not network related. For example, when trying to stream some YouTube videos, certain videos for certain resolutions are sometimes slow. Start watching a video in 480p, has buffering issues, switch to 1080p, buffering issues gone. Maybe the 480p is in less demand and hasn't been cached recently?
The internet backbone has no issues other than peering disputes. 100Gb ports on the cheap, 400Gb ports getting popular and 1Tb ports around the corner and multiplexing tech that accepts any combination of 10gb/100Gb/400Gb ports and shoves 30Tb/s down a single fiber. A single fiber can handle 3,000 10Gb ports, 300 100Gb ports, 75 400Gb ports or any combination of the above with 1,300Km ranges. New multiplexing tech is in the works.
YouTube can burst at least 1Gb/s at me, it may be faster but I only have a 1Gb Ethernet port. How is your single 1Gb link able to handle people streaming YouTube without causing jitter issues?
Plenty of companies are building out fiber networks in rural areas for a profit. They already have fiber to many farms in the area, which means they can also purchase a 250Mb/250Mb dedicated fiber connection for $200/m. According to the brochure, 250Mb is great for Web Hosting, Ecommerce, cloud computing, large remote back-ups, video streaming, and uninterrupted gaming. 10Gb is around the corner; Simple upgrade since the network is already fiber.
That's right, start hosting the new NewEgg at a local farm with 250Mb of dedicated bandwidth to Level 3, the highest quality dedicated bandwidth in the world, for $200/month.
Before you say government subsidies, the ISP has already stated that they have refused all government loans and grants and have built their fiber network entirely on their own dime. Not bad for a locally owned ISP in a small town with high unemployment.
Too big of government is about as bad as too small. There are different levels of government. My local government is still very small, they're the ones that would be running muni-fiber.
The dual port network card in my PC router is worth more than $100. No matter how many packets I throw at my router, the interrupts per second never go above 300. Interrupt coalescing is awesome. It even coalesces across my LAN and WAN ports. It does this while keeping latency low. I get a 0.04ms ping. from my PC to my router through my switch. I can't measure lower than that because of thread scheduling.
How's your latency and jitter with 300Mbs? If all I did was game, I would rather have a stable 10Mb connection than a 300Mb unstable connection. Just wondering, because they tend to have a track record of bad quality, but they're using new tech that I am not familiar with.
It doesn't happen often because most programmers are in the same boat of not understanding. I'm the goto guy for performance related issues and I find myself redesigning and re-writing huge amounts of other people's code on my own to gain magnitudes of performance, but good luck explaining garbage collectors, query optimizer, false sharing, data locality, and a slew of other issues to someone. They may grasp the concept, but they cannot predict how their code decisions will affect many of these issues.
If you're writing C/C++, you may have a decent idea of what is going on, but we need to use stuff like SQL or.Net, and I've done a lot of reading in general theory and some implementation of how these managed languages interact with system resources and what they're actually doing. They're not just a blackbox to me. To me the end result isn't good enough, it's knowing how the end result was gotten. Endless curiously drives me.
The way I describe it to others is when I program, I first think of what the basic steps to accomplish a problem as if I was coding in ASM, then I think of what is the closest way I could get that ASM with whatever high level language I am working in.
You can teach a monkey how to do what you do, but not think how you think. Good programmers are a combination of creative and obsessive, two uncommon traits.
Many programmers have an issue of using the wrong tool because they don't understand the minor differences between two tools. All they know is doubles and ints are both numbers, so they don't care which ever they use, and their decision may not make a huge difference 80% of the time.
and writes code that is easy for them to navigate, digest, and change
Unless you're working on a complex problem that other programmers can't understand in the first place, and the most minute detail is important. Then you find yourself trying to explain to the other programmers that by not doing something, they're now using an extra cacheline and causing a 10% hit in performance on their quad core and a 35% performance hit on a dual socket server.
Slashdot Mirror
Not sending your children to school can land you in jail or have them taken from you for neglect. Why not vaccines.
Vaccines are not 100%, many require herd immunity to even work on a whole. Vaccines don't keep you from getting infected, they typically keep it from spreading and reduces the severity of the person who gets sick.
There's a lot of Indian and Chinese women who hate their programming job but do the work because it pays well compared to other jobs in their areas. More recent research is showing that interest in STEM is nearly identical for women of all cultures, and it's a very low rate compared to men. This is on going research that has been going on for well over a decade and multiple different different well known universities.
Ask yourself why women in Iran have the same interest in STEM that women in India or China.
He's not talking about women, he's talking about people wanting to force women into our city. The geek city is open to any geek, but F those people and their money trying to change the fundamentals of what made the city great in the first place. Throwing money at a problem is generally not a good idea.
It's a desk job. No one cares about getting more women in dangerous jobs, but if there is a job that involves being safely contained in an office setting and doesn't involve being a servant type roll, they want more women. /sarc
This is my concept of how things are going
Women in tech: 10%
Women in tech who enjoy tech: 1%
Men in tech: 90%
Men in tech who enjoy tech: 1%
I predict that there are roughly the same number of good tech people of both male and female, the rest are in it because they're confused about what they wanted to do with their life or picked a random career that was "cool".
We're reaching a point where we have more transistors than we can turn on without melting the chip. You can have a lot of spare cores that are turned off and can be turned back on for the occasion jitter inducing burst of work. The extra cores act as a buffer to absorb unexpected work, while allowing your target core utilization as your average.
Traffic shapers already have this notion of "real time" traffic, where the packet scheduler can pretty much guarantee that latency sensitive traffic can get scheduled up to 80% of the link speed. Non latency sensitive traffic can use the other 20%, but that 20% cannot be used by real time traffic because it's too close to saturation to guarantee that the packet can get scheduled in time.
Collisions with Ethernet are because more than one thing are trying to send at the same time, which means there is too much going on. The issue with blocking and the whole back-off things is the problem they're trying to solve is keeping these cores from having to back-off in the first place. The backing off is making them sit idle for way too long.
Given enough throughput, you can statistically reduce your jitter to some low number. The transition could be painful.
I agree, the classic throughput vs latency. In the case of a high throughput 80 core CPU, I assume the trade-off is worth it, but for the quad-core desktop CPU, they might care more about not having their game stuttering.
They might be able to do a hybrid design where the break up latency sensitive tasks into smaller groups, where each group has a max number of shared cores to reduce contention, and the cores can be close to each other, because physical distance becomes an issue with large many core CPUs. Essentially two different schedulers to monitor.
Spray List optimizes multi-tasking and thread scheduling. The jobs that have to be executing in order are what are being randomly selected.
Round Robbin is bad because it can have synchronization issues. What if a task takes hours or day to complete? Pre-populating a task can cause a task to never complete because you assigned a task to the "wrong" core.
They're not pushing or keeping a back-log of work to be done. Each core only accesses the task list once it's done with its current task, but it grabs a task random from a range of tasks at the beginning of the queue instead of just the first task.
"Distributing" requires something to push. You don't want to push because you might send a task to an already overloaded core. You could keep track of which core has the least amount of work remaining, assuming that's even possible to know, but then you're back to keeping a central data structure up to date with core information, and you've gained nothing.
You could break up cores into groups and have groups of cores share a common task pool, then have a central distribution logic monitor those pools. Everything comes with a trade off and random just works very well. Fewer corner cases and typically graceful degradation, compared to catastrophic performance lost due to an unforeseen interaction of task run-time patterns and the pool and the distribution algorithm.
Now you just need to define what a "task" is. This is normally an OS or framework construct.
I wonder just how many fibers they ran to the pole in the first place. With the tech they're using, you only need one fiber or fiber pair to the node, then the node uplinks to the fiber. With modern fiber networks, each customer gets their own separate strand of fiber. They may need to re-run the fiber or use a sub-optimal fiber design of having a fiber node. Modern fiber networks have no nodes. Fiber strait back to the trunk.
A lot of people say "if the remote server supports it". Huge numbers of remote servers support it, assuming they're something other than a small company or don't purposefully traffic shape. I've done quite a few trace routes on different ISPs during file transfers, and in my experience over half of the time that I got below line rate transfers was because a trace route showed latency and jitter on a peering link with the ISP, not an issue with the remote server.
My biggest issue tends to be server related and not network related. For example, when trying to stream some YouTube videos, certain videos for certain resolutions are sometimes slow. Start watching a video in 480p, has buffering issues, switch to 1080p, buffering issues gone. Maybe the 480p is in less demand and hasn't been cached recently?
The internet backbone has no issues other than peering disputes. 100Gb ports on the cheap, 400Gb ports getting popular and 1Tb ports around the corner and multiplexing tech that accepts any combination of 10gb/100Gb/400Gb ports and shoves 30Tb/s down a single fiber. A single fiber can handle 3,000 10Gb ports, 300 100Gb ports, 75 400Gb ports or any combination of the above with 1,300Km ranges. New multiplexing tech is in the works.
YouTube can burst at least 1Gb/s at me, it may be faster but I only have a 1Gb Ethernet port. How is your single 1Gb link able to handle people streaming YouTube without causing jitter issues?
Plenty of companies are building out fiber networks in rural areas for a profit. They already have fiber to many farms in the area, which means they can also purchase a 250Mb/250Mb dedicated fiber connection for $200/m. According to the brochure, 250Mb is great for Web Hosting, Ecommerce, cloud computing, large remote back-ups, video streaming, and uninterrupted gaming. 10Gb is around the corner; Simple upgrade since the network is already fiber.
That's right, start hosting the new NewEgg at a local farm with 250Mb of dedicated bandwidth to Level 3, the highest quality dedicated bandwidth in the world, for $200/month.
Before you say government subsidies, the ISP has already stated that they have refused all government loans and grants and have built their fiber network entirely on their own dime. Not bad for a locally owned ISP in a small town with high unemployment.
Too big of government is about as bad as too small. There are different levels of government. My local government is still very small, they're the ones that would be running muni-fiber.
The dual port network card in my PC router is worth more than $100. No matter how many packets I throw at my router, the interrupts per second never go above 300. Interrupt coalescing is awesome. It even coalesces across my LAN and WAN ports. It does this while keeping latency low. I get a 0.04ms ping. from my PC to my router through my switch. I can't measure lower than that because of thread scheduling.
How's your latency and jitter with 300Mbs? If all I did was game, I would rather have a stable 10Mb connection than a 300Mb unstable connection. Just wondering, because they tend to have a track record of bad quality, but they're using new tech that I am not familiar with.
It doesn't happen often because most programmers are in the same boat of not understanding. I'm the goto guy for performance related issues and I find myself redesigning and re-writing huge amounts of other people's code on my own to gain magnitudes of performance, but good luck explaining garbage collectors, query optimizer, false sharing, data locality, and a slew of other issues to someone. They may grasp the concept, but they cannot predict how their code decisions will affect many of these issues.
.Net, and I've done a lot of reading in general theory and some implementation of how these managed languages interact with system resources and what they're actually doing. They're not just a blackbox to me. To me the end result isn't good enough, it's knowing how the end result was gotten. Endless curiously drives me.
If you're writing C/C++, you may have a decent idea of what is going on, but we need to use stuff like SQL or
The way I describe it to others is when I program, I first think of what the basic steps to accomplish a problem as if I was coding in ASM, then I think of what is the closest way I could get that ASM with whatever high level language I am working in.
You can teach a monkey how to do what you do, but not think how you think. Good programmers are a combination of creative and obsessive, two uncommon traits.
Many programmers have an issue of using the wrong tool because they don't understand the minor differences between two tools. All they know is doubles and ints are both numbers, so they don't care which ever they use, and their decision may not make a huge difference 80% of the time.
and writes code that is easy for them to navigate, digest, and change
Unless you're working on a complex problem that other programmers can't understand in the first place, and the most minute detail is important. Then you find yourself trying to explain to the other programmers that by not doing something, they're now using an extra cacheline and causing a 10% hit in performance on their quad core and a 35% performance hit on a dual socket server.