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
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
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.
... what a series.
It's not so hard to lift yourself by your bootstraps once you're off the ground. -- Daniel B. Luten
