Follow Slashdot stories on Twitter


Forgot your password?
Slashdot Deals: Deal of the Day - 6 month subscription of Pandora One at 46% off. ×

Comment Re:How gracefully does it fail? (Score 1) 147

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).

Comment Re:Why? (Score 1) 182

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?

Comment Re:Why? (Score 1) 182

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.

Comment Re:Not the only factor? (Score 1) 324

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 :)

Comment Re:Core code in C/C++. UI code in Obj-C, Swift, Ja (Score 1) 84

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.

Comment Re:Core code in C/C++. UI code in Obj-C, Swift, Ja (Score 1) 84

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? :)

Comment Re:Core code in C/C++. UI code in Obj-C, Swift, Ja (Score 1) 84

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.

Comment Re:Core code in C/C++. UI code in Obj-C, Swift, Ja (Score 1) 84

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.

Comment Re:Core code in C/C++. UI code in Obj-C, Swift, Ja (Score 0) 84

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.


Comment Re:Willl any of this affect Swift performance? (Score 2) 84

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.

Comment Re:We the taxayer get screwed. (Score 5, Insightful) 356

and they go out of their way to hire veterans:

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:

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).


Comment Transitional work as "co-pilots"... (Score 1) 615

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.

To do two things at once is to do neither. -- Publilius Syrus