This just in: "Retiring" things that we build someday may have unspecified costs associated. I guess we shouldn't build anything. Oh, wait, unless maybe it gives us free energy literally from the wind for generations... maybe that reason.
When some future iPhone is hermetically sealed in sapphire are you going to complain because you can't repair it? How about when the case it formed using liquid metal technology and there are no seams to open?
Can you repair the CPU in your desktop? No? You mean you throw away a two billion transistor machine because one NAND gate is bad? Why don't you get in there and repair it? Or more to the point why aren't you bitching about Intel conspiring to keep you from fixing it by sealing the CPU case and not using TO-92 sockets so you can pop them out?
Our kids aren't going to be repairing this stuff - they are going to be 3D printing a new one and hopefully properly recycling the old one.
Interesting note on this point - The Tesla battery has a special "intumescent" material coating the (~7000) battery cells comprising the car battery pack that responds to overheating by expanding and isolating the affected cells. So it essentially has a built in firewall between each of the thousands of component cells that tries to block off overheating or damaged ones from the rest of the pack. It's kind of like having 7000 tiny gas tanks inside the gas tank that each offer some protection against rupture and fire. (Cue Futurama "6000 hulls" joke).
Really? The point was mainly for emphasis but... You've never had a connecting flight late where you need to run to a gate or a situation where a flight was moved to another terminal randomly? You can't imagine a situation where not being able to use your phone quickly to check gates or missing an update in this situation and not realizing why would be a problem?
Exactly. Every time I go to the airport I wonder why my phone isn't working and then I realize it's joined a pay wifi that I used years ago. It's a great way to miss your flight.
I am wondering if Apple has some limits built in to the wifi assist. I was hoping the article had tested that but instead it's just speculation without any real information.
Exactly. And guess who knows exactly how many of those people there are out there? Apple. I find it weird that people complain about the existence of a low end device, even if they think it's not good enough. It's just a weird thing to complain about. It makes me think it's stoked by flash manufacturers or something:)
Try to write some business logic which crunches 100 millions entities, and then come back. Or networking application which serves 10K+/s requests in real-time. But why go so far - an Eclipse-like text editor without C, in pure Java. All that is routinely done in C/C++ - and still generally fails in Java. I know it, because I have tried.
Ok, first - you know that Eclipse is written in Java don't you?:)
Beyond that - a) The biggest financial institutions in the world use Java to crunch numbers on larger sets of entities than that every day (I have written some of these systems). b) Tomcat is a pure Java application server and it can easily scale to 10k/requests per second on a reasonable server... and c) The best IDE in the world, jetbrains IDEA, is pure Java and I use it every day.
I don't know why this thread has become a bash-Java thread but it's filled with a lot of outdated information.
The general advice for writing games in Java is avoid creating temporary objects - use long lived objects, don't create objects in the scope of a loop,..
Exactly. And the problem with Swift / ARC as compared to Java / GC is that the Swift compiler has no idea how long-lived objects are and so it has to do this super paranoid retain/release every time any reference type is touched. What is basically free in Java (referencing long lived objects on the heap) is relatively costly in Swift or Objc with ARC. At minimum this is unexpected behavior for most people and makes writing high performance code in Swift awkward right now.
What I would desperately love is simply a flag to turn off ARC for a given Swift compilation unit just like there is for objc... Or perhaps a class level annotation that says: "this reference type is long-lived / strongly referenced and you don't need to worry about it".
I've gone so far as to write some experimental code to fiddle with the mach-o object code that swiftc generates and *remove* all of the retain/release calls. (I just turn the callqs into noops and fix up the relocation table). This actually works believe it or not, at least for simple tests and makes the swift code as fast as one would expect of optimized C... But it blows up in more complex situations and I don't know if it's worth really spending time to figure out why... since it's madness anyway and I have to assume the situation will improve eventually on its own.
Does anyone know anybody on the Swift team at Apple?:)
No, you could not because modern objective-c for Mac OS and iOS has ARC retain/release just like Swift. ARC is not specific to Swift.
Yes, I could because Objective-C has a lovely switch called -fno-objc-arc that would allow me to decide in a chunk of code by chunk of code basis where ARC was acceptable and where it was not.
As for your other comments without getting into particular examples this isn't very productive. My original question again was about whether there is anything in the latest clang that might help Swift.
Ok, first, those articles are about statically compiled C/C++ and in particular targeting game systems that only support those types of applications. Runtime platforms like Java and.NET can do things do optimizations that those cannot like optimistically inlining methods where there is not enough information to prove that they never need dynamic dispatch, and making memory management for short live objects almost free by putting them on special parts of the heap.
But to take a step back - yes, it's usually possible to rewrite your app to sacrifice some readability to make it faster. I mentioned in my OP that I could rewrite my Swift app to use more structs and get rid of the reference types and it would probably meet my perf requirements... but it would be at least somewhat uglier and harder to maintain. Harder to maintain = bugs and lack of insight that might allow you to make bigger breakthroughs in perf later.
I'm not quite sure what the argument here is - We all want to use the most appropriate tool for the job. My original question was about whether these Clang changes might help improve Swift performance, which I believe is currently (ok, let's not say "crippled") hampered by excessive ARC calls.
That hasn't been productive advice since about 1998:) Modern languages with runtimes like Java, C# (and presumably Swift when it gets its act together) can actually be *faster* than C/C++ in some cases because they have more optimization information at runtime than exists statically at compile time. In particular garbage collection in Java is just about optimal and you really can't beat it with hand crafted memory management. I assume that the ARC people have some plan for how to eliminate the overhead for special cases like this eventually, but they just aren't there yet.
More generally - yes, I could just rewrite my entire app in objc or C/C++ to work around the current problems with Swift but then I'd have 25k lines of ugly code instead of 10k lines of pretty code that I actually want to maintain and work on:)
More useful advice might be to rewrite the *parts* of the application that are slow today in objc or C/C++, which would normally be a good option as swift interoperates with them fine... but in my case is awkward.
I'm talking mostly about high performance numerical computing, games, etc. Right now if you look at the object code generated by swift you'll see that even a trivial method call may generate dozens of retain/release calls on seemingly innocuous code. ARC is fine for most things but you pay a small penalty for it ever time you reference or pass a reference to an object... as opposed to a garbage collected language (e.g. Java) where you expect referencing long lived objects to be essentially free, pointer operations. Right now the only way to write high performance code in Swift is to essentially abandon classes and work only with structs. And the built in types suffer indirectly from things like retain/release unwrapping Optional types, etc. Here's a stackoverflow link to an example (Swift's dictionary is something like 25x slower than Java's right now).
I found that a straightforward port of my application from Java to Swift was spending 90% of its time in retain release calls, which is what got me deep into this.
BTW, if anyone knows of a good forum where people are talking about this type of thing I'd appreciate a reference.
Swift is currently crippled in performance by the requirement to use ARC (at least code that actually uses reference types). Just wondering if anything new in this might affect that.
Most drivers have never experienced a car where tech makes the driving experience better, safer, and *less* cluttered and attention taking. Wait till most people have driven a Tesla or a future Apple car and see if they would choose to go back.
And they doing their best to insure that most of the battery production in the world will be done in the U.S. in the future: http://www.teslamotors.com/gig...
And oh by the way they are the future of the car industry... and perhaps getting the U.S. energy independent in a sustainable way...
But yah, let's bitch about giving them tax breaks... because we need to save those for more worthy industries (sarcasm).
What if we solve two problems at the same time by legislating that for some number of years self driving rigs have to have human co-pilots aboard (bear with me)... We'd still get most of the benefits of improved safety and 24 hour schedules and the humans could even do other work while on-board but they'd ostensibly be there to monitor the rig and take over in crazy situations (e.g. flat tire, fire, unexpected weather).
The flip side is that the public gets a (somewhat irrational but real) feeling of safety knowing that humans are on board... in the same way that I feel better about flying in a mostly auto-piloted aircraft because I know two people fully trained in the systems are trusting their lives to it.
So truck drivers turn into truck co-pilots for a few years, get an easier / safer job, and some of them retire during that time while we all get used to self-driving trucks on the road.
A year ago they were slowing work on AngularJS to put more effort into a complete rewrite with AngularDart. Dart is a better language than TypeScript and it's a Google creation... I have no idea why they did this.
The Tesla is fine in the cold (it's the most popular car in Norway). My point was just that there is lower hanging fruit to be had in terms of increasing car efficiency (another one is getting rid of side mirrors for aerodynamics) than waste heat in tires... I tend to agree with other posters that the tire heat thing sounds like nonsense.
This is actually relevant to the OP because the biggest bang for the buck in capturing wasted energy in modern electric cars like the Tesla is the inability to do full regenerative braking in the winter when the battery is too cold to receive the full charge rate. When the temperature is low regen braking in the Tesla is limited (ranging from almost nothing up to the full 60kW) based on how cold the battery is. The car actually makes strategic decisions about when to spend power to *heat* the battery because the energy put into warming the (large) battery mass will at some point be more than outweighed by the gains in regen braking recouped energy.
It must be very frustrating for the Tesla engineers to have a 60kW "free" energy source and limit it because the batteries can't take the charge rate. It seems naively like that energy could be put directly into heating the battery, but I'm sure there are a lot of engineering issues (you probably can't just dump 60kW into a point heating source, etc.)
So, solving *that* problem would probably make Teslas 20% more efficient than they are now in the winter... and that would add up to a *lot* of energy.
The first thing they need to do is start calling it a body transplant, not a head transplant. The living person got a new body, the dead person did not get a new head.
It's a reflex - Those of us who live through the 90's haven't quite gotten over how Microsoft screwed over the world and tried to kill the Web in its infancy. Do you like HTML5? Well, we could have had the modern web ~20 years ago if Microsoft hadn't deliberately set out to destroy it by licensing Java and making sure a slightly incompatible, outdated version of it was on every desktop for a decade. They spent a billion dollars to create IE and drive Netscape out of business. During the DOJ lawsuit in 1998 they produced emails with people literally talking about how they had to "pollute Java" in order to ruin cross-platform apps and web browsers that threatened their desktop business model. I don't think most programmers who have grown up with JavaScript have any idea that it was designed as an afterthought - to be a glue language to bind HTML to Java applications and Java based browsers with real application and security models.
I am happy the Microsoft is turning over a new leaf and like C#, but I'm waiting for a big apology...
I did not realize until just now that Office Depot and Office Max had merged (or were always the same to begin with). So we are left with one major office outlet... Does competition work in any industry anymore?
In a normal hydraulic system there is a pump that re-pressurizes and returns the hydraulic fluid to a reservoir. To save weight and complexity here since the hydraulics are only used for a few minutes they instead use an "open" hydraulic system in which the pressure comes from a tank of compressed gas and the hydraulic fluid is expelled or burned up as it is used. (The fluid goes one way - out - as it is used).
After the pressurized gas or fluid was used up they no longer had control over the fins.
Slashdot Mirror
This just in: "Retiring" things that we build someday may have unspecified costs associated. I guess we shouldn't build anything. Oh, wait, unless maybe it gives us free energy literally from the wind for generations... maybe that reason.
Isn't there enough tech stuff to talk about?
When some future iPhone is hermetically sealed in sapphire are you going to complain because you can't repair it?
How about when the case it formed using liquid metal technology and there are no seams to open?
Can you repair the CPU in your desktop? No? You mean you throw away a two billion transistor machine because one NAND gate is bad? Why don't you get in there and repair it? Or more to the point why aren't you bitching about Intel conspiring to keep you from fixing it by sealing the CPU case and not using TO-92 sockets so you can pop them out?
Our kids aren't going to be repairing this stuff - they are going to be 3D printing a new one and hopefully properly recycling the old one.
Interesting note on this point - The Tesla battery has a special "intumescent" material coating the (~7000) battery cells comprising the car battery pack that responds to overheating by expanding and isolating the affected cells. So it essentially has a built in firewall between each of the thousands of component cells that tries to block off overheating or damaged ones from the rest of the pack. It's kind of like having 7000 tiny gas tanks inside the gas tank that each offer some protection against rupture and fire. (Cue Futurama "6000 hulls" joke).
Really? The point was mainly for emphasis but... You've never had a connecting flight late where you need to run to a gate or a situation where a flight was moved to another terminal randomly? You can't imagine a situation where not being able to use your phone quickly to check gates or missing an update in this situation and not realizing why would be a problem?
So, point taken, but... why?
Exactly. Every time I go to the airport I wonder why my phone isn't working and then I realize it's joined a pay wifi that I used years ago. It's a great way to miss your flight.
I am wondering if Apple has some limits built in to the wifi assist. I was hoping the article had tested that but instead it's just speculation without any real information.
Exactly. And guess who knows exactly how many of those people there are out there? Apple. :)
I find it weird that people complain about the existence of a low end device, even if they think it's not good enough. It's just a weird thing to complain about. It makes me think it's stoked by flash manufacturers or something
Try to write some business logic which crunches 100 millions entities, and then come back. Or networking application which serves 10K+/s requests in real-time. But why go so far - an Eclipse-like text editor without C, in pure Java. All that is routinely done in C/C++ - and still generally fails in Java. I know it, because I have tried.
Ok, first - you know that Eclipse is written in Java don't you? :)
Beyond that - a) The biggest financial institutions in the world use Java to crunch numbers on larger sets of entities than that every day (I have written some of these systems). b) Tomcat is a pure Java application server and it can easily scale to 10k/requests per second on a reasonable server... and c) The best IDE in the world, jetbrains IDEA, is pure Java and I use it every day.
I don't know why this thread has become a bash-Java thread but it's filled with a lot of outdated information.
The general advice for writing games in Java is avoid creating temporary objects - use long lived objects, don't create objects in the scope of a loop,..
Exactly. And the problem with Swift / ARC as compared to Java / GC is that the Swift compiler has no idea how long-lived objects are and so it has to do this super paranoid retain/release every time any reference type is touched. What is basically free in Java (referencing long lived objects on the heap) is relatively costly in Swift or Objc with ARC. At minimum this is unexpected behavior for most people and makes writing high performance code in Swift awkward right now.
What I would desperately love is simply a flag to turn off ARC for a given Swift compilation unit just like there is for objc... Or perhaps a class level annotation that says: "this reference type is long-lived / strongly referenced and you don't need to worry about it".
I've gone so far as to write some experimental code to fiddle with the mach-o object code that swiftc generates and *remove* all of the retain/release calls. (I just turn the callqs into noops and fix up the relocation table). This actually works believe it or not, at least for simple tests and makes the swift code as fast as one would expect of optimized C... But it blows up in more complex situations and I don't know if it's worth really spending time to figure out why... since it's madness anyway and I have to assume the situation will improve eventually on its own.
Does anyone know anybody on the Swift team at Apple? :)
No, you could not because modern objective-c for Mac OS and iOS has ARC retain/release just like Swift. ARC is not specific to Swift.
Yes, I could because Objective-C has a lovely switch called -fno-objc-arc that would allow me to decide in a chunk of code by chunk of code basis where ARC was acceptable and where it was not.
As for your other comments without getting into particular examples this isn't very productive. My original question again was about whether there is anything in the latest clang that might help Swift.
Ok, first, those articles are about statically compiled C/C++ and in particular targeting game systems that only support those types of applications. Runtime platforms like Java and .NET can do things do optimizations that those cannot like optimistically inlining methods where there is not enough information to prove that they never need dynamic dispatch, and making memory management for short live objects almost free by putting them on special parts of the heap.
But to take a step back - yes, it's usually possible to rewrite your app to sacrifice some readability to make it faster. I mentioned in my OP that I could rewrite my Swift app to use more structs and get rid of the reference types and it would probably meet my perf requirements... but it would be at least somewhat uglier and harder to maintain. Harder to maintain = bugs and lack of insight that might allow you to make bigger breakthroughs in perf later.
I'm not quite sure what the argument here is - We all want to use the most appropriate tool for the job. My original question was about whether these Clang changes might help improve Swift performance, which I believe is currently (ok, let's not say "crippled") hampered by excessive ARC calls.
That hasn't been productive advice since about 1998 :) Modern languages with runtimes like Java, C# (and presumably Swift when it gets its act together) can actually be *faster* than C/C++ in some cases because they have more optimization information at runtime than exists statically at compile time. In particular garbage collection in Java is just about optimal and you really can't beat it with hand crafted memory management. I assume that the ARC people have some plan for how to eliminate the overhead for special cases like this eventually, but they just aren't there yet.
More generally - yes, I could just rewrite my entire app in objc or C/C++ to work around the current problems with Swift but then I'd have 25k lines of ugly code instead of 10k lines of pretty code that I actually want to maintain and work on :)
More useful advice might be to rewrite the *parts* of the application that are slow today in objc or C/C++, which would normally be a good option as swift interoperates with them fine... but in my case is awkward.
Pat
I'm talking mostly about high performance numerical computing, games, etc. Right now if you look at the object code generated by swift you'll see that even a trivial method call may generate dozens of retain/release calls on seemingly innocuous code. ARC is fine for most things but you pay a small penalty for it ever time you reference or pass a reference to an object... as opposed to a garbage collected language (e.g. Java) where you expect referencing long lived objects to be essentially free, pointer operations. Right now the only way to write high performance code in Swift is to essentially abandon classes and work only with structs. And the built in types suffer indirectly from things like retain/release unwrapping Optional types, etc. Here's a stackoverflow link to an example (Swift's dictionary is something like 25x slower than Java's right now).
e.g. http://stackoverflow.com/quest...
I found that a straightforward port of my application from Java to Swift was spending 90% of its time in retain release calls, which is what got me deep into this.
BTW, if anyone knows of a good forum where people are talking about this type of thing I'd appreciate a reference.
Swift is currently crippled in performance by the requirement to use ARC (at least code that actually uses reference types). Just wondering if anything new in this might affect that.
Most drivers have never experienced a car where tech makes the driving experience better, safer, and *less* cluttered and attention taking. Wait till most people have driven a Tesla or a future Apple car and see if they would choose to go back.
Pat
and they go out of their way to hire veterans: http://www.military.com/vetera...
And they doing their best to insure that most of the battery production in the world will be done in the U.S. in the future: http://www.teslamotors.com/gig...
And oh by the way they are the future of the car industry... and perhaps getting the U.S. energy independent in a sustainable way...
But yah, let's bitch about giving them tax breaks... because we need to save those for more worthy industries (sarcasm).
Pat
What if we solve two problems at the same time by legislating that for some number of years self driving rigs have to have human co-pilots aboard (bear with me)... We'd still get most of the benefits of improved safety and 24 hour schedules and the humans could even do other work while on-board but they'd ostensibly be there to monitor the rig and take over in crazy situations (e.g. flat tire, fire, unexpected weather).
The flip side is that the public gets a (somewhat irrational but real) feeling of safety knowing that humans are on board... in the same way that I feel better about flying in a mostly auto-piloted aircraft because I know two people fully trained in the systems are trusting their lives to it.
So truck drivers turn into truck co-pilots for a few years, get an easier / safer job, and some of them retire during that time while we all get used to self-driving trucks on the road.
I find the idea of drawing blood that way a lot more unsettling than a pin prick, but I guess if you have a phobia about needles...
A year ago they were slowing work on AngularJS to put more effort into a complete rewrite with AngularDart.
Dart is a better language than TypeScript and it's a Google creation... I have no idea why they did this.
The Tesla is fine in the cold (it's the most popular car in Norway). My point was just that there is lower hanging fruit to be had in terms of increasing car efficiency (another one is getting rid of side mirrors for aerodynamics) than waste heat in tires... I tend to agree with other posters that the tire heat thing sounds like nonsense.
This is actually relevant to the OP because the biggest bang for the buck in capturing wasted energy in modern electric cars like the Tesla is the inability to do full regenerative braking in the winter when the battery is too cold to receive the full charge rate. When the temperature is low regen braking in the Tesla is limited (ranging from almost nothing up to the full 60kW) based on how cold the battery is. The car actually makes strategic decisions about when to spend power to *heat* the battery because the energy put into warming the (large) battery mass will at some point be more than outweighed by the gains in regen braking recouped energy.
It must be very frustrating for the Tesla engineers to have a 60kW "free" energy source and limit it because the batteries can't take the charge rate. It seems naively like that energy could be put directly into heating the battery, but I'm sure there are a lot of engineering issues (you probably can't just dump 60kW into a point heating source, etc.)
So, solving *that* problem would probably make Teslas 20% more efficient than they are now in the winter... and that would add up to a *lot* of energy.
The first thing they need to do is start calling it a body transplant, not a head transplant. The living person got a new body, the dead person did not get a new head.
Pat
It's a reflex - Those of us who live through the 90's haven't quite gotten over how Microsoft screwed over the world and tried to kill the Web in its infancy. Do you like HTML5? Well, we could have had the modern web ~20 years ago if Microsoft hadn't deliberately set out to destroy it by licensing Java and making sure a slightly incompatible, outdated version of it was on every desktop for a decade. They spent a billion dollars to create IE and drive Netscape out of business. During the DOJ lawsuit in 1998 they produced emails with people literally talking about how they had to "pollute Java" in order to ruin cross-platform apps and web browsers that threatened their desktop business model. I don't think most programmers who have grown up with JavaScript have any idea that it was designed as an afterthought - to be a glue language to bind HTML to Java applications and Java based browsers with real application and security models.
I am happy the Microsoft is turning over a new leaf and like C#, but I'm waiting for a big apology...
I did not realize until just now that Office Depot and Office Max had merged (or were always the same to begin with).
So we are left with one major office outlet... Does competition work in any industry anymore?
Pat
In a normal hydraulic system there is a pump that re-pressurizes and returns the hydraulic fluid to a reservoir. To save weight and complexity here since the hydraulics are only used for a few minutes they instead use an "open" hydraulic system in which the pressure comes from a tank of compressed gas and the hydraulic fluid is expelled or burned up as it is used. (The fluid goes one way - out - as it is used).
After the pressurized gas or fluid was used up they no longer had control over the fins.