Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
What's the story with these ads on Slashdot? Check out our new blog post to find out. ×

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

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

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

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

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

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

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

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.

Comment Could have said the same about phones in 2006... (Score 1) 417

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

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

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

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.
 

Comment Re:This guy has a better idea (Score 2) 221

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.

Comment Re:This guy has a better idea (Score 3, Informative) 221

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.

panic: kernel trap (ignored)

Working...