Using CC or BCC as a substitute for a mailing list is a good indicator that the organisation in question has no IT skills at all and probably shouldn't be trusted with any data that you might want to be confidential and that they might want to store on a computer.
why would you ever want to actually write a sorting algorithm? After all, somebody out there has already done it better, and that's nothing you would ever need to do as real programmer.
This sounds like the assignments were badly designed. Unless your data has an entirely random distribution, with some knowledge of the data that you're sorting you can do a much better job of sorting than any generic comparison-based algorithm. If you're sorting English words, for example (a very common example data set for this kind of thing), then a radix sort implemented by a student will do a better job than a standard library quicksort that's doing a full string comparison on each pair. If the course also asks them to implement a quicksort, and to evaluate both against libc's qsort(), then they should hopefully learn both when it is and when it isn't appropriate to implement their own.
Because (in the part of the post that I quoted in my reply), he said:
-Os frankly is of little interest to desktop developers
And I replied that -Os is relevant to desktop users, which you then disputed by saying that it's not relevant to HPC.
Modern desktops are putting a lot of effort into reducing the number of wakeups per second in orer to reduce power draw. This means that on most systems, there are a lot of processes, but very few running at any given time.
Timer coalescing does the exact opposite. It means that you'll have a single wakeup and then a load of processes run, and then sleep. This increases i-cache pressure, it doesn't reduce it.
The one that bugs me the most is the imbalance between how society treats knowledge of humanities and sciences. If a scientist doesn't know about history, then he fits the 'ignorant scientist' cliche and is a figure of fun. If a historian knows far less about the science that his daily life depends on, then he's considered a cultured and well-rounded individual. And, in my experience, the humanities person who is ignorant of science is far more prevalent than the scientist or engineer who is ignorant of humanities.
First: NIST? Really? I guess you've not been paying attention for the last couple of years.
Second: You misunderstand the grandparent. If you don't understand the basic ideas behind a crypto algorithm (or, more importantly, crypto protocols) then you will pick the wrong one. No matter how good a cypher is, or how verified the implementation is, if used incorrectly it will still be insecure.
Serif fonts work fine on small devices, they don't work well at low DPI. Which, in an age of 200+DPI on cheap devices, means that this move makes little sense. The only reason that the scaling is a problem would be if they're doing something stupid, like using a bitmap image rather than a vector. And, of course, a quick trip to google.com confirms that they are, indeed, using a png rather than an svg (with png fallback if they care that much) for their logo.
So, the real story here is that, in 2015, web giant Google has yet to learn that resolution-independent images are a thing.
It's pretty easy on anything running X11, where the authentication of things that are allowed to deliver arbitrary input events to other applications is 'oh, you're a program that can read this user's home directory or from a trusted IP address? Go right ahead! By the way, if you're not then you're not allowed to put windows on the screen.' Windows has a similar mechanism, but has a special category of window that can only receive input from privileged components (i.e. real input devices and designated assistance apps). I filed a bug with Apple about the ease of spoofing the Keychain authorisation and privilege elevation dialogs against OS X 10.2. Maybe by 10.11 they'll fix it...
LLVM was originally developed as a research project at UIUC, by Chris Lattner supervised by Vikram Adve. It was offered to the FSF as a new optimisation framework for GCC, but the FSF turned it down. Chris was hired by Apple and they used LLVM for the CPU fallback path for their GLSL compiler (giving them a compiler that could target SSE and AltiVec and work on x86 and PowerPC, both 32-bit and 64-bit variants, reusing the same code for most of the implementation as the interpreter). In 2007, Chris began work on a new C front end and open sourced it. Initial work on Clang (basically getting it up to the point where it was as more-or-less useable C compiler, could parse Objective-C, and had a token nod at C++) was done entirely in Apple and then a lot of the development was done at Apple. A few of the other bits are still led by Apple people: the Clang static analyser is mostly developed by Apple people and the work on statepoints / patchpoints in LLVM was led by Apple's WebKit JavaScript team (though now there's a lot of work from people at Azul and MSR).
If you're doing HPC, then you're definitely not the kind of 'desktop user' that the grandparent was talking about. For a single compute-bound application consuming all of the system resources, -O2 or -O3 will almost always win (unless they manage to blow out L1 i-cache on a hot loop, which does happen but is quite rare). When you benchmark systems with a lot of active processes, then the numbers become very different, because cache contention starts to matter (so does TLB contention, though on x86 with the hardware page table walker, fills are cheap if they hit in L1, so this boils down to cache contention again).
Nonsense. The income that you'll get is number of people in the market multiplied by amount that you can get from each one. People with luxury yachts will spend a lot, but there are hardly any of them. If there are 4 times as many Android users as iOS users, but iOS users are willing to part with 5 times as much money (on average), then iOS is a better market to be in. Even if iOS users are only willing to spend 3 times as much, it's still a good market to be in because each customer likely adds to your support / accounting costs and having a slightly lower income with a quarter of the number of customers may be more profitable.
You're talking about hardware makers. I'm talking about software vendors. If I make an iOS app and an Android app, what proportion of Android users will buy it, what proportion of iOS users will? If 4% of iOS users and 1% of Android users are willing to hand over money for it, then that's about the same amount from each platform. Numbers that I've seen are a bit out of date now, but they showed that iOS users were spending a lot more (per capita) than Android users, as most Android users only install free (including ad supported) apps, and ad revenue is far less than a direct sale can make.
There have been cases where EULAs that were not presented before the product was purchased were declared grounds for returning the product for a full refund. There is also a huge body of case law on contracts in general. In common law countries, the requirement for a contract to be binding is that a 'meeting of minds' has occurred and it is up to the party wishing to enforce the contract to prove this. Signatures, for example, provide strong evidence (and the backing of case law that they count as evidence), but there is very little statute law defining what makes a contract binding (though some on what makes one non-binding, such as requiring one party to break a law).
How many people do you think read all of the T&Cs? How many people do you know who have read the Facebook T&Cs, for example (I know two, but I don't know anyone who has both read them and agreed to them)?
How do those numbers change if you look at revenue? Last numbers I saw showed that the iOS ecosystem made about as much money as the Android one for app developers. If you have a small market, but that market has the majority of people who have disposable income and are willing to spend it, then it's not such a good idea to ignore it.
It depends hugely on the workload and it also depends a lot on the core. The ARMv8 ecosystem is quite diverse. For example, you have some players like nVidia's Project Denver, which fuses some of their GPU ideas with designs inherited from Transmeta. The Denver core is VLIW, but with staggered pipelines, so that results from one instruction in a VLIW bundle can be fed into the next (without needing rename registers, which are one of the biggest power sinks on a modern OoO CPU). When you start a program running, there's a simple decoder that turns ARM instructions into fairly inefficient VLIW instructions, but after a little while hot loops are optimised by a JIT and get a lot faster.
At the other end of the design spectrum, Cavium's Thunder X has 48 ARMv8 cores (not hyperthreads) per die, and supports dual-socket configurations for up to 96 processors per board. Individually the cores are weaker than a Xeon, but on some workloads (network routing, some database serving), they're pretty impressive in aggregate. That many physical cores also makes it easier to load balance VMs in a hosted environment. This is especially good for the kind of workload where most clients are idle for a lot of the time, but when they're busy they're very busy.
I guess reading TFA is too much to ask. Most of OpenMP 4 is done in Intel's development branch and is in the process of being merged, several OpenMP 4 pragmas are in the 3.7 release.
-Os frankly is of little interest to desktop developers. Heck, I spend quite a bit of my time on 8 bitters these days, and I think you're being pedantic.
You might want to tell Apple that, as they compile everything with -Os. It turns out that instruction cache pressure still matters, and matters a lot more if you're in the kind of environment where multiple applications are competing for space.
Objective-C++ also works pretty well now (including in the open source implementation), to the point that I generally prefer C++ containers to Objective-C ones. std::unordered_map seems to be faster than NSMutableDictionary for most things, and has the added advantage that you can have primitive types as keys or values without resorting to boxing. The big problem for Swift is that the FFI to C is fine, but the FFI to C++ is basically nonexistent.
I'm not 100% sure, but I think that Google passed Apple as the largest single contributor (incrementally, at least, not cumulatively) somewhere in the 3.5 to 3.7 time frame. A lot of the Apple compiler team has been busy with Swift.
It's not a question of open vs proprietary, it's a question of buying support from the right people. If you're running code that wasn't developed in house, then you probably don't want to be supporting it in house either. You want an SLA with penalty clauses with someone who will fix it when it breaks. If it's open source, that just means that you have more options in terms of who will support it if the level of support that you want involves fixing bugs and adding features.
I was going to comment that I'd expect some variation depending on the quality of the venue, but then I looked at the list. Most of the places that they looked at are top-tier publications, so it's pretty depressing. That said, they are focussing on the wrong aspect of reproducibility. The real metric should be, given the paper, can someone else recreate your work. And I suspect that even more papers fail on that. At the ASPLOS panel discussion this year, there was a proposal that PhD students should spend their first year reproducing some published result. We often do something similar for undergraduate projects (take an idea from a paper, reimplement it, see if your results support their claim).
Slashdot Mirror
Do you? Can't the app just fork a child that runs the osascript tool (which should already have this permission) with the AppleScript?
Using CC or BCC as a substitute for a mailing list is a good indicator that the organisation in question has no IT skills at all and probably shouldn't be trusted with any data that you might want to be confidential and that they might want to store on a computer.
why would you ever want to actually write a sorting algorithm? After all, somebody out there has already done it better, and that's nothing you would ever need to do as real programmer.
This sounds like the assignments were badly designed. Unless your data has an entirely random distribution, with some knowledge of the data that you're sorting you can do a much better job of sorting than any generic comparison-based algorithm. If you're sorting English words, for example (a very common example data set for this kind of thing), then a radix sort implemented by a student will do a better job than a standard library quicksort that's doing a full string comparison on each pair. If the course also asks them to implement a quicksort, and to evaluate both against libc's qsort(), then they should hopefully learn both when it is and when it isn't appropriate to implement their own.
How do you know he's a desktop user?
Because (in the part of the post that I quoted in my reply), he said:
-Os frankly is of little interest to desktop developers
And I replied that -Os is relevant to desktop users, which you then disputed by saying that it's not relevant to HPC.
Modern desktops are putting a lot of effort into reducing the number of wakeups per second in orer to reduce power draw. This means that on most systems, there are a lot of processes, but very few running at any given time.
Timer coalescing does the exact opposite. It means that you'll have a single wakeup and then a load of processes run, and then sleep. This increases i-cache pressure, it doesn't reduce it.
CSS is actually a Turing-complete language these days, though you'd have to be completely insane to try to implement a complex algorithm in it.
The one that bugs me the most is the imbalance between how society treats knowledge of humanities and sciences. If a scientist doesn't know about history, then he fits the 'ignorant scientist' cliche and is a figure of fun. If a historian knows far less about the science that his daily life depends on, then he's considered a cultured and well-rounded individual. And, in my experience, the humanities person who is ignorant of science is far more prevalent than the scientist or engineer who is ignorant of humanities.
Second: You misunderstand the grandparent. If you don't understand the basic ideas behind a crypto algorithm (or, more importantly, crypto protocols) then you will pick the wrong one. No matter how good a cypher is, or how verified the implementation is, if used incorrectly it will still be insecure.
Serif fonts work fine on small devices, they don't work well at low DPI. Which, in an age of 200+DPI on cheap devices, means that this move makes little sense. The only reason that the scaling is a problem would be if they're doing something stupid, like using a bitmap image rather than a vector. And, of course, a quick trip to google.com confirms that they are, indeed, using a png rather than an svg (with png fallback if they care that much) for their logo.
So, the real story here is that, in 2015, web giant Google has yet to learn that resolution-independent images are a thing.
It's pretty easy on anything running X11, where the authentication of things that are allowed to deliver arbitrary input events to other applications is 'oh, you're a program that can read this user's home directory or from a trusted IP address? Go right ahead! By the way, if you're not then you're not allowed to put windows on the screen.' Windows has a similar mechanism, but has a special category of window that can only receive input from privileged components (i.e. real input devices and designated assistance apps). I filed a bug with Apple about the ease of spoofing the Keychain authorisation and privilege elevation dialogs against OS X 10.2. Maybe by 10.11 they'll fix it...
There's a work-in-progress Fortran front end, but it's definitely understaffed.
LLVM was originally developed as a research project at UIUC, by Chris Lattner supervised by Vikram Adve. It was offered to the FSF as a new optimisation framework for GCC, but the FSF turned it down. Chris was hired by Apple and they used LLVM for the CPU fallback path for their GLSL compiler (giving them a compiler that could target SSE and AltiVec and work on x86 and PowerPC, both 32-bit and 64-bit variants, reusing the same code for most of the implementation as the interpreter). In 2007, Chris began work on a new C front end and open sourced it. Initial work on Clang (basically getting it up to the point where it was as more-or-less useable C compiler, could parse Objective-C, and had a token nod at C++) was done entirely in Apple and then a lot of the development was done at Apple. A few of the other bits are still led by Apple people: the Clang static analyser is mostly developed by Apple people and the work on statepoints / patchpoints in LLVM was led by Apple's WebKit JavaScript team (though now there's a lot of work from people at Azul and MSR).
Are you testing the performance of a single program, or of an entire system? The numbers generally change quite a lot when you look at interference.
If you're doing HPC, then you're definitely not the kind of 'desktop user' that the grandparent was talking about. For a single compute-bound application consuming all of the system resources, -O2 or -O3 will almost always win (unless they manage to blow out L1 i-cache on a hot loop, which does happen but is quite rare). When you benchmark systems with a lot of active processes, then the numbers become very different, because cache contention starts to matter (so does TLB contention, though on x86 with the hardware page table walker, fills are cheap if they hit in L1, so this boils down to cache contention again).
Nonsense. The income that you'll get is number of people in the market multiplied by amount that you can get from each one. People with luxury yachts will spend a lot, but there are hardly any of them. If there are 4 times as many Android users as iOS users, but iOS users are willing to part with 5 times as much money (on average), then iOS is a better market to be in. Even if iOS users are only willing to spend 3 times as much, it's still a good market to be in because each customer likely adds to your support / accounting costs and having a slightly lower income with a quarter of the number of customers may be more profitable.
You're talking about hardware makers. I'm talking about software vendors. If I make an iOS app and an Android app, what proportion of Android users will buy it, what proportion of iOS users will? If 4% of iOS users and 1% of Android users are willing to hand over money for it, then that's about the same amount from each platform. Numbers that I've seen are a bit out of date now, but they showed that iOS users were spending a lot more (per capita) than Android users, as most Android users only install free (including ad supported) apps, and ad revenue is far less than a direct sale can make.
There have been cases where EULAs that were not presented before the product was purchased were declared grounds for returning the product for a full refund. There is also a huge body of case law on contracts in general. In common law countries, the requirement for a contract to be binding is that a 'meeting of minds' has occurred and it is up to the party wishing to enforce the contract to prove this. Signatures, for example, provide strong evidence (and the backing of case law that they count as evidence), but there is very little statute law defining what makes a contract binding (though some on what makes one non-binding, such as requiring one party to break a law).
How many people do you think read all of the T&Cs? How many people do you know who have read the Facebook T&Cs, for example (I know two, but I don't know anyone who has both read them and agreed to them)?
How do those numbers change if you look at revenue? Last numbers I saw showed that the iOS ecosystem made about as much money as the Android one for app developers. If you have a small market, but that market has the majority of people who have disposable income and are willing to spend it, then it's not such a good idea to ignore it.
At the other end of the design spectrum, Cavium's Thunder X has 48 ARMv8 cores (not hyperthreads) per die, and supports dual-socket configurations for up to 96 processors per board. Individually the cores are weaker than a Xeon, but on some workloads (network routing, some database serving), they're pretty impressive in aggregate. That many physical cores also makes it easier to load balance VMs in a hosted environment. This is especially good for the kind of workload where most clients are idle for a lot of the time, but when they're busy they're very busy.
I guess reading TFA is too much to ask. Most of OpenMP 4 is done in Intel's development branch and is in the process of being merged, several OpenMP 4 pragmas are in the 3.7 release.
-Os frankly is of little interest to desktop developers. Heck, I spend quite a bit of my time on 8 bitters these days, and I think you're being pedantic.
You might want to tell Apple that, as they compile everything with -Os. It turns out that instruction cache pressure still matters, and matters a lot more if you're in the kind of environment where multiple applications are competing for space.
Objective-C++ also works pretty well now (including in the open source implementation), to the point that I generally prefer C++ containers to Objective-C ones. std::unordered_map seems to be faster than NSMutableDictionary for most things, and has the added advantage that you can have primitive types as keys or values without resorting to boxing. The big problem for Swift is that the FFI to C is fine, but the FFI to C++ is basically nonexistent.
and I believe are its biggest contributors
I'm not 100% sure, but I think that Google passed Apple as the largest single contributor (incrementally, at least, not cumulatively) somewhere in the 3.5 to 3.7 time frame. A lot of the Apple compiler team has been busy with Swift.
It's not a question of open vs proprietary, it's a question of buying support from the right people. If you're running code that wasn't developed in house, then you probably don't want to be supporting it in house either. You want an SLA with penalty clauses with someone who will fix it when it breaks. If it's open source, that just means that you have more options in terms of who will support it if the level of support that you want involves fixing bugs and adding features.
I was going to comment that I'd expect some variation depending on the quality of the venue, but then I looked at the list. Most of the places that they looked at are top-tier publications, so it's pretty depressing. That said, they are focussing on the wrong aspect of reproducibility. The real metric should be, given the paper, can someone else recreate your work. And I suspect that even more papers fail on that. At the ASPLOS panel discussion this year, there was a proposal that PhD students should spend their first year reproducing some published result. We often do something similar for undergraduate projects (take an idea from a paper, reimplement it, see if your results support their claim).