French has a reputation for linguistic preservation efforts, but it doesn't really seem to take. Television is télévision. Telephone is téléphone. Electricity is électricité. Etc. You know what these words are in Icelandic? Sjónvarp, sími, and rafmagn . Go to Wikipedia and look up random modern technical words from different fields (ideally ones not named after a person, since that's cheating) and browse over the language bar on the left to see what they're called in French vs. Icelandic (or any other languages). For example, photon, integral, mitochondria, polymer, autism, transistor, seismograph, hippocampus, supernova, and tyrannosaurus, to pick some. According to Wikipedia, in French they're photon, intégral, mitochondrie, polymère, autisme, transistor, sismographe, hippocampe, supernova, and tyrannosaurus. In Icelandic they're ljóseind, heildun, hvatberi, fjölliða, einhverfa, smári, jarðskjálftamælir, dreki, sprengistjarna and grameðla, respectively.
Why does French have this reputation for protecting their language so much? It sure doesn't look that way. Maybe the difference is with common words? For example, Icelandic has a problem with people using English as slang in everyday speech. For example, "hæ" and "bæ" as casual greetings ("hi", "bye") are so common that they're pretty much embedded into the language. Does French do this sort of thing too? Maybe they're better about that. But at least in terms of new words coming into the language, I just don't see where they get this reputation from.
(It should be noted that not only does Icelandic come up with native-based words for technical terms, but we actually use them. We actually say "tölva", not computer, "sjónvarp", not TV, "rafmagn", not electricity, etc. If there's a technical term that a person doesn't know the proper Icelandic for then they use the English, but in maybe 90% of cases, once the proper Icelandic for a word becomes widely known, it actually gets used) (there are of course those 10% exceptions where nobody liked the proper term so most people don't use it, of course...;) Pizza / flatbaka being a good example)
Finnst (th)ér íslenskan skrýtið tungumál? Langlanglanglang..->..langafi (th)inn hefði skilið íslensku betur en sænsku;)
I find the easiest to read by far is Faroese. It's almost creepy to me how well I can usually read it when I can hardly understand anything they say. I understand that's deliberate, though, that they chose their writing system to try to match up with Icelandic spellings even though the pronunciation is very different. I think the difference is analogous to Danish / Norwegian, perhaps.
That's true. A lot of native English speakers think of English as a "hard" language. True, there's a lot of irregularity, but the alphabet is small and there are very few declension forms. And lots of languages have tons of irregularity, English is hardly unique in that regard. I used an Icelandic-language database I wrote the other day to pull out how many noun declension patterns there are - depending on how you define a "pattern", it's in the range of dozens to hundreds.
As for Japan, they've gotten a lot more people to learn Japanese simply out of cultural export than via economic might. Which is usually how these things go. China has seen proportionally little success on this front.
I live in Europe and I know of almost nobody over here who's learning Chinese. Most people here would rather reduce our required-languages-to-learn-in-school (currently everyone has to learn Danish (as well as English), which isn't exactly the most useful language in the scheme of things).
The reason everyone everywhere learns English isn't just because, say, they're thinking "hmm, this language would be useful to me in international trade" or the like. It's because it's bloody everywhere (media, the grocery store, etc), you're constantly exposed to it from a young age, and in many if not most cases, technology literally forces you to use it. I know quite literally only *one* young person who grew up here who isn't fluent in English - and he only managed that by the fact that he never uses the internet and has little interest in TV or movies. And even still he could probably manage to communicate in English to a fair degree if forced to.
It doesn't bother me that English has become the international language (and probably will remain so for a long, long time), but it does bother me how it tends to contaminate other languages. Example: ask a young Icelander how to say "basically" in Icelandic. At least half will have to stop and think about it, and maybe a quarter won't be able to give you an answer on the spot. I find that really, really sad. Ég MEINA, ég FÍLA (th)etta ekki, (th)að MEIKAR EKKI SENS...
while trying to make a DC-DC converter run at half a million volts would need some very exotic semiconductor components.
Some HVDC systems run at near a megavolt. Example.
HVDC systems overall decrease losses and costs on long runs, the converter stations themselves actually lose very little and long-distance line losses can be dramatically reduced. But the stations are still very expensive (and not very standardized, as the tech is still very muchso a moving target), so it's currently pretty much only realistic for long runs and submarine cables.
For a given voltage and given mass of wire per unit distance, however, DC has lower losses (dramatically lower in some environments, such as undersea cables). It also is a lot more stable, you don't have to worry about frequency maintenance, off-sync grid interconnects, and a bunch of other stuff.
High voltage DC is still expensive to do but it's been getting a *lot* cheaper, and will probably continue to do so. For the time being, though, it's going to be confined to long high-power runs and undersea cables, situations that maximize its benefits and minimize the number of step-up / step-down stations required.
I think perhaps they meant "120V AC" or something similar. 230V AC, while having a few disadvantages, is in most regards much better for home distribution. More power with less copper and less losses, easier and more efficient to transform, etc. Shocks hurt more, though.
Either that, or perhaps they're thinking more long term with the fact that high voltage DC transformers are becoming cheaper. There may be something to the concept that in the long run we'll increasingly see at least part of distribution done as DC, it avoids some types of losses and gives you more throughput for a given amount of line over a given distance, plus avoids sync issues between disjoint grids.
Thank you! (check my sig). It's bugged me for no small amount of time.
Unicode support is one of those things that to most Americans is an "Oh, I guess that matters to some people, doesn't it?" afterthought, but to people who use alternative character sets it's one big mess of poor support after the next.
You all realize that in many cases by not properly supporting unicode you *force* people to use English, right? In this context I'm not talking about Slashdot persay (this is an English-language website and that's fine), but all sorts of other things. For example, in programming, most languages simply don't allow me to use Icelandic characters in variable and function names. So I'm left with two choices: mangle them (like we have to do with URLs and a ton of other things), or simply use English. If I choose to mangle them to remove Icelandic characters, not only is it ugly and less readable (imagine if you had to mangle about a third of the letters in the English alphabet to write), but it almost guarantees messups because you write your *strings* unmangled (you certainly don't want to be outputting mangled text to the user), so you're always switching back and forth between needing to write mangled and unmangled. Even as for the strings themselves, in most languages unicode support ranges from "mildly acceptable" to "bloody awful". Because it's just an afterthought to developers whose native language is English that hardly crosses their mind in the design and implementation phases. They know that they "should" support it, but most really don't care.
Now, I've seen some people take the concept too far, like trying to localize "for" and "if" and "else" and the like. That's stupid and pointless and asking for problems. But for crying out loud, make my strings work right and let me chose my own variable / function names.:P
Hmm, I was thinking of your launch_thread in terms of passing by reference, but I now imagine you meant copy (would have helped if you had actually, you know, defined the function). But then you're just adding an extra and unnecessary copy.
Let me help you out. Your function is going to have to keep a global data structure of all of the threads' arguments because they're too big to pass as the pthread's argument. Now, your array isn't going to be fixed-size because you don't know how many instances are going to be called (you could limit it and put a hard cap, but you still have to put checks for that). If it's pure C, then you don't have STL containers, so you have to implement all of your memory management overhead. Regardless, you at the very least have to do an additional copy of your passed my_struct into your global arguments structure (2x), versus the one that std::thread needs. Now, there is a way to work around having to keep a global data structure, but it sucks: it's to have your launch_thread function pass a pointer to the local copy of my_struct and then sit around and wait for the thread to start up, copy off of the pointer, and then zero out your copy to alert launch_thread that it's started and has copied the data structure (of course, this involves yet another copy, plus a ton of reads while sitting around and waiting and wasting time). All of this, of course, is on top of all of the overhead imposed by pthread itself, including defining a function (and not in the same place where the code is being used, which reduces clarity), and roughly three lines for the pthread calls themselves.
This is all assuming that you implement it pthread-only and not portable. Otherwise, you have to add in #ifdefs and do a whole different approach for whole different platforms.
Could you do all this? Of course you could. Would you do it? Clearly you didn't, and I know no amount of badgering would have gotten you to do it (I've tried this experiment before, you're not the first). Could you write it once and then reuse it?** Sure you could. Have you? No, of course you haven't, otherwise you would have just pasted it before. Why haven't you written such a thing before? Because it's too much hassle. Which is the very reason threading is underused.
** - kind of. You see, it's actually worse than that because unless you make an even more convoluted and unreadable and type-unsafe function, your thread launcher is going to be only set up for launching this particular case. But one can encounter all kinds of threading needs that would require significant changes. But I digress.
1) You didn define launch_thread. 2) my_struct_array was said, and I quote, "a local-context data structure", so congrats, your data is going to go out of scope on you. 3) The concept of having to write that is absurd because "for (auto&i : container)" is a "do whatever you want, any number of steps, no matching function signature required, inline, on any container whatsoever" built into C++11, *and* it's something that anyone who knows C++11 will know rather being something you brewed yourself.
Again, to repeat, given your failures on #1 and #2:
" if you're too lazy to do it here, or change the requirements to present yourself with a simpler problem, then I'm going to take it that you're too lazy to do it in your code, too."
Hence, I'm going to take it that you're likewise too lazy to actually thread your code. And the fact that your code contains a fundamental oversight resulting in a memory leak which wouldn't have caused a compile error is just icing on the cake.
If your loop contains 10 instructions and loops 5 times
Duh. And that's obviously not what is being discussed here. Step up a level or 20 in the call stack.
If that "largely" means you need a lock,
"largely" meaning "does a bunch of stuff on its own and only briefly needs to lock common data structures to update based on the results of what it's been doing". That is by far the most common case in the real world. If you have a texture loading thread for a game it only needs to briefly lock the texture structure when it's gotten its latest texture loaded and processed. If you have a mesh tweaking function for a 3d editor it only needs to lock the list of meshes briefly to swap out its newly tweaked version for the old version. And on and on and on. The most common case doesn't involve locking to wait for calculations to be done from the other side, it just needs to lock briefly to make sure it doesn't read an incomplete state when the results of calculations are being written out.
Limited data dependencies are common, it's true, but fundamental lockings between tasks are not that common in the real world. Most real world tasks aren't like matrix multiplication or whatnot. Let's say the task is a video game and your tasks are things like:
1. Get user input 2. Translate/rotate moving objects 3. Backcompute armature positions 4. Calculate mesh data from armatures 5. Load/unload new scene data 6. Load/unload textures 7. Scale objects by level of detail 8. Process AI 9. Play sound effects 10. Play music 11. Autosave 12. Read from the network. 13. Write to the network 14. Handle special effect animations 15. Render
And on and on and on, your average game has a whole laundry list of these sort of things, and each one is made of many subtasks. Some will be trivial, while others warrant threading even at the subtask level.
Now, when you look at these, of course they're all obviously interconnected in some ways, you obviously have to use mutexes. But the connections are limited. For example, If you're backcomputing how an armature must be configured, it's obviously going to use the same data structure as the thread that deforms mesh data with armatures. But the only real practical limitation is that the thread that changes armature positions has to lock the one armature it's computing briefly while writing the results of its calculations so that the other thread never reads half-written results - that's it. Likewise, rendering (which has tons and tons of subtasks, and is famously parallel) obviously depends on all sorts of texture and model data from different threads. But again, all it needs is that there not be anything half-written, it doesn't have to wait on any particular result. Objects moving will change their needed level of detail, user actions and collisions may cause sound effects, and on and on, but again, the only requirement is that you not have half-written states.
This is what the vast majority of CPU-intensive tasks in the real world are like. Yes, you have to use mutexes, and you have to be aware of iterator / pointer invalidation on insert / delete into data structures (where applicable), but apart from those sorts of things, they tend to thread very, very well.
Since it's so simple, prove it. Write this in C: Given a data structure - oh, let's say:
struct my_struct { int i; double d; };
And a local-context data structure (of your choice) called my_struct_array which contains an arbitrary number of my_struct entries, iterate over all entries and launch a detached threaded function (we'll call it my_function) on each of them in their own thread.
Here it is in C++11:
for (auto& i : my_struct_array)
std::thread([i](){ my_function(i); }).detach();
It's hardly any longer than the non-threaded version:
for (auto& i : my_struct_array)
my_function(i);
Now, your turn. Show me your "1 function call" C version. Note that this isn't some sort of contrived problem, this sort of thing is one of the most common use cases you'll encounter, so it should be trivial, right? And I'll note, if you're too lazy to do it here, or change the requirements to present yourself with a simpler problem, then I'm going to take it that you're too lazy to do it in your code, too.
Which is precisely the point. Programmers don't thread their cpu-intesive apps sufficiently because (1) a lot of tasks don't parallelize well and (2) programmers have consistently proven to suck at coming up with ways to adequately parallelize programs.
That's simply nonsense. Probably the most common algorithm in the book, what wastes probably 80% of compute cycles in some form or another, simplifies down to:
for (auto& i : container)
auto.do_something_independently_to_or_with_this_object():.... which can be parallelized tremendously, up to container.size(). Probably the next most common cycle waster is along the lines of:
while (true) {
do_regularly_occurring_largely_independent_task_1();
do_regularly_occurring_largely_independent_task_2();//...
do_regularly_occurring_largely_independent_task_N(); }
Which again, can be parallelized trivially.
Of course there exist algorithms that can't be easily parallelized. That's not the point. They're not the most common cases. And I'd be glad to demonstrate this to you by, say, pulling up random pieces of source from the Linux kernel or whatnot and showing with real-world examples.
What don't people parallelize this sort of stuff? Because they're too lazy and most programming languages (but C in particular) make it too much of a hassle. Hence they only parallelize when forced to, which means that the general case of your software runs fine, but the edge cases run terrible. It has nothing to do with whether the app *can* be parallelized. The overhwhelmingly vast percentage of code that could be sped up by parallelizing, 99.99% of the time isn't parallelized.
And it's not just about performance, it's about general user experiences. Threaded code is simply more pleasant to use. If I'm using, say, blender and I turn on decimate for a mesh, I have to sit there and wait for the mesh to finish decimating before I can do anything else. Anything at all. I can't go off and start developing a texture or tweak an unrelated object, I have to sit there and wait for that *one* task to finish. And sometimes these time wasters come accidentally or unexpectedly.
Threads are Good Things(tm), and they're way underused. And seriously, you want to talk about wasted silicon, you have to look no further than all of the huge amount of silicon that gets wasted trying to gain small incremental improvements in serial processing speed.
Exactly. Put simply, you get far more raw computing bang for your silicon buck with smaller, simpler cores.
What's so wrong with having our cake and eating it too? Why can't we have future system architectures like:
1x main core, made as fast as we realistically can 8x secondary cores, each 75% as fast as the main core but using a lot less silicon each 64x teriary cores, each 50% as fast as the main core, but again even simpler in terms of silicon consumption
Or some such? Your threader can try to keep the most intensive tasks on the main core. In the long run we could even have adaptive threading: all threaded function calls are interpreted by a bayesian thread launcher that does random sampling of how performance of different threads varies when their components are launched in different threading environments (including "completely unthreaded and inline") and changes the odds of launching in different environments accordingly. So the programmer could use threads and futures to their heart's content and all work gets distributed out where it best belongs.
Another thing to simplify the task for programmers would be changes to standards to even further simplify the launching of threads in common situations. For example, a common programming recipe involves doing an operation on every member of an object. Quite often these can be done in parallel. Now, in C++ one could do a "std::for_each" or a "for (auto& i : container)" and have the have an iterative std::thread call inside of it. Of course, if you have a million entries, you probably don't want a million threads, so it gets more complicated, you want to break the iteration down into several sub-iterations, each with one thread iterating over a fraction of the total entries. But instead of making the programmer have to think about all that, why not have a "std::for_each_threaded" or "for (auto& i ~: container)" or somesuch that automatically threads your repetitive command as efficiently as possible?
No, as long as I/O bandwidth is not the limiting factor. The sort of thing you're compiling can have radically different CPU vs. I/O requirements. Some simple but verbose C code with little optimization might be almost entirely IO limited while some heavy templated C++ and full optimization might be almost entirely CPU limited.
The thing is, there's no way to know what is going to cause a particular person to think "I wish my computer was performing faster". It all depends on the individual and what they use. But one can name various cases that might likely cause a certain subset of users headaches, and so those become use cases for improving system performance. One such use case is clearly compilation that's not IO-limited.
No, it's a good example of disproving Linus's point. Even if one can't conceive of an algorithm that can paginate in a non-linear fashion, they can certainly well bloody paginate each of the 100 books at the same time, each on their own core.
And seriously, renumbering pages is supposed to be some sort of complicated task, according to you? *boggle*
The key question is, what are as many common example cases one can list (in order of frequency times severity) where users' computers have lagged by a perceptible amount which in any way reduced their user experience, or caused the user to have to forgo features that would otherwise have been desirable? Then you need to look at the cause.
In the overwhelming majority of cases, you'll find that "more parallelism with more cores" would be a solution. So why not just bloody do it?
Not everybody suffers performance problems in the same way. But the vast majority of peoples' performance problems can be solved by the same solution.
It's not a straw man at all - I know how to read. He literally says "magical parallel algorithms" are needed to make use of hundreds of cores. And he says "The only place where parallelism matters is in graphics or on the server side, where we already largely have it", which is nothing more than pointing out that apps that need high performance (aka, graphics and servers) *do* in fact use parallelism. What you claim is "Linus's argument" isn't even brought up until the last paragraph. And the only reason that the CPU would "still going be a few core and not many core" is if programmers don't threading their cpu-intensive apps sufficiently. Which, one should note, are mainly graphics and server stuff, the things that Linus notes *are* being threaded.
I'm wondering about what he is thinking for real-world details. For example, a common use case is one thread does searches through a data structure to find an element (as, say, a pointer or an iterator), but before it can dereference it and try to access the memory, some other thread comes along and removes it from the list and frees it. Then your program tries to dereference a pointer or iterator that's no longer valid and it crashes.
The problem isn't that it's no longer in the list. Clearly the other thread had a good reason to remove it and if your first thread had happened just a split second later it never would have seen the removed entry. The problem is that your program crashes because it's trying to use a freed memory address.
What sort of implementation details is he thinking of that prevent this sort of problem? I mean, if he actually has a realistic solution, I'd love to see it, it could make for a brilliant extension of STL containers.
There are cases where getting exactly the right answer doesn't matter - real-time graphics is a good example. It's amazing the level of error you can have on an object if it's flying quickly past your field of view and lots of things are moving around. In "The Empire Strikes Back" they used a bloody potato and a shoe as asteroids and even Lucas didn't notice.
That said, it's not the general case in computing that one can tolerate random errors. Nor is the concept of tolerating errors anything new. Programmers have been using for example approximations for square roots for a long, long time to save compute cycles where precision takes a back seat to "just get the shape of the curve roughly right". There's even a number of lower-precision hardware math methods.
Indeed. There's tons of CPU-intensive tasks that need to be done in a modern computer game, but they're typically done as:
while (true) {
do_task_1();
do_task_2();
(... )
do_task_N(); }
Rather than...
std::thread([&](){ while (true) do_task_1(); }).detach(); std::thread([&](){ while (true) do_task_2(); }).detach(); (... ) std::thread([&](){ while (true) do_task_N(); }).detach(); }
... or similar. Because in C and older versions of C++ launching a thread takes significant typing and ugly code, up to and including - in the case of the same function threaded a variable number of times in a loop with more than a trivial argument - having to have a memory-managed threadsafe container to hold your arguments (and in C you don't have STL containers, you have to do all that work yourself too). It's not the end of the world to have to code threads in C or earlier C++, but it's enough work that programmers usually don't do it any more than they're pretty much forced to. "Okay, my game will literally run at half the speed if I don't thread this function" - fine, they'll thread it. But "this function call eats up 3% of my performance, this one 6%, this one 4%, this one 2,5%, this one 3,5%...."? Usually such functions just get stuck into one big main loop.
I really hope with how easy it's gotten in C++11 that more people will make better use of threads. In the first example code, not only do you relegate all of your tasks to the same core, thus hitting performance, but if any one task hangs, all of them hang. It's a terrible approach, but it's the most common. The only case where threads aren't good is where you're doing heavy concurrent read/writes to the same cached data, but in real world apps there's almost always a level where you can launch the thread where this isn't the case, if it's even an issue to begin with in your particular application. The presumption that concurrent access to cached memory will usually or always be a problem (which seems to be Linux's presumption) requires that A) your threads not doing the majority of their work on thread-local memory, AND B) that the shared data area being read from / written to concurrently is small enough to be cached, AND C) you can't just migrate your threads up in scope N levels to work around any such issue.
Linus's argument basically boils down to, "Parallel algorithms are sorcery, and the only place they matter are places applications that demand performance which are indeed increasingly using parallelism".
Of course you don't need, say, a 50-threaded version of vi or alsamixer or whatever. But for apps that need performance, increasingly they have to get them from threading. And there's nothing "magical" about parallelism. Perhaps in Linus's dislike for C++ he's missed how trivially easy it's gotten to launch threads in C++11, but it takes less work now than a for-loop, since std::thread is so simple and you can inline the command with a lambda. And you have a nice clean mutex library including scoped mutexes like std::lock_guard so you don't even have to remember to unlock them.
It's quite true that having multiple cores needing to read to and write from the same chunk of memory isn't a good thing. But I'd bet you that only in under 5% or so of high performance apps is that the *only* level you can thread at. Because if you have say five nested levels of looping, 4 of them can be memory constrained, but so long as least just one can be threaded without heavy reads/writes on shared cache, you can thread to your heart's content with minimal adverse impact. And "heavy" is the key word. So long as you're not doing essentially *constant* heavy reads/writes on shared cache, the overhead cost is minimal.
This is at least the second time a U.S. warrant has been served at Google for data from someone connected to WikiLeaks. A sealed warrant was served to Google in 2011 for the email of a WikiLeaks volunteer in Iceland.
Right, it's not like they had any probable cause of illegal activity back in 2011, no sirree.... You've got a Wikileaks volunteer who was at the time acting as an unofficial spokeman for the organization in the news, voluntarily coming up to them and telling them that Assange is working with Anonymous and LulzSec and ordering hacks and spying, including against US targets, and providing troves of data - are they supposed to just ignore that?
Slashdot Mirror
French has a reputation for linguistic preservation efforts, but it doesn't really seem to take. Television is télévision. Telephone is téléphone. Electricity is électricité. Etc. You know what these words are in Icelandic? Sjónvarp, sími, and rafmagn . Go to Wikipedia and look up random modern technical words from different fields (ideally ones not named after a person, since that's cheating) and browse over the language bar on the left to see what they're called in French vs. Icelandic (or any other languages). For example, photon, integral, mitochondria, polymer, autism, transistor, seismograph, hippocampus, supernova, and tyrannosaurus, to pick some. According to Wikipedia, in French they're photon, intégral, mitochondrie, polymère, autisme, transistor, sismographe, hippocampe, supernova, and tyrannosaurus. In Icelandic they're ljóseind, heildun, hvatberi, fjölliða, einhverfa, smári, jarðskjálftamælir, dreki, sprengistjarna and grameðla, respectively.
Why does French have this reputation for protecting their language so much? It sure doesn't look that way. Maybe the difference is with common words? For example, Icelandic has a problem with people using English as slang in everyday speech. For example, "hæ" and "bæ" as casual greetings ("hi", "bye") are so common that they're pretty much embedded into the language. Does French do this sort of thing too? Maybe they're better about that. But at least in terms of new words coming into the language, I just don't see where they get this reputation from.
(It should be noted that not only does Icelandic come up with native-based words for technical terms, but we actually use them. We actually say "tölva", not computer, "sjónvarp", not TV, "rafmagn", not electricity, etc. If there's a technical term that a person doesn't know the proper Icelandic for then they use the English, but in maybe 90% of cases, once the proper Icelandic for a word becomes widely known, it actually gets used) (there are of course those 10% exceptions where nobody liked the proper term so most people don't use it, of course... ;) Pizza / flatbaka being a good example)
Define "from" :) Iceland is my home, but I was born elsewhere.
Finnst (th)ér íslenskan skrýtið tungumál? Langlanglanglang..->..langafi (th)inn hefði skilið íslensku betur en sænsku ;)
I find the easiest to read by far is Faroese. It's almost creepy to me how well I can usually read it when I can hardly understand anything they say. I understand that's deliberate, though, that they chose their writing system to try to match up with Icelandic spellings even though the pronunciation is very different. I think the difference is analogous to Danish / Norwegian, perhaps.
That's true. A lot of native English speakers think of English as a "hard" language. True, there's a lot of irregularity, but the alphabet is small and there are very few declension forms. And lots of languages have tons of irregularity, English is hardly unique in that regard. I used an Icelandic-language database I wrote the other day to pull out how many noun declension patterns there are - depending on how you define a "pattern", it's in the range of dozens to hundreds.
As for Japan, they've gotten a lot more people to learn Japanese simply out of cultural export than via economic might. Which is usually how these things go. China has seen proportionally little success on this front.
I live in Europe and I know of almost nobody over here who's learning Chinese. Most people here would rather reduce our required-languages-to-learn-in-school (currently everyone has to learn Danish (as well as English), which isn't exactly the most useful language in the scheme of things).
The reason everyone everywhere learns English isn't just because, say, they're thinking "hmm, this language would be useful to me in international trade" or the like. It's because it's bloody everywhere (media, the grocery store, etc), you're constantly exposed to it from a young age, and in many if not most cases, technology literally forces you to use it. I know quite literally only *one* young person who grew up here who isn't fluent in English - and he only managed that by the fact that he never uses the internet and has little interest in TV or movies. And even still he could probably manage to communicate in English to a fair degree if forced to.
It doesn't bother me that English has become the international language (and probably will remain so for a long, long time), but it does bother me how it tends to contaminate other languages. Example: ask a young Icelander how to say "basically" in Icelandic. At least half will have to stop and think about it, and maybe a quarter won't be able to give you an answer on the spot. I find that really, really sad. Ég MEINA, ég FÍLA (th)etta ekki, (th)að MEIKAR EKKI SENS ...
Some HVDC systems run at near a megavolt. Example.
HVDC systems overall decrease losses and costs on long runs, the converter stations themselves actually lose very little and long-distance line losses can be dramatically reduced. But the stations are still very expensive (and not very standardized, as the tech is still very muchso a moving target), so it's currently pretty much only realistic for long runs and submarine cables.
For a given voltage and given mass of wire per unit distance, however, DC has lower losses (dramatically lower in some environments, such as undersea cables). It also is a lot more stable, you don't have to worry about frequency maintenance, off-sync grid interconnects, and a bunch of other stuff.
High voltage DC is still expensive to do but it's been getting a *lot* cheaper, and will probably continue to do so. For the time being, though, it's going to be confined to long high-power runs and undersea cables, situations that maximize its benefits and minimize the number of step-up / step-down stations required.
I think perhaps they meant "120V AC" or something similar. 230V AC, while having a few disadvantages, is in most regards much better for home distribution. More power with less copper and less losses, easier and more efficient to transform, etc. Shocks hurt more, though.
Either that, or perhaps they're thinking more long term with the fact that high voltage DC transformers are becoming cheaper. There may be something to the concept that in the long run we'll increasingly see at least part of distribution done as DC, it avoids some types of losses and gives you more throughput for a given amount of line over a given distance, plus avoids sync issues between disjoint grids.
Thank you! (check my sig). It's bugged me for no small amount of time.
Unicode support is one of those things that to most Americans is an "Oh, I guess that matters to some people, doesn't it?" afterthought, but to people who use alternative character sets it's one big mess of poor support after the next.
You all realize that in many cases by not properly supporting unicode you *force* people to use English, right? In this context I'm not talking about Slashdot persay (this is an English-language website and that's fine), but all sorts of other things. For example, in programming, most languages simply don't allow me to use Icelandic characters in variable and function names. So I'm left with two choices: mangle them (like we have to do with URLs and a ton of other things), or simply use English. If I choose to mangle them to remove Icelandic characters, not only is it ugly and less readable (imagine if you had to mangle about a third of the letters in the English alphabet to write), but it almost guarantees messups because you write your *strings* unmangled (you certainly don't want to be outputting mangled text to the user), so you're always switching back and forth between needing to write mangled and unmangled. Even as for the strings themselves, in most languages unicode support ranges from "mildly acceptable" to "bloody awful". Because it's just an afterthought to developers whose native language is English that hardly crosses their mind in the design and implementation phases. They know that they "should" support it, but most really don't care.
Now, I've seen some people take the concept too far, like trying to localize "for" and "if" and "else" and the like. That's stupid and pointless and asking for problems. But for crying out loud, make my strings work right and let me chose my own variable / function names. :P
Hmm, I was thinking of your launch_thread in terms of passing by reference, but I now imagine you meant copy (would have helped if you had actually, you know, defined the function). But then you're just adding an extra and unnecessary copy.
Let me help you out. Your function is going to have to keep a global data structure of all of the threads' arguments because they're too big to pass as the pthread's argument. Now, your array isn't going to be fixed-size because you don't know how many instances are going to be called (you could limit it and put a hard cap, but you still have to put checks for that). If it's pure C, then you don't have STL containers, so you have to implement all of your memory management overhead. Regardless, you at the very least have to do an additional copy of your passed my_struct into your global arguments structure (2x), versus the one that std::thread needs. Now, there is a way to work around having to keep a global data structure, but it sucks: it's to have your launch_thread function pass a pointer to the local copy of my_struct and then sit around and wait for the thread to start up, copy off of the pointer, and then zero out your copy to alert launch_thread that it's started and has copied the data structure (of course, this involves yet another copy, plus a ton of reads while sitting around and waiting and wasting time). All of this, of course, is on top of all of the overhead imposed by pthread itself, including defining a function (and not in the same place where the code is being used, which reduces clarity), and roughly three lines for the pthread calls themselves.
This is all assuming that you implement it pthread-only and not portable. Otherwise, you have to add in #ifdefs and do a whole different approach for whole different platforms.
Could you do all this? Of course you could. Would you do it? Clearly you didn't, and I know no amount of badgering would have gotten you to do it (I've tried this experiment before, you're not the first). Could you write it once and then reuse it?** Sure you could. Have you? No, of course you haven't, otherwise you would have just pasted it before. Why haven't you written such a thing before? Because it's too much hassle. Which is the very reason threading is underused.
** - kind of. You see, it's actually worse than that because unless you make an even more convoluted and unreadable and type-unsafe function, your thread launcher is going to be only set up for launching this particular case. But one can encounter all kinds of threading needs that would require significant changes. But I digress.
BZZT, fail.
1) You didn define launch_thread.
2) my_struct_array was said, and I quote, "a local-context data structure", so congrats, your data is going to go out of scope on you.
3) The concept of having to write that is absurd because "for (auto&i : container)" is a "do whatever you want, any number of steps, no matching function signature required, inline, on any container whatsoever" built into C++11, *and* it's something that anyone who knows C++11 will know rather being something you brewed yourself.
Again, to repeat, given your failures on #1 and #2:
" if you're too lazy to do it here, or change the requirements to present yourself with a simpler problem, then I'm going to take it that you're too lazy to do it in your code, too."
Hence, I'm going to take it that you're likewise too lazy to actually thread your code. And the fact that your code contains a fundamental oversight resulting in a memory leak which wouldn't have caused a compile error is just icing on the cake.
Duh. And that's obviously not what is being discussed here. Step up a level or 20 in the call stack.
"largely" meaning "does a bunch of stuff on its own and only briefly needs to lock common data structures to update based on the results of what it's been doing". That is by far the most common case in the real world. If you have a texture loading thread for a game it only needs to briefly lock the texture structure when it's gotten its latest texture loaded and processed. If you have a mesh tweaking function for a 3d editor it only needs to lock the list of meshes briefly to swap out its newly tweaked version for the old version. And on and on and on. The most common case doesn't involve locking to wait for calculations to be done from the other side, it just needs to lock briefly to make sure it doesn't read an incomplete state when the results of calculations are being written out.
Limited data dependencies are common, it's true, but fundamental lockings between tasks are not that common in the real world. Most real world tasks aren't like matrix multiplication or whatnot. Let's say the task is a video game and your tasks are things like:
1. Get user input
2. Translate/rotate moving objects
3. Backcompute armature positions
4. Calculate mesh data from armatures
5. Load/unload new scene data
6. Load/unload textures
7. Scale objects by level of detail
8. Process AI
9. Play sound effects
10. Play music
11. Autosave
12. Read from the network.
13. Write to the network
14. Handle special effect animations
15. Render
And on and on and on, your average game has a whole laundry list of these sort of things, and each one is made of many subtasks. Some will be trivial, while others warrant threading even at the subtask level.
Now, when you look at these, of course they're all obviously interconnected in some ways, you obviously have to use mutexes. But the connections are limited. For example, If you're backcomputing how an armature must be configured, it's obviously going to use the same data structure as the thread that deforms mesh data with armatures. But the only real practical limitation is that the thread that changes armature positions has to lock the one armature it's computing briefly while writing the results of its calculations so that the other thread never reads half-written results - that's it. Likewise, rendering (which has tons and tons of subtasks, and is famously parallel) obviously depends on all sorts of texture and model data from different threads. But again, all it needs is that there not be anything half-written, it doesn't have to wait on any particular result. Objects moving will change their needed level of detail, user actions and collisions may cause sound effects, and on and on, but again, the only requirement is that you not have half-written states.
This is what the vast majority of CPU-intensive tasks in the real world are like. Yes, you have to use mutexes, and you have to be aware of iterator / pointer invalidation on insert / delete into data structures (where applicable), but apart from those sorts of things, they tend to thread very, very well.
Since it's so simple, prove it. Write this in C: Given a data structure - oh, let's say:
struct my_struct {
int i;
double d;
};
And a local-context data structure (of your choice) called my_struct_array which contains an arbitrary number of my_struct entries, iterate over all entries and launch a detached threaded function (we'll call it my_function) on each of them in their own thread.
Here it is in C++11:
for (auto& i : my_struct_array)
std::thread([i](){ my_function(i); }).detach();
It's hardly any longer than the non-threaded version:
for (auto& i : my_struct_array)
my_function(i);
Now, your turn. Show me your "1 function call" C version. Note that this isn't some sort of contrived problem, this sort of thing is one of the most common use cases you'll encounter, so it should be trivial, right? And I'll note, if you're too lazy to do it here, or change the requirements to present yourself with a simpler problem, then I'm going to take it that you're too lazy to do it in your code, too.
You're on.
That's simply nonsense. Probably the most common algorithm in the book, what wastes probably 80% of compute cycles in some form or another, simplifies down to:
for (auto& i : container) .... which can be parallelized tremendously, up to container.size(). Probably the next most common cycle waster is along the lines of:
auto.do_something_independently_to_or_with_this_object():
while (true) // ...
{
do_regularly_occurring_largely_independent_task_1();
do_regularly_occurring_largely_independent_task_2();
do_regularly_occurring_largely_independent_task_N();
}
Which again, can be parallelized trivially.
Of course there exist algorithms that can't be easily parallelized. That's not the point. They're not the most common cases. And I'd be glad to demonstrate this to you by, say, pulling up random pieces of source from the Linux kernel or whatnot and showing with real-world examples.
What don't people parallelize this sort of stuff? Because they're too lazy and most programming languages (but C in particular) make it too much of a hassle. Hence they only parallelize when forced to, which means that the general case of your software runs fine, but the edge cases run terrible. It has nothing to do with whether the app *can* be parallelized. The overhwhelmingly vast percentage of code that could be sped up by parallelizing, 99.99% of the time isn't parallelized.
And it's not just about performance, it's about general user experiences. Threaded code is simply more pleasant to use. If I'm using, say, blender and I turn on decimate for a mesh, I have to sit there and wait for the mesh to finish decimating before I can do anything else. Anything at all. I can't go off and start developing a texture or tweak an unrelated object, I have to sit there and wait for that *one* task to finish. And sometimes these time wasters come accidentally or unexpectedly.
Threads are Good Things(tm), and they're way underused. And seriously, you want to talk about wasted silicon, you have to look no further than all of the huge amount of silicon that gets wasted trying to gain small incremental improvements in serial processing speed.
Exactly. Put simply, you get far more raw computing bang for your silicon buck with smaller, simpler cores.
What's so wrong with having our cake and eating it too? Why can't we have future system architectures like:
1x main core, made as fast as we realistically can
8x secondary cores, each 75% as fast as the main core but using a lot less silicon each
64x teriary cores, each 50% as fast as the main core, but again even simpler in terms of silicon consumption
Or some such? Your threader can try to keep the most intensive tasks on the main core. In the long run we could even have adaptive threading: all threaded function calls are interpreted by a bayesian thread launcher that does random sampling of how performance of different threads varies when their components are launched in different threading environments (including "completely unthreaded and inline") and changes the odds of launching in different environments accordingly. So the programmer could use threads and futures to their heart's content and all work gets distributed out where it best belongs.
Another thing to simplify the task for programmers would be changes to standards to even further simplify the launching of threads in common situations. For example, a common programming recipe involves doing an operation on every member of an object. Quite often these can be done in parallel. Now, in C++ one could do a "std::for_each" or a "for (auto& i : container)" and have the have an iterative std::thread call inside of it. Of course, if you have a million entries, you probably don't want a million threads, so it gets more complicated, you want to break the iteration down into several sub-iterations, each with one thread iterating over a fraction of the total entries. But instead of making the programmer have to think about all that, why not have a "std::for_each_threaded" or "for (auto& i ~: container)" or somesuch that automatically threads your repetitive command as efficiently as possible?
No, as long as I/O bandwidth is not the limiting factor. The sort of thing you're compiling can have radically different CPU vs. I/O requirements. Some simple but verbose C code with little optimization might be almost entirely IO limited while some heavy templated C++ and full optimization might be almost entirely CPU limited.
The thing is, there's no way to know what is going to cause a particular person to think "I wish my computer was performing faster". It all depends on the individual and what they use. But one can name various cases that might likely cause a certain subset of users headaches, and so those become use cases for improving system performance. One such use case is clearly compilation that's not IO-limited.
No, it's a good example of disproving Linus's point. Even if one can't conceive of an algorithm that can paginate in a non-linear fashion, they can certainly well bloody paginate each of the 100 books at the same time, each on their own core.
And seriously, renumbering pages is supposed to be some sort of complicated task, according to you? *boggle*
The key question is, what are as many common example cases one can list (in order of frequency times severity) where users' computers have lagged by a perceptible amount which in any way reduced their user experience, or caused the user to have to forgo features that would otherwise have been desirable? Then you need to look at the cause.
In the overwhelming majority of cases, you'll find that "more parallelism with more cores" would be a solution. So why not just bloody do it?
Not everybody suffers performance problems in the same way. But the vast majority of peoples' performance problems can be solved by the same solution.
It's not a straw man at all - I know how to read. He literally says "magical parallel algorithms" are needed to make use of hundreds of cores. And he says "The only place where parallelism matters is in graphics or on the server side, where we already largely have it", which is nothing more than pointing out that apps that need high performance (aka, graphics and servers) *do* in fact use parallelism. What you claim is "Linus's argument" isn't even brought up until the last paragraph. And the only reason that the CPU would "still going be a few core and not many core" is if programmers don't threading their cpu-intensive apps sufficiently. Which, one should note, are mainly graphics and server stuff, the things that Linus notes *are* being threaded.
I'm wondering about what he is thinking for real-world details. For example, a common use case is one thread does searches through a data structure to find an element (as, say, a pointer or an iterator), but before it can dereference it and try to access the memory, some other thread comes along and removes it from the list and frees it. Then your program tries to dereference a pointer or iterator that's no longer valid and it crashes.
The problem isn't that it's no longer in the list. Clearly the other thread had a good reason to remove it and if your first thread had happened just a split second later it never would have seen the removed entry. The problem is that your program crashes because it's trying to use a freed memory address.
What sort of implementation details is he thinking of that prevent this sort of problem? I mean, if he actually has a realistic solution, I'd love to see it, it could make for a brilliant extension of STL containers.
There are cases where getting exactly the right answer doesn't matter - real-time graphics is a good example. It's amazing the level of error you can have on an object if it's flying quickly past your field of view and lots of things are moving around. In "The Empire Strikes Back" they used a bloody potato and a shoe as asteroids and even Lucas didn't notice.
That said, it's not the general case in computing that one can tolerate random errors. Nor is the concept of tolerating errors anything new. Programmers have been using for example approximations for square roots for a long, long time to save compute cycles where precision takes a back seat to "just get the shape of the curve roughly right". There's even a number of lower-precision hardware math methods.
Indeed. There's tons of CPU-intensive tasks that need to be done in a modern computer game, but they're typically done as:
Rather than...
I really hope with how easy it's gotten in C++11 that more people will make better use of threads. In the first example code, not only do you relegate all of your tasks to the same core, thus hitting performance, but if any one task hangs, all of them hang. It's a terrible approach, but it's the most common. The only case where threads aren't good is where you're doing heavy concurrent read/writes to the same cached data, but in real world apps there's almost always a level where you can launch the thread where this isn't the case, if it's even an issue to begin with in your particular application. The presumption that concurrent access to cached memory will usually or always be a problem (which seems to be Linux's presumption) requires that A) your threads not doing the majority of their work on thread-local memory, AND B) that the shared data area being read from / written to concurrently is small enough to be cached, AND C) you can't just migrate your threads up in scope N levels to work around any such issue.
Linus's argument basically boils down to, "Parallel algorithms are sorcery, and the only place they matter are places applications that demand performance which are indeed increasingly using parallelism".
Of course you don't need, say, a 50-threaded version of vi or alsamixer or whatever. But for apps that need performance, increasingly they have to get them from threading. And there's nothing "magical" about parallelism. Perhaps in Linus's dislike for C++ he's missed how trivially easy it's gotten to launch threads in C++11, but it takes less work now than a for-loop, since std::thread is so simple and you can inline the command with a lambda. And you have a nice clean mutex library including scoped mutexes like std::lock_guard so you don't even have to remember to unlock them.
It's quite true that having multiple cores needing to read to and write from the same chunk of memory isn't a good thing. But I'd bet you that only in under 5% or so of high performance apps is that the *only* level you can thread at. Because if you have say five nested levels of looping, 4 of them can be memory constrained, but so long as least just one can be threaded without heavy reads/writes on shared cache, you can thread to your heart's content with minimal adverse impact. And "heavy" is the key word. So long as you're not doing essentially *constant* heavy reads/writes on shared cache, the overhead cost is minimal.
They try to spin it as so malicious, including:
Right, it's not like they had any probable cause of illegal activity back in 2011, no sirree.... You've got a Wikileaks volunteer who was at the time acting as an unofficial spokeman for the organization in the news, voluntarily coming up to them and telling them that Assange is working with Anonymous and LulzSec and ordering hacks and spying, including against US targets, and providing troves of data - are they supposed to just ignore that?