We are pretty good at lifting things above the atmosphere. As for "really big", the farther from the earth the structure is the more shade it generates. Yes technological inventions are necessary, but we went from no powered flight to landing on the moon in 66 years and the pace of technological innovation has greatly improved since then. Its mostly a matter of starting to work on the problem.
4x the number of solar panels in the darkness or the shade doesn't really help. 4x the number of wind turbines in the still air doesn't really help. Storage would help but that's an evolving technology, its scalability unproven. The reality is that Europe has doubled their imports of coal from the US, and also increased natural gas imports from the Russian oligarchs/Putin, to help make up for the decommissioning of nuclear. A decommissioning that was largely driven by **politics** not economics.
And opponents of nuclear overlook a secondary benefit of modern reactors. They help clean up the mess left behind by the older reactors. We don't need to figure out how to safely store all our current nuclear waste for tens of thousands of years, much of it can be consumed as fuel in more modern reactor designs. That also needs to be part of the economic calculation of nuclear.
Or, we could use cheaper power sources, like wind and solar.
That's what the EU thought. They shut down nuclear and now are importing twice as much coal from the US. Wind and solar need backup and without nuclear that will be natural gas and coal.
You seem to assume climate is a symmetric linear system. It is not. It is non-linear and it could be much harder to reverse climate change than initiate it.
Actually history shows that global cooling is quite feasible, volcanic winters, periods of low solar activity resulting in mini-ice ages (1400s, 1600s), etc.
The malthusian failing has repeatedly been your concept of a symmetric steep hill from which there is no return. Through science and engineering we have repeatedly found that "steep hill" is quite flat on the other unseen side.
Malthus and his followers repeatedly fall into the trap of looking at one variable and *assuming* all other are held constant. Science and engineering often avoid malthusian disasters by operating on the other variables that are not really constants. With respect to climate engineering two such variables may be the solar energy reaching the earth and the amount of this energy that is reflected back into space. I suppose some might argue improvements in carbon capture and sequestration technology but I'm just going to stick with shade and reflection for now.
Again, to be clear, I'm all for conservation, increased efficiency, alternative energy (wind, solar, tidal, geothermal, nuclear, biofuels, etc)... but I expect some climate engineering will **also** be necessary. Best to get that on the radar earlier than later.
Yes. You do know the problem with CO2? In help retain heat from the sun. You know what help counteracts this? Shade. As far as I know shade does not violate the law of entropy.
Conversion of energy from other forms into heat is not known to be reversible.
The earth is being continuously heated by the sun, the problem with CO2 is the increased capture of this heat. Climate engineering would likely involve well known concepts like more shade so there is less heat to be captured.
While I would like to agree, we kind of bumbled our way into this one. While I dont think we are quite there yet, I'm not so sure we are ready to tackle a runaway scenario.
In 66 years, 1903-1969, we went from the first powered flight to landing on the moon. And the pace of scientific and engineering progress has accelerated since then. Much of that aerospace progress was made in the era of paper, pencil and slide rules. Our smart watches have more computation power than 1969 Apollo mission computers.
Seems a bit Malthusian, and Malthus loses over and over to science and engineering.
Do not misunderstand, I am in favor of conservation, alternative sources, etc. However "irreversible" seems a bit alarmist and BS'ish. Human activity pushed the climate in one direction, it can push it in the other direction as well via science and engineering. Again, it would be best not to have to resort to climate engineering, but climate engineering can make things reversible.
Why bulk up a laptop with a real keyboard when the laptop's primary features are mobility and compactness. That for any extended duration typing a person is more likely to be at the office or at home. The tradeoff that has a more broad appeal seems to be compactness when mobile and the flexibility of external for home or office when the extended typing is more likely.
Its kind of hard to think of not using an external display at the office or home when in "work" mode, so an external keyboard and mouse seems quite natural.
There is no need to lug around an external. One for the office and possibly a second for home. Most users probably do a relatively small amount of *work* related typing when traveling and on the couch.
Also note I was responding to a claim that *current* Apple laptops are not designed for work. These current keyboards are sufficient for travel and couch. I am *not* defending the notion of a touch screen keyboard, I agree that this would be a bad idea. However I disagree regarding the current keyboards. Which I am typing on right now while on my couch. My desk upstairs has a G4 era mechanical USB Apple keyboard. I prefer these over the current Apple externals, I'd probably use a Unicomp Mac keyboard if my 2 G4 era keyboards died.
Quit trying to make the damn laptop so thin and put a good keyboard in it. IMHO Apple's obsession with thin is form over function.
The real alternative is to get an external keyboard (and mouse and display) for office and/or home. You only need to use the built-in keyboard when away from home or office.
And yes, that includes the modern Model-M keyboards from Unicomp.
*Laptop*, where mobility and compactness may be more important. When at your desk at the office or home, where people may do more typing, plug in the external keyboard, mouse and display. Working from the laptop's display and keyboard at the office is a joke, its only for those idiotic open floor plan offices that provide nothing more than crappy tables and chairs. Any employer with half a brain will provide external displays, keyboard and mice, as will any half serious home worker.
CS grads that have an inherent interest in software development
That's really what it comes down to at the end of the day, not whether you went to university.
Yes and no. Combine inherent interest and self motivated study with the formal training and the person will likely be even stronger. The university adds to, it doesn't take away from, such a person. Now if the options are a self taught person with the interest and self motivation and a person with a degree that was a "ticket puncher" who showed up and did the minimal required and nothing else, yes, I'd prefer the self taught. The gaps the self taught usually have are easier to deal with. But don't dismiss the formal university program, the self taught person whose personal study will equal a formal program is exceptionally rare.
And frankly, that is how it should be. Class time for concepts and theory that outlive the operating system and programming language of the day, the OS and lang being left as an "exercise for the student". The university is not merely about sitting in classrooms and having knowledge handed to you, you and your fellow students puzzling things out and learning from each other is supposed to be part of the university experience too. And given the amazing access to equipment and expertise one has at a university not indulging in personal projects unrelated to class is quite the lost opportunity.
Regarding professors, the programming expertise might be more contextual. For one of those data structures and algorithms classes taught in pascal my professor was no pascal expert, he knew enough to teach the class but that was about where his interest in the language dropped off. Now when I had him for upper division AI classes. he was quite the expert in LISP which he had been using for decades. It didn't take too long to figure out what professors were the local experts in one language or another, so for office hour questions it was really about knowing who to ask. And like CS students, some professors learned what they needed to and just stuck with that, and others had this innate curiosity and learned new operating systems and languages to satisfy their own curiosity not because they needed to for school or work.
My only complaint of CS majors is that you guys please stick to theory and math. Please donâ(TM)t lecture engineers on how things work in the physical world.
Actually the theory is quite useful and helps in the real world. An example from molecular visualization prior to ubiquitous 3d hardware, i.e. software based rendering days. A "non-theory person" quite familiar with the language and standard library used the built in sort function to get a z-sort of atoms in preparation for rendering. The "theory person" with the theoretical understanding knew that the appropriate sorting algorithm would depend on the current data, which from one rendering to the next would be mostly sorted. Knew that the commonly stated run-times for various sort algorithms assumed random data and were therefore erroneous. A quick check of references showed that for mostly sorted data the standard library algorithm was actually a quite poor choice. The "theory person" implemented a more obscure sorting algorithm with excellent performance given the nature of the data and the atom z sort code dropped off the profiler hot spot list. After many such improvements of the code, at an industry trade show, various visitors to the booth were surprised that commodity PC hardware could offer such visualization performance.
The better programmers understand the practical elements of the hardware and the programming languages *and* they understand the theory. I know engineers who built things sitting on the moon today, they understood the practical and the theory quite well.
The theory taught in CS courses has plenty of application and there are plenty of CS people who can overcome the limits of their education, however a high density of CS degrees in a software development team has often in my experience correlated with problems.
Then you have not learned how to differentiate between the CS grads who chose that degree program because they had an inherent interest in programming and those that chose that program because a parent, guidance councilor, etc told them it was a good career path.
Here's a simple way to tell the two apart. Has the recent grad written *anything* unrelated to class assignments? I don't care what their personal project was, sometimes I have to coax it out of them because they think it too simple or too stupid a project. But they are mistaken, all I am really looking for is that they had some sort of personal curiosity or "need" to sit down and write some code that was not an assignment from a professor, a boss, etc. Something purely for themselves.
Your "overcome the limits of their education" comment is misguided, you don't understand a good CS program. Learning to program is left as an exercise to the student, they are expected to learn, outside of class (maybe there is a TA session to help), the necessary programming language to complete assignments. Some do the absolute minimum, these are the "ticket punchers" who take the class to get the degree to get the job, they aren't really there to learn. Others will be more thorough in learning some programming language, will start to think about problems beyond the class assignment, may try to code up a solution to one of those on their own initiative to satisfy their curiosity as to whether they know enough to pull it off, etc. These "stretch goals" are actually expected and encouraged by the good professors. What you think is some extra work they have to perform to make up some shortcoming is actually work expected by the professors, the "exercises" left to the student on their own time.
Now if you want to rephrase your argument that the less capable students are allowed to somehow skate through the program and graduate that is a valid complaint. But to think that good CS programs do not produce good programmers, that is misinformed.
Kind of like how not everyone needs to hire someone who designs programming languages or builds compilers, right?
Studying programming languages and compilers is important. Such a foundation to build upon is how we CS grads can easily learn and switch to whatever "new" language is the flavor of the moment, while writing decent code that has some understanding of the limitations of the underlying architecture it all runs on.
Not having such a foundation can lead to those degenerate situation where "fans" of a language try to use it everywhere for anything and require 3 GHz quad core CPUs and 16 GB of RAM to accomplish relatively simple things.
In short those CS classes and projects teach a young developer there are many ways to do things, a wide variety of tools are available, some tools are better for some tasks, and they learn a little about what happens at the architecture level where all the levels of abstraction have to meet and execute on the available hardware.
Now can a young developer learn these things outside a formal degree program, sure, but very few have the personal initiative to do so and most need the coercing of the university. And the direction of the university as well since many of the seemingly "unnecessary" classes actually turn out to be useful.
...so much software is written now, and the tools are so mature and easy to use, not everyone needs a CS degree to write all software.
If you think a CS degree is limited to complex problems and inapplicable to modest projects, you are mistaken. CS and other degree programs are a foundation, and with a stronger foundation the personal study one does and the experience one gains will be more effective. Again, its just starting on day one with a bigger toolbox and more tools.
And for the record, I've gone both the self taught and formal university route. The former is not a replacement for the later, the two are not mutually exclusive, and the CS grads that have an inherent interest in software development (as opposed to those who were told its a good career path) likely have practiced the former as well.
Actually compiling would not be one of those rare instances. I/O and RAM are also huge factors.
You have it exactly backwards. The more RAM accesses you have, the more SMT helps.
You misunderstand, its the amount of RAM that can greatly effect compilation speed.
... And I/O has almost nothing to do with SMT because the OS takes care of that... a thread waiting for I/O is not running, or in other words, not in any CPU core, so not affected by SMT.
You misunderstand, its the amount of I/O that can greatly effect compilation speed.
And again, **diminishing returns**, 8 core vs 8 core + HT will probably be less helpful than 2 vs 4 cores or 4 vs 8 cores. 8 cores without hyper threading is not wimpy.
You are talking nonsense. I get my fastest compiles with 8x2 SMT cores, exactly what I my Ryzen part gives me. I just don't care about your other comparisons, they look like smokescreen to me. A decent compiler (gcc, llvm) will use as many cores as you have. You just tell it how many threads you want and away it goes. Compiling is embarrassingly parallel, it approaches best case for SMT. Linking was a serializing bottleneck historically but there is no good reason for it, and is now largely fixed. Your evident confusion coupled with confident pronouncements that are flat wrong is a little concering. Is this somehow normal for the circles you move in?
Again, you evade the point, **diminishing returns**, and substitute a different goal, "faster", and offer an apples and oranges comparison, Intel v AMD.
Merely saying faster with HT than without is not a meaningful counterargument. If you want to have a meaningful counterargument you might compare an Intel 8 core with hyperthreading enabled and disabled (again the same physical CPU), and an Intel 4 core vs an Intel 8 core. Oh, and please do so with a large software project, something that would take 10+ minutes to compile. In such projects improvements are somewhat linear when threads equal physical cores but when there are multiple threads per core (ie Hhyperthreading) the improvements drop off dramatically. Going from 4 cores to 8 might show a 60% improvement but 8 non-HT and 8 HT might only show a 10% improvement.
And again, the point I am trying to make is not what is fastest. What I am trying to convey is that dropping hyperthreading is not necessarily a big deal when you are starting with a CPU that has 8 physical cores due to diminishing returns.
Intel isn't going to drop Hypthreading on all its parts, or AMD will happily kick their tail with its superior SMT implementation.
Doubtful. Increasing cores experiences diminishing returns. The difference between 8 cores and 8 cores + HT may be quite minimal except in very rare instances.
Those rare instances tend to the be ones you care about, like compiling or video encoding. If you don't care about performance then by all means accept a wimpy processor, it's right for you.
Actually compiling would not be one of those rare instances. I/O and RAM are also huge factors. And again, **diminishing returns**, 8 core vs 8 core + HT will probably be less helpful than 2 vs 4 cores or 4 vs 8 cores. 8 cores without hyper threading is not wimpy.
I was talking about GPU, This is what somebody means when they say "Vulkan". Hint: if you don't know the words then google before you post.
Actually you were talking about both CPU and GPU, and your reference to Vulkan was game specific. I am referring to some non-gaming tasks that can also move to the GPU.
Depends on the software, the code, the limitations of a consumer GPU and the CPU math thats supported for the task. A game supporting consumer GPU that needs really great code may not always be the best for a given math task.
True but the parallelization can go way beyond the 8 threads of the CPU, that can make up for a bit a relative inefficiency.
I'm thinking of some consumer tasks that lends itself to parallelization, like image processing.
Intel isn't going to drop Hypthreading on all its parts, or AMD will happily kick their tail with its superior SMT implementation.
Doubtful. Increasing cores experiences diminishing returns. The difference between 8 cores and 8 cores + HT may be quite minimal except in very rare instances.
Wait, so "institutional operators" basically control the space now? What happened to that decentralization thing that was supposed to be the entire purpose of bitcoin?
Decentralization ended with ASIC mining hardware displacing CPUs and GPUs. We are far removed from the point in time where ordinary users with ordinary computers were in control. For years control is centralized in *one* particular authoritarian country that is not known for a hands off approach to things. Something around 60-70% (IIRC) of the hash rate occurs in its border and is dependent upon cheap government supplied power. We've also had mining pools approach the 51% attack hazard. Something that was assumed to be "impossible" as the network grows.
The theoretical foundation of Bitcoin no longer matches reality, the risk of blockchain manipulation by government or cartel is now quite plausible.
Slashdot Mirror
We are pretty good at lifting things above the atmosphere. As for "really big", the farther from the earth the structure is the more shade it generates. Yes technological inventions are necessary, but we went from no powered flight to landing on the moon in 66 years and the pace of technological innovation has greatly improved since then. Its mostly a matter of starting to work on the problem.
4x the number of solar panels in the darkness or the shade doesn't really help. 4x the number of wind turbines in the still air doesn't really help. Storage would help but that's an evolving technology, its scalability unproven. The reality is that Europe has doubled their imports of coal from the US, and also increased natural gas imports from the Russian oligarchs/Putin, to help make up for the decommissioning of nuclear. A decommissioning that was largely driven by **politics** not economics.
And opponents of nuclear overlook a secondary benefit of modern reactors. They help clean up the mess left behind by the older reactors. We don't need to figure out how to safely store all our current nuclear waste for tens of thousands of years, much of it can be consumed as fuel in more modern reactor designs. That also needs to be part of the economic calculation of nuclear.
Or, we could use cheaper power sources, like wind and solar.
That's what the EU thought. They shut down nuclear and now are importing twice as much coal from the US. Wind and solar need backup and without nuclear that will be natural gas and coal.
You seem to assume climate is a symmetric linear system. It is not. It is non-linear and it could be much harder to reverse climate change than initiate it.
Actually history shows that global cooling is quite feasible, volcanic winters, periods of low solar activity resulting in mini-ice ages (1400s, 1600s), etc.
The malthusian failing has repeatedly been your concept of a symmetric steep hill from which there is no return. Through science and engineering we have repeatedly found that "steep hill" is quite flat on the other unseen side.
... but I expect some climate engineering will **also** be necessary. Best to get that on the radar earlier than later.
Malthus and his followers repeatedly fall into the trap of looking at one variable and *assuming* all other are held constant. Science and engineering often avoid malthusian disasters by operating on the other variables that are not really constants. With respect to climate engineering two such variables may be the solar energy reaching the earth and the amount of this energy that is reflected back into space. I suppose some might argue improvements in carbon capture and sequestration technology but I'm just going to stick with shade and reflection for now.
Again, to be clear, I'm all for conservation, increased efficiency, alternative energy (wind, solar, tidal, geothermal, nuclear, biofuels, etc)
Umm... you DO know the law of entropy, yes?
Yes. You do know the problem with CO2? In help retain heat from the sun. You know what help counteracts this? Shade. As far as I know shade does not violate the law of entropy.
Conversion of energy from other forms into heat is not known to be reversible.
The earth is being continuously heated by the sun, the problem with CO2 is the increased capture of this heat. Climate engineering would likely involve well known concepts like more shade so there is less heat to be captured.
While I would like to agree, we kind of bumbled our way into this one. While I dont think we are quite there yet, I'm not so sure we are ready to tackle a runaway scenario.
In 66 years, 1903-1969, we went from the first powered flight to landing on the moon. And the pace of scientific and engineering progress has accelerated since then. Much of that aerospace progress was made in the era of paper, pencil and slide rules. Our smart watches have more computation power than 1969 Apollo mission computers.
Seems a bit Malthusian, and Malthus loses over and over to science and engineering.
Do not misunderstand, I am in favor of conservation, alternative sources, etc. However "irreversible" seems a bit alarmist and BS'ish. Human activity pushed the climate in one direction, it can push it in the other direction as well via science and engineering. Again, it would be best not to have to resort to climate engineering, but climate engineering can make things reversible.
Why bulk up a laptop with a real keyboard when the laptop's primary features are mobility and compactness. That for any extended duration typing a person is more likely to be at the office or at home. The tradeoff that has a more broad appeal seems to be compactness when mobile and the flexibility of external for home or office when the extended typing is more likely.
Its kind of hard to think of not using an external display at the office or home when in "work" mode, so an external keyboard and mouse seems quite natural.
There is no need to lug around an external. One for the office and possibly a second for home. Most users probably do a relatively small amount of *work* related typing when traveling and on the couch.
Also note I was responding to a claim that *current* Apple laptops are not designed for work. These current keyboards are sufficient for travel and couch. I am *not* defending the notion of a touch screen keyboard, I agree that this would be a bad idea. However I disagree regarding the current keyboards. Which I am typing on right now while on my couch. My desk upstairs has a G4 era mechanical USB Apple keyboard. I prefer these over the current Apple externals, I'd probably use a Unicomp Mac keyboard if my 2 G4 era keyboards died.
Quit trying to make the damn laptop so thin and put a good keyboard in it. IMHO Apple's obsession with thin is form over function.
The real alternative is to get an external keyboard (and mouse and display) for office and/or home. You only need to use the built-in keyboard when away from home or office.
And yes, that includes the modern Model-M keyboards from Unicomp.
Apple laptops aren't designed for work anymore
*Laptop*, where mobility and compactness may be more important. When at your desk at the office or home, where people may do more typing, plug in the external keyboard, mouse and display. Working from the laptop's display and keyboard at the office is a joke, its only for those idiotic open floor plan offices that provide nothing more than crappy tables and chairs. Any employer with half a brain will provide external displays, keyboard and mice, as will any half serious home worker.
CS grads that have an inherent interest in software development
That's really what it comes down to at the end of the day, not whether you went to university.
Yes and no. Combine inherent interest and self motivated study with the formal training and the person will likely be even stronger. The university adds to, it doesn't take away from, such a person. Now if the options are a self taught person with the interest and self motivation and a person with a degree that was a "ticket puncher" who showed up and did the minimal required and nothing else, yes, I'd prefer the self taught. The gaps the self taught usually have are easier to deal with. But don't dismiss the formal university program, the self taught person whose personal study will equal a formal program is exceptionally rare.
And frankly, that is how it should be. Class time for concepts and theory that outlive the operating system and programming language of the day, the OS and lang being left as an "exercise for the student". The university is not merely about sitting in classrooms and having knowledge handed to you, you and your fellow students puzzling things out and learning from each other is supposed to be part of the university experience too. And given the amazing access to equipment and expertise one has at a university not indulging in personal projects unrelated to class is quite the lost opportunity.
Regarding professors, the programming expertise might be more contextual. For one of those data structures and algorithms classes taught in pascal my professor was no pascal expert, he knew enough to teach the class but that was about where his interest in the language dropped off. Now when I had him for upper division AI classes. he was quite the expert in LISP which he had been using for decades. It didn't take too long to figure out what professors were the local experts in one language or another, so for office hour questions it was really about knowing who to ask. And like CS students, some professors learned what they needed to and just stuck with that, and others had this innate curiosity and learned new operating systems and languages to satisfy their own curiosity not because they needed to for school or work.
My only complaint of CS majors is that you guys please stick to theory and math. Please donâ(TM)t lecture engineers on how things work in the physical world.
Actually the theory is quite useful and helps in the real world. An example from molecular visualization prior to ubiquitous 3d hardware, i.e. software based rendering days. A "non-theory person" quite familiar with the language and standard library used the built in sort function to get a z-sort of atoms in preparation for rendering. The "theory person" with the theoretical understanding knew that the appropriate sorting algorithm would depend on the current data, which from one rendering to the next would be mostly sorted. Knew that the commonly stated run-times for various sort algorithms assumed random data and were therefore erroneous. A quick check of references showed that for mostly sorted data the standard library algorithm was actually a quite poor choice. The "theory person" implemented a more obscure sorting algorithm with excellent performance given the nature of the data and the atom z sort code dropped off the profiler hot spot list. After many such improvements of the code, at an industry trade show, various visitors to the booth were surprised that commodity PC hardware could offer such visualization performance.
The better programmers understand the practical elements of the hardware and the programming languages *and* they understand the theory. I know engineers who built things sitting on the moon today, they understood the practical and the theory quite well.
The theory taught in CS courses has plenty of application and there are plenty of CS people who can overcome the limits of their education, however a high density of CS degrees in a software development team has often in my experience correlated with problems.
Then you have not learned how to differentiate between the CS grads who chose that degree program because they had an inherent interest in programming and those that chose that program because a parent, guidance councilor, etc told them it was a good career path.
Here's a simple way to tell the two apart. Has the recent grad written *anything* unrelated to class assignments? I don't care what their personal project was, sometimes I have to coax it out of them because they think it too simple or too stupid a project. But they are mistaken, all I am really looking for is that they had some sort of personal curiosity or "need" to sit down and write some code that was not an assignment from a professor, a boss, etc. Something purely for themselves.
Your "overcome the limits of their education" comment is misguided, you don't understand a good CS program. Learning to program is left as an exercise to the student, they are expected to learn, outside of class (maybe there is a TA session to help), the necessary programming language to complete assignments. Some do the absolute minimum, these are the "ticket punchers" who take the class to get the degree to get the job, they aren't really there to learn. Others will be more thorough in learning some programming language, will start to think about problems beyond the class assignment, may try to code up a solution to one of those on their own initiative to satisfy their curiosity as to whether they know enough to pull it off, etc. These "stretch goals" are actually expected and encouraged by the good professors. What you think is some extra work they have to perform to make up some shortcoming is actually work expected by the professors, the "exercises" left to the student on their own time.
Now if you want to rephrase your argument that the less capable students are allowed to somehow skate through the program and graduate that is a valid complaint. But to think that good CS programs do not produce good programmers, that is misinformed.
Kind of like how not everyone needs to hire someone who designs programming languages or builds compilers, right?
Studying programming languages and compilers is important. Such a foundation to build upon is how we CS grads can easily learn and switch to whatever "new" language is the flavor of the moment, while writing decent code that has some understanding of the limitations of the underlying architecture it all runs on.
Not having such a foundation can lead to those degenerate situation where "fans" of a language try to use it everywhere for anything and require 3 GHz quad core CPUs and 16 GB of RAM to accomplish relatively simple things.
In short those CS classes and projects teach a young developer there are many ways to do things, a wide variety of tools are available, some tools are better for some tasks, and they learn a little about what happens at the architecture level where all the levels of abstraction have to meet and execute on the available hardware.
Now can a young developer learn these things outside a formal degree program, sure, but very few have the personal initiative to do so and most need the coercing of the university. And the direction of the university as well since many of the seemingly "unnecessary" classes actually turn out to be useful.
If you think a CS degree is limited to complex problems and inapplicable to modest projects, you are mistaken. CS and other degree programs are a foundation, and with a stronger foundation the personal study one does and the experience one gains will be more effective. Again, its just starting on day one with a bigger toolbox and more tools.
And for the record, I've gone both the self taught and formal university route. The former is not a replacement for the later, the two are not mutually exclusive, and the CS grads that have an inherent interest in software development (as opposed to those who were told its a good career path) likely have practiced the former as well.
Actually compiling would not be one of those rare instances. I/O and RAM are also huge factors.
You have it exactly backwards. The more RAM accesses you have, the more SMT helps.
You misunderstand, its the amount of RAM that can greatly effect compilation speed.
... And I/O has almost nothing to do with SMT because the OS takes care of that... a thread waiting for I/O is not running, or in other words, not in any CPU core, so not affected by SMT.
You misunderstand, its the amount of I/O that can greatly effect compilation speed.
And again, **diminishing returns**, 8 core vs 8 core + HT will probably be less helpful than 2 vs 4 cores or 4 vs 8 cores. 8 cores without hyper threading is not wimpy.
You are talking nonsense. I get my fastest compiles with 8x2 SMT cores, exactly what I my Ryzen part gives me. I just don't care about your other comparisons, they look like smokescreen to me. A decent compiler (gcc, llvm) will use as many cores as you have. You just tell it how many threads you want and away it goes. Compiling is embarrassingly parallel, it approaches best case for SMT. Linking was a serializing bottleneck historically but there is no good reason for it, and is now largely fixed. Your evident confusion coupled with confident pronouncements that are flat wrong is a little concering. Is this somehow normal for the circles you move in?
Again, you evade the point, **diminishing returns**, and substitute a different goal, "faster", and offer an apples and oranges comparison, Intel v AMD.
Merely saying faster with HT than without is not a meaningful counterargument. If you want to have a meaningful counterargument you might compare an Intel 8 core with hyperthreading enabled and disabled (again the same physical CPU), and an Intel 4 core vs an Intel 8 core. Oh, and please do so with a large software project, something that would take 10+ minutes to compile. In such projects improvements are somewhat linear when threads equal physical cores but when there are multiple threads per core (ie Hhyperthreading) the improvements drop off dramatically. Going from 4 cores to 8 might show a 60% improvement but 8 non-HT and 8 HT might only show a 10% improvement.
And again, the point I am trying to make is not what is fastest. What I am trying to convey is that dropping hyperthreading is not necessarily a big deal when you are starting with a CPU that has 8 physical cores due to diminishing returns.
Intel isn't going to drop Hypthreading on all its parts, or AMD will happily kick their tail with its superior SMT implementation.
Doubtful. Increasing cores experiences diminishing returns. The difference between 8 cores and 8 cores + HT may be quite minimal except in very rare instances.
Those rare instances tend to the be ones you care about, like compiling or video encoding. If you don't care about performance then by all means accept a wimpy processor, it's right for you.
Actually compiling would not be one of those rare instances. I/O and RAM are also huge factors. And again, **diminishing returns**, 8 core vs 8 core + HT will probably be less helpful than 2 vs 4 cores or 4 vs 8 cores. 8 cores without hyper threading is not wimpy.
I was talking about GPU, This is what somebody means when they say "Vulkan". Hint: if you don't know the words then google before you post.
Actually you were talking about both CPU and GPU, and your reference to Vulkan was game specific. I am referring to some non-gaming tasks that can also move to the GPU.
Depends on the software, the code, the limitations of a consumer GPU and the CPU math thats supported for the task. A game supporting consumer GPU that needs really great code may not always be the best for a given math task.
True but the parallelization can go way beyond the 8 threads of the CPU, that can make up for a bit a relative inefficiency.
I'm thinking of some consumer tasks that lends itself to parallelization, like image processing.
With GPUs relatively ubiquitous some (many ?) of these workloads may just shift to the GPU.
Intel isn't going to drop Hypthreading on all its parts, or AMD will happily kick their tail with its superior SMT implementation.
Doubtful. Increasing cores experiences diminishing returns. The difference between 8 cores and 8 cores + HT may be quite minimal except in very rare instances.
Wait, so "institutional operators" basically control the space now? What happened to that decentralization thing that was supposed to be the entire purpose of bitcoin?
Decentralization ended with ASIC mining hardware displacing CPUs and GPUs. We are far removed from the point in time where ordinary users with ordinary computers were in control. For years control is centralized in *one* particular authoritarian country that is not known for a hands off approach to things. Something around 60-70% (IIRC) of the hash rate occurs in its border and is dependent upon cheap government supplied power. We've also had mining pools approach the 51% attack hazard. Something that was assumed to be "impossible" as the network grows.
The theoretical foundation of Bitcoin no longer matches reality, the risk of blockchain manipulation by government or cartel is now quite plausible.