Like I mentioned... the actual drawing is NOT the bottleneck (but every little bit helps).
Those images you see on the screens are backed by TB of data that has to be read in and distilled down before being renderable. That's what the thousands of cores are doing.
Also: those rotateable ones you see in the beginning are small. If you skip forward to the 2:30 mark you can see some of the larger stuff (note that we're not interactively rotating it). That movie at 2:30 took 24 hours to render on about 1,000 cores.
Again: The bottleneck was NOT rendering time. It was the time to read TB from disk and crunch the data down to the point where you had a renderable image.
Like I said: raw rasterizing isn't the main bottleneck... reading the data and transforming the data is.... both things better done on the CPU. Drawing frames takes up a very small amount of the overall runtime... but it's always nice to speed it up!
GPUs wouldn't help much in this scenario... and our CPU clusters are used for many things other than visualization.
Yes, we do have some dedicated "viz" clusters as well... but we typically don't use them because they are too small for loading many TB of data.
This is seriously useful for massive scientific visualization... where raw rendering speed isn't always the bottleneck (but of course, faster is better).
We do simulations on supercomputers that generate terabytes of output. You then have to use a smaller cluster (typically 1000-2000 processors) to read that data and generate visualizations of it (using software like Paraview ( http://www.paraview.org/ ) ). Those smaller clusters often don't have any graphics cards on the compute nodes at all... and we currently fall back to Mesa for rendering frames.
If you're interested in what some of these visualizations look like... here's a video of some of our stuff: https://www.youtube.com/watch?...
Look at my reply to the guy above you for a little more detail.
We _do_ actually test every every code change _before_ it enters a "devel" branch (everything flows through tested pull requests). Part of that testing is actually testing against _downstream_ applications (user's applications). Once it's deemed fit to go into "devel" the PR is merged and a new set of automated testing is kicked off... with more extensive testing against all downstream applications. If that passes then a "release" is automatically done by merging to our "stable" branch (which is actually master).
The entire system (other than pressing "Merge" on the PR) is completely automated... allowing us to roll out several releases per day that are guaranteed to work with all of our user's applications. This gives them the freedom to use the very most up to date version of the library (the master branch) without fear.
As for the version "number" it actually doesn't matter... no one talks about "I'm on version 4ce653b488b3f1a3f929caa136f63f7846303967"... the only question is: "Did you update today?"...
BTW: If we make an incompatible API change (which is rare). _WE_ actually put in PR's to all of our downstream user's applications (currently numbering in the hundreds) to fix their applications.
The purpose of all of this (which is talked about in the papers) is to keep the entire community running on the newest code... all the time. It trades support burden (of old versions) for a burden of always passing extremely rigorous tests. We've found it to be a really positive thing and our userbase is continuing to grow because of it.
About that userbase. This is massively-parallel, scientific and engineering software (the kind that runs on the largest supercomputers in the world). Several hundred users is actually pretty great;-)
You obviously didn't even bother a cursory glance at the two papers I pointed to. We spend a LOT of time doing release engineering... we just build it all into an automated system so that we can do multiple "releases" per day.
We actually test every code change against a large set of our downstream users codes... automatically. Yes, every change... and yes, against _user's_ applications that are built using our library (even users located on the other side of the world). Our continuous integration isn't just internal... it's over all our user's applications. Every time the code changes pass against the dozens of downstream applications the system automatically rolls out a "release" (by merging to our "stable" branch). Our users can use the stable branch (and update daily if they like) without fear of it breaking their codes.
We are proud of using a Git hash for our "version". We do it this way because we want the entire community to move forward together... all the time. It's a major issue in computational science when people use old versions of libraries forever. Again, go read the papers.
We run with a full continuous integration cycle... with continuous release. Our software version is whatever the Git hash is. This is for a large computational science library that's in use by hundreds of researchers around the globe.
You can read about some of our software development methodology here:
Although, that's a bit dated now and a newer article has already been accepted by the Journal Of Open Research Software and should be out "real soon now". You can see an early draft of the new paper here:
I wonder if it would be possible for XCode to compute a hash of system libraries / executables that is then embedded into the App binary. Apple could then check this hash against what it should be and reject any app that was compiled with a bogus version of XCode or system libraries.
Might not stop everything... but it could be a start.
In this case the malware was reporting back to a server with lots of details about where it was running... including what app it was buried inside of and then awaited further instruction.
It's definitely conceivable that the authors would send back specific instructions for what to do _in that particular app_... like steal bank account numbers or mess with email...
Use an iPhone. This is the whole reason why Apple disallowed multitasking in the first place (relying instead on external notifications)... then they brought out API's to allow apps to do very specific things in the background (finish a download, play music, etc.). For a long time Apps had huge restrictions on what they could do in the background so that they didn't soak up battery.
Only recently were iPhone Apps allowed "free reign" in the background through a mechanism called "Background App Refresh". And you know what? The ability to do that is directly selectable _per app_ right in the Settings for the phone. No extra "Battery Saver" app needed.
It's funny how many techy people react to this type of thing as Apple being overly restrictive... when in reality the majority of users are appreciative of these restrictions as it gives them an overall better experience.
Or the system is working properly. 80% of people are happy with their thin phones and 20% of people can add battery cases if their needs call for it (numbers pulled out of ass based on seeing people with huge cases that might be battery cases).
Why do the rest of us need to carry around a 4 pound brick when our current thin phone gets us through the day?
My apartment complex has many stations that are always fully stocked with bags: BUT I actually carry and use my own because it's more convenient than using the stations.
Because of the stations it is VERY rare for there to be poop lying around... even though there are TONS of dogs here.
In addition to what turp182 said about not allowing multiple orders it also sends a notification to your phone telling you all about the order... and you receive multiple emails about the progress of that order (just like any Amazon order).
You might be interested in http://jet.com/ . I haven't used it yet (friend just told me about it the other day). But it seems a bit more targeted than Amazon at non-greymarket goods.
(Note: I don't work for them, or with them or anything... simply heard about it the other day and thought I would pass it on)
Definitely a good point about trading lean mass for fat. Something I'll have to keep an eye out for.
I know that in my particular case I've definitely lost some fat mass. My Withings scale keeps track of body fat % as well as weight and I've gone from 23% fat to 19% fat. Which puts me at losing about 12 pounds of fat (0.23*212 - 0.19*193)
But of course, I've lost closer to 20 pounds (currently around 19 pounds)... so it is possible that I've already lost some lean mass as well.
Definitely something to think about as I start to increase my dietary intake a bit... I will need to keep my exercise high to make sure my body doesn't decide to store all those new calories as fat.
I'll provide some anecdotal evidence to back up what you're saying...
A few months ago when the Apple Watch came out I decided to use it to try to lose some pounds. I'm in my early 30's and even though I'm fairly active the pounds had started to pile up to the point where I had a "gut" and I wanted to get rid of it. For the record I weighed in at 212 pounds and I'm a 6'4" male... so I was just a bit beyond the normally recommended weight for my height.
I've watched ALL of my friends go on crazy fad diets complete with kale smoothies and quinoa pancakes. They also always talk about how "terrible" soda is for you. They've all failed pretty miserably after a few weeks.
I decided to take a different route. I just decided to eat what I normally eat... just eat less of it and then use my Apple Watch to motivate me to exercise a little more. In most cases I cut my meals in half... but still ate exactly the same thing I normally do: _including_ having a full can of soda for lunch and dinner (either Coke or Dr. Pepper).
I started out with modest exercise goals of 350 calories a day... but eventually worked my way up to 600 calories per day of exercise where I am now. I didn't join a gym or anything... I just went on long walks with my dog (which had the nice side effect of getting him healthy as well;-)
It's now been just over two months and I've lost _20_ pounds and I'm in better shape than I've been in since high school. I'm actually damn skinny and don't plan on losing any more weight... so I'm decreasing my exercise goals a bit and increasing my eating just a bit and I hope to come into "equilibrium" around 190 pounds... which is fine with me (I don't want to be muscular or anything).
I did all of this while still drinking 2+ sodas a day and eating everything I normally do. All I did differently was have some self-control about how MUCH I ate and got my ass out to do some walking....
Through this whole experience I've done a lot of reading on how our body works to consume, store and burn calories... and I've come to the conclusion that most everything surrounding "dieting" is crack-pottery. It is really hard to find hard evidence that says exactly how our body responds to different stimuli.
For instance, one question I had (since I was doing mostly walking) is: does it matter if you use muscles near fat to burn that fat faster? As it turns out... not for me. Just by walking I was able to remove my gut and love handles and all of the fat off my face and arms. But a lot of the "dogma" out there says you need to "target" fat with specific exercises or you won't be able to get rid of it.
As a scientist myself I just decided to go with conservation of energy. If you eat less calories than you burn (and you do it consistently, every day)... you MUST lose weight... and that seems to be holding true for me;-)
The idea that government coercion is either morally justified or effective in achieving high vaccination rates is wrong.
I don't care to debate you about "morally justified" but you're definitely wrong about "effective in achieving high vaccination rates". It's pretty clear that states with more stringent vaccination requirements have higher vaccination rates:
"In many but not all states, philosophical exemptions are easier to get than religious exemptions, which typically require parents to cite and explain the religious doctrine in question. Overall, states with philosophical exemptions have 2.5 times the rate of opt-outs than states with only religious exemptions."
I led the team that created the MOOSE Framework ( http://www.mooseframework.org/ ) an open source computational science package.
We decided to open source the framework (MOOSE)... and build proprietary (and many open source... depending on the line of funding) computational science apps on top of it. For that reason MOOSE (and everything that surrounds it) uses an LGPL license.
This has allowed us to grow a large community of people all working together to solve coupled systems of PDEs... while also allowing us to have a line of funding in the future (licensing some of our applications).
So... you may want to open source the core components... then use the core components to develop proprietary capabilities that you then sell.
I use Google+... but not for my "main" social network. Google+ is used to keep track of my scientific colleagues. We share science news articles and discuss new papers that have come out, etc. It works really well for that.
Here's how I use the various social networks:
Facebook: Family and friends, normal happenings (all "private") Google+: Scientific / mathematical / coding discussions with scientific colleagues Twitter: Announcements related to my software project. Anything I wish to shout out "publicly" Linked In: Major announcements about my software project. Connections with colleagues and scientific funding agencies. No casual updates (more professional).
For me, each one has its place. I would be sad to see Google+ actually die as my colleagues and I have spent a good deal of time cultivating a community there...
I agree. I'm for some improved regulation to make sure that insurance is in place. But whatever that regulation is... it needs to also allow Uber to exist.
Massachusetts (where I currently live and use Uber) is passing some good regulations to ensure that Uber drivers are properly insured and vetted. Uber is actually happy about the deal because it specifically codifies that Uber is legal.
Slashdot Mirror
Like I mentioned... the actual drawing is NOT the bottleneck (but every little bit helps).
Those images you see on the screens are backed by TB of data that has to be read in and distilled down before being renderable. That's what the thousands of cores are doing.
Also: those rotateable ones you see in the beginning are small. If you skip forward to the 2:30 mark you can see some of the larger stuff (note that we're not interactively rotating it). That movie at 2:30 took 24 hours to render on about 1,000 cores.
Again: The bottleneck was NOT rendering time. It was the time to read TB from disk and crunch the data down to the point where you had a renderable image.
Like I said: raw rasterizing isn't the main bottleneck... reading the data and transforming the data is.... both things better done on the CPU. Drawing frames takes up a very small amount of the overall runtime... but it's always nice to speed it up!
GPUs wouldn't help much in this scenario... and our CPU clusters are used for many things other than visualization.
Yes, we do have some dedicated "viz" clusters as well... but we typically don't use them because they are too small for loading many TB of data.
This is seriously useful for massive scientific visualization... where raw rendering speed isn't always the bottleneck (but of course, faster is better).
We do simulations on supercomputers that generate terabytes of output. You then have to use a smaller cluster (typically 1000-2000 processors) to read that data and generate visualizations of it (using software like Paraview ( http://www.paraview.org/ ) ). Those smaller clusters often don't have any graphics cards on the compute nodes at all... and we currently fall back to Mesa for rendering frames.
If you're interested in what some of these visualizations look like... here's a video of some of our stuff: https://www.youtube.com/watch?...
Look at my reply to the guy above you for a little more detail.
We _do_ actually test every every code change _before_ it enters a "devel" branch (everything flows through tested pull requests). Part of that testing is actually testing against _downstream_ applications (user's applications). Once it's deemed fit to go into "devel" the PR is merged and a new set of automated testing is kicked off... with more extensive testing against all downstream applications. If that passes then a "release" is automatically done by merging to our "stable" branch (which is actually master).
The entire system (other than pressing "Merge" on the PR) is completely automated... allowing us to roll out several releases per day that are guaranteed to work with all of our user's applications. This gives them the freedom to use the very most up to date version of the library (the master branch) without fear.
As for the version "number" it actually doesn't matter... no one talks about "I'm on version 4ce653b488b3f1a3f929caa136f63f7846303967"... the only question is: "Did you update today?"...
BTW: If we make an incompatible API change (which is rare). _WE_ actually put in PR's to all of our downstream user's applications (currently numbering in the hundreds) to fix their applications.
The purpose of all of this (which is talked about in the papers) is to keep the entire community running on the newest code... all the time. It trades support burden (of old versions) for a burden of always passing extremely rigorous tests. We've found it to be a really positive thing and our userbase is continuing to grow because of it.
About that userbase. This is massively-parallel, scientific and engineering software (the kind that runs on the largest supercomputers in the world). Several hundred users is actually pretty great ;-)
Quick to criticize and call names I see.
You obviously didn't even bother a cursory glance at the two papers I pointed to. We spend a LOT of time doing release engineering... we just build it all into an automated system so that we can do multiple "releases" per day.
We actually test every code change against a large set of our downstream users codes... automatically. Yes, every change... and yes, against _user's_ applications that are built using our library (even users located on the other side of the world). Our continuous integration isn't just internal... it's over all our user's applications. Every time the code changes pass against the dozens of downstream applications the system automatically rolls out a "release" (by merging to our "stable" branch). Our users can use the stable branch (and update daily if they like) without fear of it breaking their codes.
We are proud of using a Git hash for our "version". We do it this way because we want the entire community to move forward together... all the time. It's a major issue in computational science when people use old versions of libraries forever. Again, go read the papers.
We run with a full continuous integration cycle... with continuous release. Our software version is whatever the Git hash is. This is for a large computational science library that's in use by hundreds of researchers around the globe.
You can read about some of our software development methodology here:
http://openresearchsoftware.me...
Although, that's a bit dated now and a newer article has already been accepted by the Journal Of Open Research Software and should be out "real soon now". You can see an early draft of the new paper here:
http://figshare.com/articles/C...
Yep - this is what happened. In particular, they were downloading from Baidu... which was much faster than downloading from Apple directly.
I wonder if it would be possible for XCode to compute a hash of system libraries / executables that is then embedded into the App binary. Apple could then check this hash against what it should be and reject any app that was compiled with a bogus version of XCode or system libraries.
Might not stop everything... but it could be a start.
In this case the malware was reporting back to a server with lots of details about where it was running... including what app it was buried inside of and then awaited further instruction.
It's definitely conceivable that the authors would send back specific instructions for what to do _in that particular app_... like steal bank account numbers or mess with email...
Use an iPhone. This is the whole reason why Apple disallowed multitasking in the first place (relying instead on external notifications)... then they brought out API's to allow apps to do very specific things in the background (finish a download, play music, etc.). For a long time Apps had huge restrictions on what they could do in the background so that they didn't soak up battery.
Only recently were iPhone Apps allowed "free reign" in the background through a mechanism called "Background App Refresh". And you know what? The ability to do that is directly selectable _per app_ right in the Settings for the phone. No extra "Battery Saver" app needed.
It's funny how many techy people react to this type of thing as Apple being overly restrictive... when in reality the majority of users are appreciative of these restrictions as it gives them an overall better experience.
Or the system is working properly. 80% of people are happy with their thin phones and 20% of people can add battery cases if their needs call for it (numbers pulled out of ass based on seeing people with huge cases that might be battery cases).
Why do the rest of us need to carry around a 4 pound brick when our current thin phone gets us through the day?
bags are cheap, and there are MANY biodegradable dog bags available (ex: http://www.amazon.com/gp/aw/d/... )
Quit being an ass and pick up after your dog!
My apartment complex has many stations that are always fully stocked with bags: BUT I actually carry and use my own because it's more convenient than using the stations.
Because of the stations it is VERY rare for there to be poop lying around... even though there are TONS of dogs here.
In addition to what turp182 said about not allowing multiple orders it also sends a notification to your phone telling you all about the order... and you receive multiple emails about the progress of that order (just like any Amazon order).
You can even cancel the order within 30 minutes.
You might be interested in http://jet.com/ . I haven't used it yet (friend just told me about it the other day). But it seems a bit more targeted than Amazon at non-greymarket goods.
(Note: I don't work for them, or with them or anything... simply heard about it the other day and thought I would pass it on)
Agreed... projects I work on have been doing this for ages. Here's one of the open source examples:
https://github.com/libMesh/lib...
dynamic_cast with an error statement in DEBUG mode. static_cast otherwise (including if you don't have RTTI).
This is a no brainer...
Interesting. Thanks for the reply!
Definitely a good point about trading lean mass for fat. Something I'll have to keep an eye out for.
I know that in my particular case I've definitely lost some fat mass. My Withings scale keeps track of body fat % as well as weight and I've gone from 23% fat to 19% fat. Which puts me at losing about 12 pounds of fat (0.23*212 - 0.19*193)
But of course, I've lost closer to 20 pounds (currently around 19 pounds)... so it is possible that I've already lost some lean mass as well.
Definitely something to think about as I start to increase my dietary intake a bit... I will need to keep my exercise high to make sure my body doesn't decide to store all those new calories as fat.
Really nice post!
I'll provide some anecdotal evidence to back up what you're saying...
A few months ago when the Apple Watch came out I decided to use it to try to lose some pounds. I'm in my early 30's and even though I'm fairly active the pounds had started to pile up to the point where I had a "gut" and I wanted to get rid of it. For the record I weighed in at 212 pounds and I'm a 6'4" male... so I was just a bit beyond the normally recommended weight for my height.
I've watched ALL of my friends go on crazy fad diets complete with kale smoothies and quinoa pancakes. They also always talk about how "terrible" soda is for you. They've all failed pretty miserably after a few weeks.
I decided to take a different route. I just decided to eat what I normally eat... just eat less of it and then use my Apple Watch to motivate me to exercise a little more. In most cases I cut my meals in half... but still ate exactly the same thing I normally do: _including_ having a full can of soda for lunch and dinner (either Coke or Dr. Pepper).
I started out with modest exercise goals of 350 calories a day... but eventually worked my way up to 600 calories per day of exercise where I am now. I didn't join a gym or anything... I just went on long walks with my dog (which had the nice side effect of getting him healthy as well ;-)
It's now been just over two months and I've lost _20_ pounds and I'm in better shape than I've been in since high school. I'm actually damn skinny and don't plan on losing any more weight... so I'm decreasing my exercise goals a bit and increasing my eating just a bit and I hope to come into "equilibrium" around 190 pounds... which is fine with me (I don't want to be muscular or anything).
I did all of this while still drinking 2+ sodas a day and eating everything I normally do. All I did differently was have some self-control about how MUCH I ate and got my ass out to do some walking....
Through this whole experience I've done a lot of reading on how our body works to consume, store and burn calories... and I've come to the conclusion that most everything surrounding "dieting" is crack-pottery. It is really hard to find hard evidence that says exactly how our body responds to different stimuli.
For instance, one question I had (since I was doing mostly walking) is: does it matter if you use muscles near fat to burn that fat faster? As it turns out... not for me. Just by walking I was able to remove my gut and love handles and all of the fat off my face and arms. But a lot of the "dogma" out there says you need to "target" fat with specific exercises or you won't be able to get rid of it.
As a scientist myself I just decided to go with conservation of energy. If you eat less calories than you burn (and you do it consistently, every day)... you MUST lose weight... and that seems to be holding true for me ;-)
I don't care to debate you about "morally justified" but you're definitely wrong about "effective in achieving high vaccination rates". It's pretty clear that states with more stringent vaccination requirements have higher vaccination rates:
http://www.pewtrusts.org/en/re...
"In many but not all states, philosophical exemptions are easier to get than religious exemptions, which typically require parents to cite and explain the religious doctrine in question. Overall, states with philosophical exemptions have 2.5 times the rate of opt-outs than states with only religious exemptions."
I led the team that created the MOOSE Framework ( http://www.mooseframework.org/ ) an open source computational science package.
We decided to open source the framework (MOOSE)... and build proprietary (and many open source... depending on the line of funding) computational science apps on top of it. For that reason MOOSE (and everything that surrounds it) uses an LGPL license.
This has allowed us to grow a large community of people all working together to solve coupled systems of PDEs... while also allowing us to have a line of funding in the future (licensing some of our applications).
So... you may want to open source the core components... then use the core components to develop proprietary capabilities that you then sell.
Just an option...
I use Google+... but not for my "main" social network. Google+ is used to keep track of my scientific colleagues. We share science news articles and discuss new papers that have come out, etc. It works really well for that.
Here's how I use the various social networks:
Facebook: Family and friends, normal happenings (all "private")
Google+: Scientific / mathematical / coding discussions with scientific colleagues
Twitter: Announcements related to my software project. Anything I wish to shout out "publicly"
Linked In: Major announcements about my software project. Connections with colleagues and scientific funding agencies. No casual updates (more professional).
For me, each one has its place. I would be sad to see Google+ actually die as my colleagues and I have spent a good deal of time cultivating a community there...
I wanted to run this on my own GitHub hosted project. But the "article" has nothing but a huge link to a LICENSE and README file.
Bummer.
I would say that _that_ person could then sign up for extra tracking if they want to avoid the tax.
No reason to track everyone... only the outliers..
Sigh - I was just using the words "ride sharing" because it was convenient. The bill cover "ride hailing" services.
Or whatever you want to call them...
I agree. I'm for some improved regulation to make sure that insurance is in place. But whatever that regulation is... it needs to also allow Uber to exist.
Massachusetts (where I currently live and use Uber) is passing some good regulations to ensure that Uber drivers are properly insured and vetted. Uber is actually happy about the deal because it specifically codifies that Uber is legal.
Both sides win.
And who lobbies the government to set the fares as high as possible?
Competition is a much better way to set taxi fares. But for that to work there has to be a free-market... which Uber is bringing.