High-precision math is an excellent time to use assembly language. Assembly languages generally have a way to express ideas like a 32x32->64-bit multiply (and 64x64->128-bit multiply), and add-with-carry. High-level languages generally support neither of those options directly. To tell the compiler that you want a 32x32->64-bit multiply you generally have to have two 32-bit inputs, then cast one of them to 64-bit, and hope that the compiler doesn't actually generate a 64x64 multiply.
That has nothing to do with "hope". Clang and GCC do that without any problems. Clang and GCC also support 128 bit integers on 64 bit processors and do the same there. Worst case, you build some inline assembler functions and use them as building blocks. Then you can do anything in high level language, and leave all the boring details to the compiler.
There's nothing rare about it. SIMD vectorization is useful in tons of applications.
Vectorization is not the same as assembler. You can do vectorization just fine in a high level language. Actually, SSE3 is an absolute pain in the ass in assembler and trying to use it in assembler is absolutely misguided.
I have on several occassions taken assembler code and sped it up significantly by turning it into normal high level language code.
To make an algorithm fast, you need to improve the algorithm (so the number of operations that the algorithm needs to perform are minimised), and improve the number of operations per time unit that the algorithm can perform. Assembler _may_ help with the second task. However, writing asssembler code is much much more time consuming, so in a fixed amount of development time, much less time is spent on improving the algorithm itself. And anything that I ever looked at that was really time critical, I managed to get huge improvements through improved algorithms which I would never have managed had I written assembler code.
Flash is already a bit weirdly sized because of extra bits for Flash Translation Layer to do block management.
When you buy a car, they tell you how many horse powers the engine has, and they don't deduct the power needed for climate control, wind screen wiper, lights and so on.
No, I have not the 8GB, 16GB, whatever GB they are selling. I rather think if those gentlemen want to him, rather than complaining about the new OS taking more memory (stupid), they could complaint about Apple misleading people about 1K = 1000. I certainly feel cheated about my "128" iPhone having only 114GB.
You are not cheated, you are stupid. Everyone knows that 128GB = 128 billion bytes. Geeks know that 128GiB = 128 x 1024 x 1024 x 1024 bytes. Idiots "know" that 128GB = 128 x 1024 x 1024 x 1024 bytes, but they are wrong.
next lawsuit: at walmart the price on the shelf is different than the price at the register due to sales tax. class action!
As a non-american, I found this really annoying the first time I bought stuff in an American shop. I had a bit of money in my pocket (a few dollars) and picked items just below the amount that I had. Then at the checkout they asked for more money than I had in cash. Really annoying.
Agreed. It's mostly bullshit reporting too. 65% of cancers are not caused by "bad luck". They are caused by yet unknown reasons. Unknown reasons is not "bad luck". Bad luck is getting hit by a meteor.
"Unknown reasons" _is_ bad luck. If there are things that I should avoid and could avoid to increase my chances of being cancer free, but nobody knows about it, then it is just bad luck if I encounter these things. If there are things that I know I should avoid but I can't avoid, that's also bad luck. Being hit by a meteor is just an extreme case of the second kind of "bad luck"; it's something I know I should avoid but I can't.
Mostly writing code for MacOS X and iOS. All current devices have two or more cores. Writing multi-threaded code is made rather easy through GCD (Grand Central Dispatch), and anything receiving data from a server _must_ be multithreaded, because you never know how long it takes to get a response. So there is an awful lot of multi-threaded code around.
But the fact that work is distributed to several cores is just secondary for that kind of work. It is also easy to make most work-intensive code use multiple cores. There are calls like sorting an array or searching for an item with multi-threaded variants. With GCD, you can just say "do this task on a background thread", and if you have five things to do, it uses five threads and up to five cores. It's so easy that people do it a lot without measuring how efficient it is. As long as your software is fast enough, it's fine.
The typical result is an application that uses multiple cores to some degrees, but may have bottlenecks that require a single core. Now on an iPhone with 2 cores, that's fine. (If 30% of your time needs to run on a single core, but you have only two cores, it doesn't matter). On an iMac with 4 cores, it's quite OK. On a monster MacPro with 24 threads it might be a problem. On a hypothetical machine with 100s of cores it _is_ a problem.
So your typical MacOS X or iOS app written by reasonably competent people will work fine in the current environment, but would need major changes to take advantage of 100s of cores.
I'll give you an example. I use iBooks to read eBooks. I downloaded two eBooks which are actually each a collection of fifty full-size books. On my MacBook, the one I'm currently reading displays that it's around page 8,000. The total is about ten thousand pages.
If I change the font size, it recalculates the pages and page breaks for the whole book. One CPU running at 100% for a very long time. For a five hundred page book, no problem. For a ten thousand page book, big problem. I'd love it if the re-pagination process would use all the cores that are available.
It is not illegal for people to be in a home. It is also not illegal for weapons to be in a home. The things they propose were the justification for their search were not even illegal.
Since the person they found was a known violent criminal, any weapons in the house accessible to him were illegal. And the other person who they believed to be living in the house was another known criminal. So they did a quick search to make sure that there was no other criminal holding a gun around in the house.
They were not looking for something illegal, they were looking for something _dangerous_.
From that crappy summary it's practically impossible to tell what's going on. Why does the police need to know who is in a house anyway? What crime are we talking about? Being in a house? Not being in a house? I really don't get it.
If they are looking for a criminal on the run, and they have a reasonable suspicion that he is inside the house, they can search the house. If they don't have a reasonable suspicion that he is inside the house, they can't search the house. If that doppler radar shows that there is someone, anyone in the house, that makes it more likely that the person they are looking for is inside.
For "reasonable suspicion" it isn't necessary that it's more likely he is inside than not, just that there is a good chance. If they knew the house was empty they wouldn't have been allowed to enter.
What he said was that the police had enough grounds to believe the person was at home to enter. So _if_ evidence by the use of the Doppler radar was unlawful, it didn't matter, because the police had enough evidence without that.
Interestingly, the police searched the home because they believed there might be other people and weapons present (they did find weapons), while the doppler radar only spotted one person. Here the judge decided that as far as he knew, the doppler radar was not enough evidence that there only was one person. If the doppler radar worked better, then the police could _know_ that there is one and only one person, and wouldn't be allowed to do a search in case there is someone else dangerous in the house, but that wasn't the case.
Feel me? Good. Some people are blessed with the right bodies and cars to drive safely at 120 MPH on 60 MPH limited roads; others doing 30 MPH is a challenge.
120mph on a 60mph limited road is only safe if there is actually not one car in your sight. No matter who you are.
We have ever increasing armies of people who should not drive any longer, namely, the partly-disabled elderly.
Maybe we can start by sorting out a much more dangerous group, kids driving cars that they can't handle, who think they are invincible, and who think speeding in dangerous situations is a sign of being a good driver.
Two that you forgot: Parking. I drive right to the entrance of a store and the car parks itself. Much tighter than usual; almost door to door, and four cars in a row instead of two (assuming your car can leave its spot for a minute if a blocked car needs to get out).
The other: Driving not with less distance, but with no distance whatsoever. Basically turning ten cars into a giant truck. You would have to change the bumpers a bit to handle this. You get _a lot_ more traffic through, and you save a lot of fuel.
Well, that's Google's mistake obviously. They shouldn't patent the driverless car and everything associated with it, they should copyright it, then it would be theirs forever.
But then anybody can take a Google car apart, study it, learn what Google is doing, and build their own. As long as they don't copy it, that's fine. And I doubt you can copyright a car.
Apple doesn't _compete_ as a software company. By now, Apple could quite easily release MacOS X for PCs, and they would quite easily get a 25 percent OS market share. (Which would be a bad idea, because support cost would be horrendous, and they would lose tons of Mac sales, so it's not going to happen).
Very true...look at Apple and the bigger phone and smaller tablet....Samsung went to town on them....and they had to follow suite...
And now Samsung is in the shitters with revenue breaking down, profits absolutely breaking down, and having a very bad time competing against Apple at the high end and the Chinese manufacturers at the low end. It always goes up and down. At the moment, Apple is way up.
Uber - Highly dependent on the political winds. Will most likely encounter numerous well publicised attacks on woman that will generate calls for regulation. Then it is just a taxi company. So, might become a taxi franchise spanning multiple countries. The KFC of taxis.
I think their problem is that should they be successful, there is nothing to stop Google or Amazon from entering the market and just killing them.
Missing the point. I wasn't talking about USB, I was talking about Apple. So when Apple built a plastic colour Mac, and everybody started building plastic colour accessories, the future looked bright for Apple.
Read the headline. It's obviously enough to be "identified [...] as perpetrator". I know, I'm not a native english speaker, but doesn't that imply at least some level of guilt?
That sentence, as written, implies guilt, without any doubt. If I was the engineer who was accused, and everything was in the UK, I would sue for libel, and I would win.
So you support locking kids up in prisons where they have to expect physical harm for little more than a service interruption? What's your demand for theft? Stoning?
Not "little more". Just a service interruption. But a "service interruption" that was destroying Christmas fun for a few million people.
There was very little damage done to each person. Maybe a minute of jail sentence worth of damage. Multiply by a million, and you get two years.
If you don't realise what a DDoS attack does, then obviously you don't belong in jail. You belong into a home for seriously mentally handicapped people.
Slashdot Mirror
High-precision math is an excellent time to use assembly language. Assembly languages generally have a way to express ideas like a 32x32->64-bit multiply (and 64x64->128-bit multiply), and add-with-carry. High-level languages generally support neither of those options directly. To tell the compiler that you want a 32x32->64-bit multiply you generally have to have two 32-bit inputs, then cast one of them to 64-bit, and hope that the compiler doesn't actually generate a 64x64 multiply.
That has nothing to do with "hope". Clang and GCC do that without any problems. Clang and GCC also support 128 bit integers on 64 bit processors and do the same there. Worst case, you build some inline assembler functions and use them as building blocks. Then you can do anything in high level language, and leave all the boring details to the compiler.
There's nothing rare about it. SIMD vectorization is useful in tons of applications.
Vectorization is not the same as assembler. You can do vectorization just fine in a high level language. Actually, SSE3 is an absolute pain in the ass in assembler and trying to use it in assembler is absolutely misguided.
I have on several occassions taken assembler code and sped it up significantly by turning it into normal high level language code.
To make an algorithm fast, you need to improve the algorithm (so the number of operations that the algorithm needs to perform are minimised), and improve the number of operations per time unit that the algorithm can perform. Assembler _may_ help with the second task. However, writing asssembler code is much much more time consuming, so in a fixed amount of development time, much less time is spent on improving the algorithm itself. And anything that I ever looked at that was really time critical, I managed to get huge improvements through improved algorithms which I would never have managed had I written assembler code.
Flash is already a bit weirdly sized because of extra bits for Flash Translation Layer to do block management.
When you buy a car, they tell you how many horse powers the engine has, and they don't deduct the power needed for climate control, wind screen wiper, lights and so on.
No, I have not the 8GB, 16GB, whatever GB they are selling. I rather think if those gentlemen want to him, rather than complaining about the new OS taking more memory (stupid), they could complaint about Apple misleading people about 1K = 1000. I certainly feel cheated about my "128" iPhone having only 114GB.
You are not cheated, you are stupid. Everyone knows that 128GB = 128 billion bytes. Geeks know that 128GiB = 128 x 1024 x 1024 x 1024 bytes. Idiots "know" that 128GB = 128 x 1024 x 1024 x 1024 bytes, but they are wrong.
next lawsuit: at walmart the price on the shelf is different than the price at the register due to sales tax. class action!
As a non-american, I found this really annoying the first time I bought stuff in an American shop. I had a bit of money in my pocket (a few dollars) and picked items just below the amount that I had. Then at the checkout they asked for more money than I had in cash. Really annoying.
Why TF don't Apple have a slot for microSD card ike most smartphones these days.
Look at the article. How would that change? The complaint is that iOS 8 takes more space than iOS 7, and that is true no matter how much space.
Agreed. It's mostly bullshit reporting too. 65% of cancers are not caused by "bad luck". They are caused by yet unknown reasons. Unknown reasons is not "bad luck". Bad luck is getting hit by a meteor.
"Unknown reasons" _is_ bad luck. If there are things that I should avoid and could avoid to increase my chances of being cancer free, but nobody knows about it, then it is just bad luck if I encounter these things. If there are things that I know I should avoid but I can't avoid, that's also bad luck. Being hit by a meteor is just an extreme case of the second kind of "bad luck"; it's something I know I should avoid but I can't.
Mostly writing code for MacOS X and iOS. All current devices have two or more cores. Writing multi-threaded code is made rather easy through GCD (Grand Central Dispatch), and anything receiving data from a server _must_ be multithreaded, because you never know how long it takes to get a response. So there is an awful lot of multi-threaded code around.
But the fact that work is distributed to several cores is just secondary for that kind of work. It is also easy to make most work-intensive code use multiple cores. There are calls like sorting an array or searching for an item with multi-threaded variants. With GCD, you can just say "do this task on a background thread", and if you have five things to do, it uses five threads and up to five cores. It's so easy that people do it a lot without measuring how efficient it is. As long as your software is fast enough, it's fine.
The typical result is an application that uses multiple cores to some degrees, but may have bottlenecks that require a single core. Now on an iPhone with 2 cores, that's fine. (If 30% of your time needs to run on a single core, but you have only two cores, it doesn't matter). On an iMac with 4 cores, it's quite OK. On a monster MacPro with 24 threads it might be a problem. On a hypothetical machine with 100s of cores it _is_ a problem.
So your typical MacOS X or iOS app written by reasonably competent people will work fine in the current environment, but would need major changes to take advantage of 100s of cores.
I'll give you an example. I use iBooks to read eBooks. I downloaded two eBooks which are actually each a collection of fifty full-size books. On my MacBook, the one I'm currently reading displays that it's around page 8,000. The total is about ten thousand pages.
If I change the font size, it recalculates the pages and page breaks for the whole book. One CPU running at 100% for a very long time. For a five hundred page book, no problem. For a ten thousand page book, big problem. I'd love it if the re-pagination process would use all the cores that are available.
It is not illegal for people to be in a home. It is also not illegal for weapons to be in a home. The things they propose were the justification for their search were not even illegal.
Since the person they found was a known violent criminal, any weapons in the house accessible to him were illegal. And the other person who they believed to be living in the house was another known criminal. So they did a quick search to make sure that there was no other criminal holding a gun around in the house.
They were not looking for something illegal, they were looking for something _dangerous_.
From that crappy summary it's practically impossible to tell what's going on. Why does the police need to know who is in a house anyway? What crime are we talking about? Being in a house? Not being in a house? I really don't get it.
If they are looking for a criminal on the run, and they have a reasonable suspicion that he is inside the house, they can search the house. If they don't have a reasonable suspicion that he is inside the house, they can't search the house. If that doppler radar shows that there is someone, anyone in the house, that makes it more likely that the person they are looking for is inside.
For "reasonable suspicion" it isn't necessary that it's more likely he is inside than not, just that there is a good chance. If they knew the house was empty they wouldn't have been allowed to enter.
What he said was that the police had enough grounds to believe the person was at home to enter. So _if_ evidence by the use of the Doppler radar was unlawful, it didn't matter, because the police had enough evidence without that.
Interestingly, the police searched the home because they believed there might be other people and weapons present (they did find weapons), while the doppler radar only spotted one person. Here the judge decided that as far as he knew, the doppler radar was not enough evidence that there only was one person. If the doppler radar worked better, then the police could _know_ that there is one and only one person, and wouldn't be allowed to do a search in case there is someone else dangerous in the house, but that wasn't the case.
Feel me? Good. Some people are blessed with the right bodies and cars to drive safely at 120 MPH on 60 MPH limited roads; others doing 30 MPH is a challenge.
120mph on a 60mph limited road is only safe if there is actually not one car in your sight. No matter who you are.
I disagree: God+life is a bigger miracle than life alone.
And therefore much more unlikely.
We have ever increasing armies of people who should not drive any longer, namely, the partly-disabled elderly.
Maybe we can start by sorting out a much more dangerous group, kids driving cars that they can't handle, who think they are invincible, and who think speeding in dangerous situations is a sign of being a good driver.
Two that you forgot: Parking. I drive right to the entrance of a store and the car parks itself. Much tighter than usual; almost door to door, and four cars in a row instead of two (assuming your car can leave its spot for a minute if a blocked car needs to get out).
The other: Driving not with less distance, but with no distance whatsoever. Basically turning ten cars into a giant truck. You would have to change the bumpers a bit to handle this. You get _a lot_ more traffic through, and you save a lot of fuel.
Well, that's Google's mistake obviously. They shouldn't patent the driverless car and everything associated with it, they should copyright it, then it would be theirs forever.
But then anybody can take a Google car apart, study it, learn what Google is doing, and build their own. As long as they don't copy it, that's fine. And I doubt you can copyright a car.
Apple doesn't _compete_ as a software company. By now, Apple could quite easily release MacOS X for PCs, and they would quite easily get a 25 percent OS market share. (Which would be a bad idea, because support cost would be horrendous, and they would lose tons of Mac sales, so it's not going to happen).
Very true...look at Apple and the bigger phone and smaller tablet....Samsung went to town on them....and they had to follow suite...
And now Samsung is in the shitters with revenue breaking down, profits absolutely breaking down, and having a very bad time competing against Apple at the high end and the Chinese manufacturers at the low end. It always goes up and down. At the moment, Apple is way up.
Uber - Highly dependent on the political winds. Will most likely encounter numerous well publicised attacks on woman that will generate calls for regulation. Then it is just a taxi company. So, might become a taxi franchise spanning multiple countries. The KFC of taxis.
I think their problem is that should they be successful, there is nothing to stop Google or Amazon from entering the market and just killing them.
Missing the point. I wasn't talking about USB, I was talking about Apple. So when Apple built a plastic colour Mac, and everybody started building plastic colour accessories, the future looked bright for Apple.
... as soon as the first colored iMac was released, and everyone started building USB devices in colorful plastic cases.
Read the headline. It's obviously enough to be "identified [...] as perpetrator". I know, I'm not a native english speaker, but doesn't that imply at least some level of guilt?
That sentence, as written, implies guilt, without any doubt. If I was the engineer who was accused, and everything was in the UK, I would sue for libel, and I would win.
So you support locking kids up in prisons where they have to expect physical harm for little more than a service interruption? What's your demand for theft? Stoning?
Not "little more". Just a service interruption. But a "service interruption" that was destroying Christmas fun for a few million people.
There was very little damage done to each person. Maybe a minute of jail sentence worth of damage. Multiply by a million, and you get two years.
If you don't realise what a DDoS attack does, then obviously you don't belong in jail. You belong into a home for seriously mentally handicapped people.