Before even reaching single payer, there needs to be a legal requirement for a single charger! If you go to a particular doctor for treatment, ALL bills should come from that doctor or his facility. If they contract, that doesn't matter, that doctor is responsible for telling you how much you owe, being in-network with the insurance companies and so on. The current situation of going to an in-network doctor only to find he uses an anaesthetist or lab who is out of network and thus only partially covered is insane.
Your first word is 7 digits your second is 3, so clearly one is stronger than the other. "nom" is not in the diceware set, which helps a little, but it isn't so uncommon to be in a search dictionary. The numbers are in the diceware set.
You're comparing 7700^3 against 7700^7. Your more secure password isn't any better than chickensandwichwafflesworkcraigcrossafrica, probably a lot less good because chicken, delicious and nom clearly correlate heavily and nomnomnom is almost one word really. 7700^7 is 1604852326685300000000000000 according to my calculator. If I assume 72 characters (52 letters, 10 numbers, 10 special characters) then I need a 15 character random password to beat it in terms of search space. Maybe this: }&X$0ueUo~ravx&.
Further, if you put numbers between your letters you are turning a search space of 7700 into 7710 or whatever. If you replace l with 1 and so on, you are surely turning 7700 into 7700*(number of replacement options and combinations thereof). So mathematically, I would think that replacing e with 3, a with @ would actually be a stronger encoding that what you suggest.
You are indeed correct. Polymorphic lambdas as defined in C++ only apply template polymorphism to them. That's a subset of the possible forms of polymorphism, but I shouldn't really have used the term given that it has a definition in the standard now. Java lambdas (or C++ std::function wrapping of a lambda) is a different situation - those are only statically typed to the point of the interface, so any use of the lambda has to rely on a more dynamic typing mechanism (virtual function calls, maybe JIT inference), which is the situation I was alluding to.
Lambdas are a primary place where auto is there precisely because C++ is a strong, statically typed language as far as possible. The alternative might be polymorphic lambdas, which would require dynamic typing. With auto the type you get, and can propagate through templates, is the type of that specific lambda. With polymorphism the type you'd get is the type of a lambda, from which you'd need to infer which lambda. Auto ensures that with a lambda, though the type is not easily known to the programmer, the type can be statically defined in the code and propagated accordingly.
Google supports LLVM in the NDK. Renderscript is more like OpenCL where they restrict the input to make portability easier. Google also has the portable native client definition that aims to do something more general as you are suggesting, though that's for the desktop not android, admittedly. The thing is that LLVM is not actually portable between 32-bit and 64-bit anyway because C loses too much of that information at the early stages of compilation.
If you look at the SPIR spec (https://www.khronos.org/spir), which is an attempt to write a standardised version of an LLVM subset as you suggest, but for the OpenCL C subset so avoiding some of the complexities, you'll see that there are 32-bit and 64-bit versions and it really relies on the fact that OpenCL defines the sizes and layout of types more strictly than pure C does. LLVM is not a panacea in this case and a browse of past LLVM mailing lists will tell you that many of the devs are not keen on using it for portability because it isn't really what the IR was designed for.
Even roaming charges in countries not covered by that scheme are better. I maintain a 3 phone on a UK number even though I live in the US, partly because it's a way to keep the number I've had for 15 years, and partly because it is just cheaper to use in all countries other than the US. At the moment it's even cheaper to use IN the US if calling the UK, as you point out.
Average traffic is there in the old version too. The traffic view information seems less clear in the new version and it still doesn't allow you to estimate the time for a given route based on the average traffic.
Hopefully this will fall out nicely from the work they're doing on Sumatra/Graal. If they can generate independent streams of ALU work that suit GPU vector units they should be able to generate AVX/SSE code too. No need to concentrate on vectorising the entire application, which can be difficult given other aspects of the Java language, but just concentrate on using the stream APIs and related features that guarantee iteration independence.
That is a quirk of American trademarks that you don't see so much in other countries. It has always seemed strange to see "x brand y" used everywhere in the US. Understandable for the reason you point out, but not natural to non-Americans.
When you do it that way you have no control over which computations are inaccurate. There's a lot more you can do if you have some input information from higher levels of the system.
You may be happy that your pixels come out wrong occasionally, but you certainly don't want the memory allocator that controls the data to do the same. The point of this kind of technology (which is becoming common in research at the moment, the MIT link here is a good use of the marketing department) is to be able to control this in a more fine-grained fashion. For example, you could mark the code in the memory allocator as accurate - it must not have errors and so must enable any hardware error correction, might use a core on the platform that operates at a higher voltage, or would add extra software error correction as necessary. At the same time you might allow the visualization code to degrade to reduce overall power consumption, because the visualization code is not mutating any important data structures. Anything it generates is transient and the errors will barely be noticed.
GPU manufacturers have a tendency to use the word "core" to mean "one ALU in the middle of a vector unit". It's not really very different in principle from saying that an AVX unit is 8 cores, though, so you have to be careful with comparisons.
If you look at the AMD architecture for each compute unit, it's not so different from the cores you see on the CPU side, so it's much more fair to call the 7970 a 32 core chip. The way that a work item in OpenCL, say, or a shader instance in OpenGL maps down to one of those lanes is as much an artifact of the toolchain as of the architecture.
Hmm. After two years in California and then a year in Texas I ended up spending quite a bit to move my family back to California. Absolutely no comparison, and well worth paying for.
I don't know. On the same money my taxes raised slightly moving from London to California by the calculations I did at the time. VAT/California sales tax might have made a significant difference on top of that, but probably not enough to worry about given that the UK taxes had health insurance built into the number.
Make it 40 minutes and you can get a reasonable 2 or 3 bed for that comfortably. I much preferred my 40 minutes on the train doing that to my 20 minutes driving in California: the quiet reading time was wonderful. Both are preferable to where I am now by miles even given property prices.
Even the addition of vector units basically breaks that model. We now need intrinsics or help from vectorising compilers to map to the way the hardware works: C isn't a great match at all.
I tried to drop comcast TV last year and they told me it was cheaper to have internet + basic cable than internet alone. Of course it was... until 6 months later that specially discounted package ran out and my bill jumped. You have to keep an eye on it.
Re:Which is an... odd way to talk about graphics
on
Apple Unveils New iPad
·
· Score: 4, Interesting
Oh I don't know about that. I gave a talk only last week in which I described AMD's latest GPU (HD7970) as having 32 cores and I ran that content past some of the chip's architects first. If you look at the design of the chip it quite clearly has 32 cores: 32 scalar cores each of which having 4 16-wide SIMD units hanging off the side.
Of course, how the marketing department at Apple defines cores is open to question, but 4 strikes me as a reasonable number for an embedded GPU. The ARM Mali designs are around that kind of core count.
There is: AVX. The difference is that to cope with the workloads GPUs are NOT good at, a lot of the CPU transistors are dedicated to things other than AVX units and registers so the peak is lower.
Why would you not expect all of the participants to (statistically speaking) modify their behaviour in the same way? If the people who get the real anti-HIV drug modify, and the people who get the placebo modify then the chances are good that the modifications will be evenly spread with a large enough sample pool. If, given the modified behaviour, the HIV drug performs with statistically meaningful results then you have a positive result from the study.
Texture units clearly aren't cores, they're largely passive data pipelines. If you really look at a GPU more closely you can of course get far more complicated, The AMD architecture at the high end has two control flow cores with 24 SIMD coprocessors that execute blocks of non-control flow non-memory work. It is true that even those are hard to qualify as cores given their limited capabilities.
Without question a single SIMD lane is not a core, though.
Slashdot Mirror
Before even reaching single payer, there needs to be a legal requirement for a single charger! If you go to a particular doctor for treatment, ALL bills should come from that doctor or his facility. If they contract, that doesn't matter, that doctor is responsible for telling you how much you owe, being in-network with the insurance companies and so on. The current situation of going to an in-network doctor only to find he uses an anaesthetist or lab who is out of network and thus only partially covered is insane.
Your first word is 7 digits your second is 3, so clearly one is stronger than the other. "nom" is not in the diceware set, which helps a little, but it isn't so uncommon to be in a search dictionary. The numbers are in the diceware set.
You're comparing 7700^3 against 7700^7. Your more secure password isn't any better than chickensandwichwafflesworkcraigcrossafrica, probably a lot less good because chicken, delicious and nom clearly correlate heavily and nomnomnom is almost one word really. 7700^7 is 1604852326685300000000000000 according to my calculator. If I assume 72 characters (52 letters, 10 numbers, 10 special characters) then I need a 15 character random password to beat it in terms of search space. Maybe this: }&X$0ueUo~ravx&.
Further, if you put numbers between your letters you are turning a search space of 7700 into 7710 or whatever. If you replace l with 1 and so on, you are surely turning 7700 into 7700*(number of replacement options and combinations thereof). So mathematically, I would think that replacing e with 3, a with @ would actually be a stronger encoding that what you suggest.
It already is to some degree
You are indeed correct. Polymorphic lambdas as defined in C++ only apply template polymorphism to them. That's a subset of the possible forms of polymorphism, but I shouldn't really have used the term given that it has a definition in the standard now. Java lambdas (or C++ std::function wrapping of a lambda) is a different situation - those are only statically typed to the point of the interface, so any use of the lambda has to rely on a more dynamic typing mechanism (virtual function calls, maybe JIT inference), which is the situation I was alluding to.
Lambdas are a primary place where auto is there precisely because C++ is a strong, statically typed language as far as possible. The alternative might be polymorphic lambdas, which would require dynamic typing. With auto the type you get, and can propagate through templates, is the type of that specific lambda. With polymorphism the type you'd get is the type of a lambda, from which you'd need to infer which lambda. Auto ensures that with a lambda, though the type is not easily known to the programmer, the type can be statically defined in the code and propagated accordingly.
Google supports LLVM in the NDK. Renderscript is more like OpenCL where they restrict the input to make portability easier. Google also has the portable native client definition that aims to do something more general as you are suggesting, though that's for the desktop not android, admittedly. The thing is that LLVM is not actually portable between 32-bit and 64-bit anyway because C loses too much of that information at the early stages of compilation.
If you look at the SPIR spec (https://www.khronos.org/spir), which is an attempt to write a standardised version of an LLVM subset as you suggest, but for the OpenCL C subset so avoiding some of the complexities, you'll see that there are 32-bit and 64-bit versions and it really relies on the fact that OpenCL defines the sizes and layout of types more strictly than pure C does. LLVM is not a panacea in this case and a browse of past LLVM mailing lists will tell you that many of the devs are not keen on using it for portability because it isn't really what the IR was designed for.
Even roaming charges in countries not covered by that scheme are better. I maintain a 3 phone on a UK number even though I live in the US, partly because it's a way to keep the number I've had for 15 years, and partly because it is just cheaper to use in all countries other than the US. At the moment it's even cheaper to use IN the US if calling the UK, as you point out.
And you think this is a bigger problem than letting someone walk off with your credit card to where you can't see what they do with it?
Average traffic is there in the old version too. The traffic view information seems less clear in the new version and it still doesn't allow you to estimate the time for a given route based on the average traffic.
Although it does seem to have lost the little arrow that hinted which direction the camera would point in.
Hopefully this will fall out nicely from the work they're doing on Sumatra/Graal. If they can generate independent streams of ALU work that suit GPU vector units they should be able to generate AVX/SSE code too. No need to concentrate on vectorising the entire application, which can be difficult given other aspects of the Java language, but just concentrate on using the stream APIs and related features that guarantee iteration independence.
That is a quirk of American trademarks that you don't see so much in other countries. It has always seemed strange to see "x brand y" used everywhere in the US. Understandable for the reason you point out, but not natural to non-Americans.
When you do it that way you have no control over which computations are inaccurate. There's a lot more you can do if you have some input information from higher levels of the system.
You may be happy that your pixels come out wrong occasionally, but you certainly don't want the memory allocator that controls the data to do the same. The point of this kind of technology (which is becoming common in research at the moment, the MIT link here is a good use of the marketing department) is to be able to control this in a more fine-grained fashion. For example, you could mark the code in the memory allocator as accurate - it must not have errors and so must enable any hardware error correction, might use a core on the platform that operates at a higher voltage, or would add extra software error correction as necessary. At the same time you might allow the visualization code to degrade to reduce overall power consumption, because the visualization code is not mutating any important data structures. Anything it generates is transient and the errors will barely be noticed.
GPU manufacturers have a tendency to use the word "core" to mean "one ALU in the middle of a vector unit". It's not really very different in principle from saying that an AVX unit is 8 cores, though, so you have to be careful with comparisons.
If you look at the AMD architecture for each compute unit, it's not so different from the cores you see on the CPU side, so it's much more fair to call the 7970 a 32 core chip. The way that a work item in OpenCL, say, or a shader instance in OpenGL maps down to one of those lanes is as much an artifact of the toolchain as of the architecture.
Hmm. After two years in California and then a year in Texas I ended up spending quite a bit to move my family back to California. Absolutely no comparison, and well worth paying for.
I don't know. On the same money my taxes raised slightly moving from London to California by the calculations I did at the time. VAT/California sales tax might have made a significant difference on top of that, but probably not enough to worry about given that the UK taxes had health insurance built into the number.
Make it 40 minutes and you can get a reasonable 2 or 3 bed for that comfortably. I much preferred my 40 minutes on the train doing that to my 20 minutes driving in California: the quiet reading time was wonderful. Both are preferable to where I am now by miles even given property prices.
Even the addition of vector units basically breaks that model. We now need intrinsics or help from vectorising compilers to map to the way the hardware works: C isn't a great match at all.
I tried to drop comcast TV last year and they told me it was cheaper to have internet + basic cable than internet alone. Of course it was... until 6 months later that specially discounted package ran out and my bill jumped. You have to keep an eye on it.
Oh I don't know about that. I gave a talk only last week in which I described AMD's latest GPU (HD7970) as having 32 cores and I ran that content past some of the chip's architects first. If you look at the design of the chip it quite clearly has 32 cores: 32 scalar cores each of which having 4 16-wide SIMD units hanging off the side.
Of course, how the marketing department at Apple defines cores is open to question, but 4 strikes me as a reasonable number for an embedded GPU. The ARM Mali designs are around that kind of core count.
Auto in K&R was a storage class, not a request for compiler type inference.
There is: AVX. The difference is that to cope with the workloads GPUs are NOT good at, a lot of the CPU transistors are dedicated to things other than AVX units and registers so the peak is lower.
Why would you not expect all of the participants to (statistically speaking) modify their behaviour in the same way? If the people who get the real anti-HIV drug modify, and the people who get the placebo modify then the chances are good that the modifications will be evenly spread with a large enough sample pool. If, given the modified behaviour, the HIV drug performs with statistically meaningful results then you have a positive result from the study.
er... each of those cores has 16 things that aren't cores so they have lots of cores?
Each of the Cores on a i7 has an AVX pipe (or two, depending on how you look at it) with 8 ALUs in it. Does that mean a quad i7 has 32 cores?
Texture units clearly aren't cores, they're largely passive data pipelines. If you really look at a GPU more closely you can of course get far more complicated, The AMD architecture at the high end has two control flow cores with 24 SIMD coprocessors that execute blocks of non-control flow non-memory work. It is true that even those are hard to qualify as cores given their limited capabilities.
Without question a single SIMD lane is not a core, though.