For global warming, a slight increase in temperature results in a large increase in standard deviation. Higher highs and lower lows with a small increase in the average. It's a normal phenomena that the more energy there is in a system that has a cold and hot side, the wilder the self-forming structures in an attempt for physics to equalize. Energy distribution is not uniform.
Looks like IOMMU is roughly a 15% cpu overhead because of memory virtualization overhead causing increased cache invalidation. But can be up to 60% overhead for events 256bytes and smaller. This might apply for keyboard key presses where the datastructure for the event is larger than the data to indicate which key was pressed or a UDP flood on a network interface, most other hardware devices are going to be dealing in 512byte+ chucks of data at a time. ~15% cpu cost should be the most common.
15% additional CPU cost on IO seems cheap to me. Most of my IO requires virtually no CPU because of offloading and DMA access. To give an example. Transferring 940Mb/s(114MiB/s) over Ethernet copying a file from one Windows machine to another over SMB results in about 0.5% cpu usage on my quad core. A 15% increase would push it to 0.575%
When I say "self-discovered many common multithreading building block", I mean like compare-and-swap, atomic reads, atomic writes, channels, ordering, etc. I did not make any implementations of any of these, but around the age of 11, I realized these issue MUST exist as they are a physical requirement of our universe, and regardless of how these common operations are implemented, I could continue thinking about concurrency problems.
To me, torn reads, torn writes, and ordering are fundamental issues that something must be responsible for. And it was my conclusion that to keep two independent CPUs in perfect sync would require a great performance cost to transistor count, clock rate and-or latency. I did not have read any of this anywhere or test it or see existing code. All of these issues I was able to reasonably assume must exist because of my basic understanding of physics.
This wasn't some long term issue that I spent forever on. All of these issues were almost immediately obvious, It was a kind of problem you look at, have an gut reaction to notice that the devil is in the details, sleep on it, and realized the issues in the morning. All of this I was able to infer just from seeing a marketing ad for a dual socket 486.
The biggest issue I face with multithreading is finding pre-existing code that implements my ideas. My assumption about my ideas is someone has already thought about this problem and solved it in an elegant way. I really hate rolling my own concurrent data structures and algorithms, but I've done it many times with great success. Still doesn't mean I am proud of rolling my own. Though, I have been bitten by more concurrency issues in mature frameworks and libraries than my own code. It comes down to risk management. I can't go my whole life being worried that other highly publicly scrutinized code may have some stupid bug that I would have never missed. There is a certain value in conformity.
Nothing is easy to multithread in because multithreading anything more than the most basic of processes is inherently complex
I'll agree that multithreading makes a problem more complex, but I disagree that multithreading makes a problem too complex. Many problems are naturally asynchronous and/or concurrent, and I am not talking about embarrassingly parallel problems.
I self-discovered many common multithreading building block patterns at the age of 11 without any books or teachers. I read about multi-CPU 486 computers and spent several days obsessing about the problem, thinking about how one would allow two independent CPUs to work together. I find multithreading quite intuitive. I would argue that it is no more difficult to design a multithreaded application than it is to design a distributed web application that is so common these days in AWS.
Einstein did not do away with gravity, just better explained it. Gravity is an observed phenomena, you can't just make an observation disappear. Even without relativity, one of Einstein's thought experiments proved gravity is not a force. Forces can be measured with an accelerometer. Gravity cannot. Use an accelerometer on an object in orbit and no acceleration is measured. If gravity was a force, acceleration would be measured. Not to mention that acceleration takes energy. If an object in orbit was actually accelerating, it would have nearly infinite energy.
1) This discussion is about DST and timezones in general, but I guess that wooshed right over you.
2) Is thinking about the future such a difficult issue? What about the moon or Mars?
3) They must be big words to you because you clearly don't understand what "monotonic" means if you think DST is monotonic.
4) Relativistic issue as in a different gravity well that causes a substantial difference in the measured monotonic progression of time
Simply get up based on sunrise and go to bed based on sunset.
So.. Get up at 7am and go to sleep at 3pm? During the dead of winter, Alaska doesn't even have a sunrise for several months. Time needs to work by the same rules for at least all people on earth. Time should be made monotonic and we can worry about relativistic issues in the far future.
I really have to emphasize how short day light is up north. A 1 hour shift does absolutely nothing. In fact, it makes it worse. Day light gets to be so short that centering around the noon time sun means it's dark when I went to school and dark when I left school and same for work. I rarely got to see the sun because it was often too cold to play outside according to the school. If DST never happened, I'd actually get about 30min of sun outside of school/work hours.
In practice, DST reduces the amount of sun I get to see. And don't get the farmers started. They almost don't even care about time in the same way most do. They start work when the animals need them. DST is an ivory tower idea that misses the finer details resulting in it making the situation it attempts to help, worse.
I'm from that general area. DST is annoying except for people who want an extra hour to drink at the bar. School doesn't have to start at "7:30am" all year long. It can start at 7:30a at one time of the year and 8:30a at another time. Problem solved. Does the same thing without the retarded obsession of trying to match time with the sun. Why the fk would you care about where the sun is when you only get 6 hours of it?! It's gone almost all day during the time of year that DST is meant to help. Even when the sun is up, I can't see it through these thick winter clouds.
Yay, noon time matches peak sun.... for a few days of the year. I know, lets go full retard. Daylight shifts by 3 minutes every day. Lets have a dst for every day of the year, that'll be even better! Can you imagine of the utopia?
DST is unnecessary complexity for a simple problem that is only a problem because people make it to be a problem.
There was an interesting article about shared conduit recently. I can't say if it's a fundamental issue or an implementation issue, but several communities that tried shared conduit found it to be a waste of money because the conduit gets damaged and other issues, and in the end, no one wants to use it because it's more costly and issue prone in the long run than just trenching your own.
They used horizontal drilling over here. Lets them get under roads. I was told 18"-24" underground on public property. In my lawn they just trenched using a vibratory plow, 8"-12" deep.
I can't argue about the validity of what they're measuring, but it seems they're measuring the perception of civility. It's entirely possible that people have become more "rude", but others are more willing to put up with it. I quoted "rude" because what is considered rude is a social perception.
HTTPS scanning and proxy is a known attack vector. HTTPS provides both encryption and authentication. MITM breaks authentication. Unfortunately, HTTP does not support signing content, only the outer stream can be signed.
I tried UV a few times over the years by entering in codes from purchased movies. It only gave access to SD streams. Even for SD, it was crappy quality. I was having flashbacks of watching watching pirated full length movies back from the 90s. Realtime called, wanted its compression algorithms back.
There is no lack of programmers, there's only a gross mismanagement of existing talent. Dilbert effect + bean counting + micromanagement absolutely destroys productivity when it comes these problem domains. Just look at the issue with architecture and design. Case study after case study shows it's 10x more expensive to fix a problem after it gets deployed in testing and 100x more expensive after deployed in production. Agile doesn't do crap against this and many implementations of Agile makes it worse. Take the extra 10% time to go over your design and figure out and deal with your edge cases before you paint yourself into a corner.
Adding more people to a project tends to make each person less productive. Taken to the extremes that I see, the number of programmers on a project can easily make a communications deadlock where no one is moving in the same direction but no one can stop working to the take the time to figure out what direction to go in. Everyone keeps busy doing meaningless work, but at least they get to keep their job. Get a proper architect and stop micromanaging, that's what I have to say about the phantom "programmer shortage".
CS is not a fundamental critical skill, critical thinking is. Public education should be focused primarily on core fundamentals and touch just enough on other areas to give students a taste of different job roles in society.
Schools also need to be very careful about how enthusiastically they push, I mean, encourage specific jobs. Many schools tend to treat skills as rote memorization and a worse yet is the whole participation award attitude to make classes easy enough to not "scare" students away. CS is hard, 80% of people who attempt CS at college level royally faceplant, and 80% of those who make it are below average.
Customer Service, Marketing, and Sales compromise about 99% of the cost of an ISP. Bandwidth is a fraction of the remaining 1%. Providing internet access is effectively free, supporting your existing customer base and attracting new customers is expensive.
Of course it doesn't cost "nothing", but for any typical ISP in 80% of populated locations in the USA, bandwidth and infrastructure maintenance and upgrades represents 1-2% of operating costs.
but idiots whose noses are held too high for that would spend an hour chasing things around in a debugger to figure out they had a typo or an incorrect dependency version.
An action in and of itself is neither right or wrong, it's the reasoning. The more I "waste time debugging", the better I get at correctly identifying when I should skip debugging and quickly search. Personally, I like the challenge. This does make me slower, but the more I learn from my mistakes, the less often I make mistake and the faster I realize what my mistake was.
This has an unforeseen side effect that the bulk of production issues are because many programmers use error messages as a crutch, and quickly finding the answer reduces the amount of mental effort, aka exercise, in order to reason about the issue. I am in no way saying what you're doing is wrong. I am just saying is that anyone who does an action because the action is the correct way to do something is just doing a rain dance. Each person is different and need to find out what works best for themselves, but there are some good rules of thumb that should be learned and practiced before making personal alterations to processes that tend to work well.
The opposite is equally bad. Women are less likely to stand up for themselves and tend to favor conformity over being correct. They're easier to convince that they're wrong even when they're not. And this is a big issue in STEM fields. People don't like to think and treat rules of thumb as absolute facts. About 10% of STEM workers produce about 50% of the value, and they tend to get paid along those lines. When you're 10x more value than your co-workers, you have to stand up for yourself unless you want to be dragged down to their level.
And it's a fractal all the way up. The top 10% of the top 10% represent 25% of value.
Slashdot Mirror
If only there was a way to make the sun shine and the wind blow 24/7. Then we'd be able to always match supply and demand.
For global warming, a slight increase in temperature results in a large increase in standard deviation. Higher highs and lower lows with a small increase in the average. It's a normal phenomena that the more energy there is in a system that has a cold and hot side, the wilder the self-forming structures in an attempt for physics to equalize. Energy distribution is not uniform.
https://www.kernel.org/doc/ols...
Looks like IOMMU is roughly a 15% cpu overhead because of memory virtualization overhead causing increased cache invalidation. But can be up to 60% overhead for events 256bytes and smaller. This might apply for keyboard key presses where the datastructure for the event is larger than the data to indicate which key was pressed or a UDP flood on a network interface, most other hardware devices are going to be dealing in 512byte+ chucks of data at a time. ~15% cpu cost should be the most common.
15% additional CPU cost on IO seems cheap to me. Most of my IO requires virtually no CPU because of offloading and DMA access. To give an example. Transferring 940Mb/s(114MiB/s) over Ethernet copying a file from one Windows machine to another over SMB results in about 0.5% cpu usage on my quad core. A 15% increase would push it to 0.575%
When I say "self-discovered many common multithreading building block", I mean like compare-and-swap, atomic reads, atomic writes, channels, ordering, etc. I did not make any implementations of any of these, but around the age of 11, I realized these issue MUST exist as they are a physical requirement of our universe, and regardless of how these common operations are implemented, I could continue thinking about concurrency problems.
To me, torn reads, torn writes, and ordering are fundamental issues that something must be responsible for. And it was my conclusion that to keep two independent CPUs in perfect sync would require a great performance cost to transistor count, clock rate and-or latency. I did not have read any of this anywhere or test it or see existing code. All of these issues I was able to reasonably assume must exist because of my basic understanding of physics.
This wasn't some long term issue that I spent forever on. All of these issues were almost immediately obvious, It was a kind of problem you look at, have an gut reaction to notice that the devil is in the details, sleep on it, and realized the issues in the morning. All of this I was able to infer just from seeing a marketing ad for a dual socket 486.
The biggest issue I face with multithreading is finding pre-existing code that implements my ideas. My assumption about my ideas is someone has already thought about this problem and solved it in an elegant way. I really hate rolling my own concurrent data structures and algorithms, but I've done it many times with great success. Still doesn't mean I am proud of rolling my own. Though, I have been bitten by more concurrency issues in mature frameworks and libraries than my own code. It comes down to risk management. I can't go my whole life being worried that other highly publicly scrutinized code may have some stupid bug that I would have never missed. There is a certain value in conformity.
Nothing is easy to multithread in because multithreading anything more than the most basic of processes is inherently complex
I'll agree that multithreading makes a problem more complex, but I disagree that multithreading makes a problem too complex. Many problems are naturally asynchronous and/or concurrent, and I am not talking about embarrassingly parallel problems.
I self-discovered many common multithreading building block patterns at the age of 11 without any books or teachers. I read about multi-CPU 486 computers and spent several days obsessing about the problem, thinking about how one would allow two independent CPUs to work together. I find multithreading quite intuitive. I would argue that it is no more difficult to design a multithreaded application than it is to design a distributed web application that is so common these days in AWS.
Einstein did not do away with gravity, just better explained it. Gravity is an observed phenomena, you can't just make an observation disappear. Even without relativity, one of Einstein's thought experiments proved gravity is not a force. Forces can be measured with an accelerometer. Gravity cannot. Use an accelerometer on an object in orbit and no acceleration is measured. If gravity was a force, acceleration would be measured. Not to mention that acceleration takes energy. If an object in orbit was actually accelerating, it would have nearly infinite energy.
1) This discussion is about DST and timezones in general, but I guess that wooshed right over you.
2) Is thinking about the future such a difficult issue? What about the moon or Mars?
3) They must be big words to you because you clearly don't understand what "monotonic" means if you think DST is monotonic.
4) Relativistic issue as in a different gravity well that causes a substantial difference in the measured monotonic progression of time
So do parents of children have to adjust their personal work schedules to accommodate your continuously variable start and end of the school day
We already do this with DST. Is that so hard to grasp?
Simply get up based on sunrise and go to bed based on sunset.
So.. Get up at 7am and go to sleep at 3pm? During the dead of winter, Alaska doesn't even have a sunrise for several months. Time needs to work by the same rules for at least all people on earth. Time should be made monotonic and we can worry about relativistic issues in the far future.
I really have to emphasize how short day light is up north. A 1 hour shift does absolutely nothing. In fact, it makes it worse. Day light gets to be so short that centering around the noon time sun means it's dark when I went to school and dark when I left school and same for work. I rarely got to see the sun because it was often too cold to play outside according to the school. If DST never happened, I'd actually get about 30min of sun outside of school/work hours.
In practice, DST reduces the amount of sun I get to see. And don't get the farmers started. They almost don't even care about time in the same way most do. They start work when the animals need them. DST is an ivory tower idea that misses the finer details resulting in it making the situation it attempts to help, worse.
I'm from that general area. DST is annoying except for people who want an extra hour to drink at the bar. School doesn't have to start at "7:30am" all year long. It can start at 7:30a at one time of the year and 8:30a at another time. Problem solved. Does the same thing without the retarded obsession of trying to match time with the sun. Why the fk would you care about where the sun is when you only get 6 hours of it?! It's gone almost all day during the time of year that DST is meant to help. Even when the sun is up, I can't see it through these thick winter clouds.
Yay, noon time matches peak sun.... for a few days of the year. I know, lets go full retard. Daylight shifts by 3 minutes every day. Lets have a dst for every day of the year, that'll be even better! Can you imagine of the utopia?
DST is unnecessary complexity for a simple problem that is only a problem because people make it to be a problem.
you can just ask what time it is there
If there were no timezones, you could just ask them what times they're open and do no calculations.
There was an interesting article about shared conduit recently. I can't say if it's a fundamental issue or an implementation issue, but several communities that tried shared conduit found it to be a waste of money because the conduit gets damaged and other issues, and in the end, no one wants to use it because it's more costly and issue prone in the long run than just trenching your own.
They used horizontal drilling over here. Lets them get under roads. I was told 18"-24" underground on public property. In my lawn they just trenched using a vibratory plow, 8"-12" deep.
I was doing this kind of stuff strait out of college with about 2 weeks experience programming.
+1 funny/civil
I can't argue about the validity of what they're measuring, but it seems they're measuring the perception of civility. It's entirely possible that people have become more "rude", but others are more willing to put up with it. I quoted "rude" because what is considered rude is a social perception.
HTTPS scanning and proxy is a known attack vector. HTTPS provides both encryption and authentication. MITM breaks authentication. Unfortunately, HTTP does not support signing content, only the outer stream can be signed.
I tried UV a few times over the years by entering in codes from purchased movies. It only gave access to SD streams. Even for SD, it was crappy quality. I was having flashbacks of watching watching pirated full length movies back from the 90s. Realtime called, wanted its compression algorithms back.
There is no lack of programmers, there's only a gross mismanagement of existing talent. Dilbert effect + bean counting + micromanagement absolutely destroys productivity when it comes these problem domains. Just look at the issue with architecture and design. Case study after case study shows it's 10x more expensive to fix a problem after it gets deployed in testing and 100x more expensive after deployed in production. Agile doesn't do crap against this and many implementations of Agile makes it worse. Take the extra 10% time to go over your design and figure out and deal with your edge cases before you paint yourself into a corner.
Adding more people to a project tends to make each person less productive. Taken to the extremes that I see, the number of programmers on a project can easily make a communications deadlock where no one is moving in the same direction but no one can stop working to the take the time to figure out what direction to go in. Everyone keeps busy doing meaningless work, but at least they get to keep their job. Get a proper architect and stop micromanaging, that's what I have to say about the phantom "programmer shortage".
CS is not a fundamental critical skill, critical thinking is. Public education should be focused primarily on core fundamentals and touch just enough on other areas to give students a taste of different job roles in society.
Schools also need to be very careful about how enthusiastically they push, I mean, encourage specific jobs. Many schools tend to treat skills as rote memorization and a worse yet is the whole participation award attitude to make classes easy enough to not "scare" students away. CS is hard, 80% of people who attempt CS at college level royally faceplant, and 80% of those who make it are below average.
People good at CS tend to already get into CS.
Customer Service, Marketing, and Sales compromise about 99% of the cost of an ISP. Bandwidth is a fraction of the remaining 1%. Providing internet access is effectively free, supporting your existing customer base and attracting new customers is expensive.
Of course it doesn't cost "nothing", but for any typical ISP in 80% of populated locations in the USA, bandwidth and infrastructure maintenance and upgrades represents 1-2% of operating costs.
but idiots whose noses are held too high for that would spend an hour chasing things around in a debugger to figure out they had a typo or an incorrect dependency version.
An action in and of itself is neither right or wrong, it's the reasoning. The more I "waste time debugging", the better I get at correctly identifying when I should skip debugging and quickly search. Personally, I like the challenge. This does make me slower, but the more I learn from my mistakes, the less often I make mistake and the faster I realize what my mistake was.
This has an unforeseen side effect that the bulk of production issues are because many programmers use error messages as a crutch, and quickly finding the answer reduces the amount of mental effort, aka exercise, in order to reason about the issue. I am in no way saying what you're doing is wrong. I am just saying is that anyone who does an action because the action is the correct way to do something is just doing a rain dance. Each person is different and need to find out what works best for themselves, but there are some good rules of thumb that should be learned and practiced before making personal alterations to processes that tend to work well.
The opposite is equally bad. Women are less likely to stand up for themselves and tend to favor conformity over being correct. They're easier to convince that they're wrong even when they're not. And this is a big issue in STEM fields. People don't like to think and treat rules of thumb as absolute facts. About 10% of STEM workers produce about 50% of the value, and they tend to get paid along those lines. When you're 10x more value than your co-workers, you have to stand up for yourself unless you want to be dragged down to their level.
And it's a fractal all the way up. The top 10% of the top 10% represent 25% of value.