Since the cocoa libaries (Foundation, UIKit, CoreData etc.) are written in Objective-C and not converted to Swift (yet?) do we still get the performance benefits which Swift offers, when calling these cocoa libaries in Swift vs. using the libaries along with Objective-C (which has been the case until now)?
Erm...
The system frameworks are the system frameworks. They will perform the same regardless of which language they are called from.
Apple has millions of lines of code in their frameworks. (probably hundreds of millions of lines.) I doubt if they are going to be mass-converting all those frameworks to Swift. Instead, as they update and expand their frameworks, they will probably use Swift rather than Objective C where it's appropriate, and then provide interfaces for both languages. The transition in Apple's code is likely to be limited to new APIs and/or APIs where they are doing a major overhaul for some other reason.
When you look at the performance of an app, it usually boils down to a small amount of code that is the bottleneck and takes the bulk of the time. Optimizing other parts of your program have very little effect.
If your program winds up spending most of it's time in application frameworks, then it doesn't matter if it's written in Objective C, Swift, native assembler, or Java.
Personally, I am very skeptical of Apple's claims of huge performance benefits from Swift. I suspect that their comparisons deliberately picked problems that have very bad performance characteristics when written in "pure" Objective-C (ignoring the fact that Objective-C is a true superset of C, and you can always write C code in an Objective-C program.)
I am an old assembler jockey, and a C programmer after that. When I do application design, I avoid creating objects that represent tiny atoms of data, minimize memory allocations in tight loops, and will even sometimes write critical code using C functions rather than Objective-C method calls. I already optimize my design and implementation with an awareness of what slows programs down. I would hazard a bet that with this approach, the difference between Swift and Objective-C code is small. If we have less control in Swift over what is an object and what is a simple array of scalar values, I would expect careful coding would still yield better performance with a mix of C and Objective-C.
Another point is that usually your algorithms make much more difference than your implementation. If you use a bubble sort on a million records, it's gonna be dog-slow even if you write the slickest, most highly optimized implementation of a bubble sort.
Example:
Our company has a Mac program, FractalWorks, (link) in the Mac App store. It is a very high performance fractal renderer. Internally, it allocates a block of memory to store results, and then uses carefully crafted C code to do the number-crunching. It is multi-threaded, and keeps every core on your Mac "maxed out" until the calculations are done. When possible, it also uses knowledge of the geometry of Mandelbrot and Julia sets to use a "boundary following" algorithm, and traces the outside of regions that have the same "iteration value", and then flood-fills the whole region, thus often saving millions or even billions of expensive floating-point calculations. The first part, using memory buffers and C code to calculate results, is implementation optimization. The second bit, the boundary following algorithm, is an algorithm optimization, and for problems where it's a good fit, it can reduce the number of calculations by 5X or even 10X.
Related
There's something else to keep in mind: while Erlang does some things very well, it's technically still possible to get the same results from other languages. The opposite is also true; evaluate each problem as it needs to be, and choose the right tool according to the problem being addressed. Erlang is no silver bullet and will be particularly bad at things like image and signal processing, operating system device drivers, etc. and will shine at things like large software for server use (i.e.: queues, map-reduce), doing some lifting coupled with other languages, higher-level protocol implementation
I'm learning Erlang and this link (http://learnyousomeerlang.com/introduction#kool-aid) got me curious of the reasoning of good vs bad applications for Erlang. Can anyone expound on this statement?
Why do Erlang excel at some of the aformentioned fields and not in the others?
while Erlang does some things very well, it's technically still possible to get the same results from other languages
Lets face it, really all programming languages can do more or less everything, and have ways to interface to C libraries to access anything they don't as such have a native library for.
The most obvious thing to point out is that all of Erlang boils down to C at the end of the day, and a little bit of assembler, but that's not really relevant to the point.
Thus it should be clear enough that anything you can write in Erlang could be written in C, and because you are eliminating a layer of abstraction and interpretation, if you do a reasonable job of it, it should be faster. Sometimes a little faster. Sometimes a lot faster.
Erlang is no silver bullet and will be particularly bad at things like image and signal processing, operating system device drivers, etc.
This is the arena of nitty gritty byte and bit shifting magic, and if you introduce an abstraction layer for every bit you shift... you can easily end up degrading the best possible achievable performance by multiple orders of magnitude.
and will shine at things like large software for server use (i.e.: queues, map-reduce), doing some lifting coupled with other languages, higher-level protocol implementation
This is the interesting bit. We've already established that if you write it in C, unless you do a sufficiently poor job of it, the result can only be better in terms of performance.
BUT performance isn't everything. In today’s world CPU and memory is cheap, but time to market is hugely important. A company might spend thousands on some extra hardware required to run your application because it's written in Erlang instead of C, but save (or make) millions because the product is first to market.
The fact is, if you match a given software problem to a high level language with the right paradigm, the average software engineer can often produce a given product many MANY times faster than if they had to write it in C.
Also, writing C is error prone, and provides vastly more scope for making mistakes and poor choices. That means a software engineer might write something in C badly enough that the equivalent Erlang, based on some very finely tuned mature clever C, if the Erlang itself is well through out, it might perform better!
evaluate each problem as it needs to be, and choose the right tool according to the problem being addressed
Erlang is a really great tool, generally, but it does suit some problem domains more than others. There are some problems which might just be better solved with perl for example, or C, python, etc. When it fits the problem domain, Erlang can be unbeatable, but if it's a bad fit, it's definitely best to consider something else.
Both Erlang and C are Turing complete (except for the lack of infinite memory) and thus both can be used to compute anything if you don't care about absolute performance or the amount of memory or other system resources used.
In systems with constrained memory (tinyDuino, et.al.), the language runtime footprint (and OS resources required to support that runtime) may be a differentiator. For problems where every multiply-accumulate per second counts (affects total cost in MegaWatt-days of power or microseconds of latency), any extra type or value checks, copies, or conversions, which might be implicit in the formal language definition, might incur an added performance cost in processor cycles, cache misses, or run-time memory management. A C program might be specified without much of the above overhead for certain types of applications. However, in applications which require such overhead for a robust solution, that performance advantage disappears as compared against the expected human cost of coding an equivalent (or more) robust solution.
Erlang is a good solution when you want to create:
Realtime Systems: They need predictable response time and Erlang preemptive scheduling and per process garbage collection features shine in it.
Distributed Systems: Erlang has out of box mechanisms for distribution and a standard protocol which is called Erlang Distributed Protocol.
Fault Tolerant Systems: The light-weight processes of Erlang which lets a process to crash without making other processes crash, and its mechanisms for processes to supervise and monitor each other is suitable for fault tolerant systems.
Concurrent Systems: Although writing a concurrent system in languages like C and Java is possible, it can be hard and error prone. But Erlang has internal primitives that makes it so easy to write a concurrent program.
Erlang is not a good choice when you need to write a program that has to do number crunching, image processing and such things because your Erlang codes runs above some layers of abstraction. However there are official mechanisms in Erlang for taking the advantage of C performance. Also Hipe (High Performance Erlang) project is worth considering.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am doing some research on Swift and its differences with Objective-C. From what I could gather, the current version of Swift is quite fast, faster even than Objective-C: see here.
However, since most of these tests are done with sorting algorithms and such, I am wondering if Swift will actually be faster than Objective-C when it is used for development of iOS apps. Can anyone enlighten me on this, preferably from their own experience.
Swift is claimed by Apple to be faster than Objective-C, and as you said it is faster in those sorting algorithms, but for the usage of iOS development, a simple user would not recognize the difference between an app developed in Swift or Objective-C. I developed a lot of apps in Objective-C that are in apple store, and now several in Swift and so far users can not tell the difference if one is much faster than the other.
Swift is unlikely to result in applications that run much faster than applications developed in Objective-C. Even though the two languages are quit different, both target the same Cocoa and Cocoa Touch APIs, iOS and OS X a, both are statically typed languages and both use the same LLVM compiler, so they are not that different after all. There will be performance differences, as the two languages aren't identical after all, but don't expect significant differences.
Swift is also developed from Apple to appeal to new programmers because it is similar to languages such as Ruby and Python than it is Objective-C.
There is a great blog-post about the improvement of Swift performance especially after the Swift 1.2 release.
The author ran several tests with different kind of code like Objc-like Swift code, Swift only and Objective-c only code. And the result was, that Swift 1.2 is much faster than before. He ran tests with JSON so it's a bit more practical than just algorithms.
Beside the 'real' performance, my personal experience about that is, that I'm developing much easier in Swift. I never liked the .h and .m files from Objective-C because it stopped the 'flow of programming'. Also I think the Syntax itself is much easier than in objective-c [with these brackets].
So I think, if you write a new Project from Scratch, Swift is much easier, faster and more elegant. (My opinion)
You can write slow code in any language and Swift is no exception. I haven't had time to fully evaluate the Swift 1.2 Beta but even before most code could be made reasonably fast but it was also very easy to make it very slow. Accessing non-final instance methods especially was very slow and Debug builds were horrifically slow (I have several cases of 100x slower than release builds). A little work to optimise the most deeply nested loops was usually enough to quickly get it somewhere close to C performance.
Most of the code you write is not that performance critical provided you can move slow operations off the main UI queue. More time will be spent in API calls and those will not be affected by the language used to call them. Even where performance is critical the amount of code that needs to be heavily optimised will tend to be small and you could switch to a faster language (e.g. C) for just those parts.
When comparing the Objective-C it is also worth considering what we mean by Objective-C. You can write C functions in Objective-C code and they will result in code as fast as C. I would say that they were C and that to meaningfully talk about Objective-C performance it should be code based on Objective-C message sending and probably NSArrays rather than raw C arrays. If that is the basis Swift (when optimised and using structs and final classes) will come out quite well. However if you are comparing with C code it will usually be the case that Swift will be slower at the moment.
I have a few blog posts about optimising Swift on my blog and I gave a short talk back in October.
Swift comparing to Objective-C has its own benefits like: Swift handles strings more easily, swift tuples offer compound variables, and furthermore, coders don't need to spend time annotating variables with type information and risk making mistakes; in most cases, the compiler can infer the type from the value that a variable is being set with.
Swift is faster compare to Objective-C; that's what Apple's Swift team claims, and it is certainly true. However, the fact is that you have to plan many things in order to write the responsive apps. Here are a few pointers:
Remove unused resources
Optimize resources for ex images
Caching
Compression
Reusable code
Object life management
Unfortunately, due to .NET's lack of an incremental GC (either in the MS or Mono implementation), building soft real-time software such as games with F# is problematic. I've written a language in F# that, if -
a) it doesn't perform adequately in the face of the generational GC (arbitrary pauses during the interactive simulation, and
b) OCaml gets a good complete port to the LLVM backend -
I will port it from F# to OCaml. I have avoided as much .NET-specific libraries as I could, and since F#'s syntax is based on OCaml's, I'm assuming there should be some automated tools to assist in converting the code.
Anyone know of such things, either finished or in progress?
Thanks deeply!
To answer your question in an answer - as far as I know, there are no such tools and I do not think it is likely somebody will create them.
Although F# is inspired by OCaml, it has evolved a lot and is different in a number of ways (see this SO discussion), so automatic conversion is not trivial. Even if somebody did that, it would be more like compilation to hard to read OCaml than conversion to idiomatic code that you can later continue working on.
To add a few general comments, when you speak about "real-time" I imagine controlling some robot in a factory dealing with dangerous stuff or an airplane control. In these areas, concerns about GC are certainly valid. However, I do not think games are necessarily "real-time". You need good performance, that's for sure, but people have been writing games with .NET and F# quite happily. For some F# examples, see:
... a nice blog with a couple of game samples (that you can actually try & buy)
a 3D airplane shooter game that also looks fairly realistic
and there is also a book that uses games to explain F#
These are probably simpler than what you're aiming for, but it may be good enough to show that writing games using GC is doable.
Unfortunately, due to .NET's lack of an incremental GC (either in the MS or Mono implementation), building soft real-time software such as games with F# is problematic.
A few points here:
Incremental GCs are not the only way to get low pause times. Concurrent GCs like VCGC do the work in bulk but do it concurrently with mutators running, e.g. the VCGC implementation I described in the non-free article here was running with sub-millisecond pause times.
Incremental GC does not necessarily mean low pause times. For example, OCaml's GC typically incurs 10ms pauses and can incur arbitrarily-long pauses when it encounters a deep thread stack or long array in the heap.
I have measured typical pause times of 10ms with OCaml and 30ms with F# on .NET 3. With a simple implementation I was able to build a fault tolerant server in F# from scratch that handled 20k msgs/s with 50% of latencies under 114us and 95% under 500us.
I've written a language in F# that, if -
a) it doesn't perform adequately in the face of the generational GC (arbitrary pauses during the interactive simulation, and
I wouldn't give up on the platform is your first working version has unacceptable latency. There are lots of things you can do to bring the max latency down.
b) OCaml gets a good complete port to the LLVM backend -
I seriously doubt OCaml will ever get what I'd consider to be a "good complete port to the LLVM backend". They'll just retarget LLVM with the current typeless IR and it won't do much better than the current ocamlopt compiler because LLVM isn't designed to optimize that kind of workload.
I will port it from F# to OCaml. I have avoided as much .NET-specific libraries as I could, and since F#'s syntax is based on OCaml's, I'm assuming there should be some automated tools to assist in converting the code.
No automated tools but I've ported hundreds of thousands of lines of code between OCaml and F# now and it is generally very easy because most code is written in the core ML subset of both languages.
I have an image processing routine that I believe could be made very parallel very quickly. Each pixel needs to have roughly 2k operations done on it in a way that doesn't depend on the operations done on neighbors, so splitting the work up into different units is fairly straightforward.
My question is, what's the best way to approach this change such that I get the quickest speedup bang-for-the-buck?
Ideally, the library/approach I'm looking for should meet these criteria:
Still be around in 5 years. Something like CUDA or ATI's variant may get replaced with a less hardware-specific solution in the not-too-distant future, so I'd like something a bit more robust to time. If my impression of CUDA is wrong, I welcome the correction.
Be fast to implement. I've already written this code and it works in a serial mode, albeit very slowly. Ideally, I'd just take my code and recompile it to be parallel, but I think that that might be a fantasy. If I just rewrite it using a different paradigm (ie, as shaders or something), then that would be fine too.
Not require too much knowledge of the hardware. I'd like to be able to not have to specify the number of threads or operational units, but rather to have something automatically figure all of that out for me based on the machine being used.
Be runnable on cheap hardware. That may mean a $150 graphics card, or whatever.
Be runnable on Windows. Something like GCD might be the right call, but the customer base I'm targeting won't switch to Mac or Linux any time soon. Note that this does make the response to the question a bit different than to this other question.
What libraries/approaches/languages should I be looking at? I've looked at things like OpenMP, CUDA, GCD, and so forth, but I'm wondering if there are other things I'm missing.
I'm leaning right now to something like shaders and opengl 2.0, but that may not be the right call, since I'm not sure how many memory accesses I can get that way-- those 2k operations require accessing all the neighboring pixels in a lot of ways.
Easiest way is probably to divide your picture into the number of parts that you can process in parallel (4, 8, 16, depending on cores). Then just run a different process for each part.
In terms of doing this specifically, take a look at OpenCL. It will hopefully be around for longer since it's not vendor specific and both NVidia and ATI want to support it.
In general, since you don't need to share too much data, the process if really pretty straightforward.
I would also recommend Threading Building Blocks. We use this with the Intel® Integrated Performance Primitives for the image analysis at the company I work for.
Threading Building Blocks(TBB) is similar to both OpenMP and Cilk. And it uses OpenMP to do the multithreading, it is just wrapped in a simpler interface. With it you don't have to worry about how many threads to make, you just define tasks. It will split the tasks, if it can, to keep everything busy and it does the load balancing for you.
Intel Integrated Performance Primitives(Ipp) has optimized libraries for vision. Most of which are multithreaded. For the functions we need that aren't in the IPP we thread them using TBB.
Using these, we obtain the best result when we use the IPP method for creating the images. What it does is it pads each row so that any given cache line is entirely contained in one row. Then we don't divvy up a row in the image across threads. That way we don't have false sharing from two threads trying to write to the same cache line.
Have you seen Intel's (Open Source) Threading Building Blocks?
I haven't used it, but take a look at Cilk. One of the big wigs on their team is Charles E. Leiserson; he is the "L" in CLRS, the most widely/respected used Algorithms book on the planet.
I think it caters well to your requirements.
From my brief readings, all you have to do is "tag" your existing code and then run it thru their compiler which will automatically/seamlessly parallelize the code. This is their big selling point, so you dont need to start from scratch with parallelism in mind, unlike other options (like OpenMP).
If you already have a working serial code in one of C, C++ or Fortran, you should give serious consideration to OpenMP. One of its big advantages over a lot of other parallelisation libraries / languages / systems / whatever, is that you can parallelise a loop at a time which means that you can get useful speed-up without having to re-write or, worse, re-design, your program.
In terms of your requirements:
OpenMP is much used in high-performance computing, there's a lot of 'weight' behind it and an active development community -- www.openmp.org.
Fast enough to implement if you're lucky enough to have chosen C, C++ or Fortran.
OpenMP implements a shared-memory approach to parallel computing, so a big plus in the 'don't need to understand hardware' argument. You can leave the program to figure out how many processors it has at run time, then distribute the computation across whatever is available, another plus.
Runs on the hardware you already have, no need for expensive, or cheap, additional graphics cards.
Yep, there are implementations for Windows systems.
Of course, if you were unwise enough to have not chosen C, C++ or Fortran in the beginning a lot of this advice will only apply after you have re-written it into one of those languages !
Regards
Mark
Another thread had this quote
Erlang VM BEAM and HiPE is written mostly in C.
Linked-in drivers are written mostly in C. (They are plugged to VM
and serves communication with outside
world.)
I've read some opinions that Ada's strong typing, modularity, run-time checking, parallel processing etc. etc. are better than that of C.
Would Erlang compiled using Ada be noticably better or worse than the Erlang made with C?
Just a hypothetical Q.
Normally I'd throw a bunch of weasel-words at you on a topic like this, but it turns out this exact question has been studied (it's a .doc file. Sorry).
Rational had a compiler with a large amount of code in both languages, and a large amount of data compiled over several years on bug rates, fix times, etc. Out of curiosity, one of their engineers crunched the numbers.
The answer was "Development Costs of C Exceed Those of Ada". If you read past the summary title, you'd see that they figured writing the same code in Ada cost them about half what writing it in C cost.
I know that everyone reading this is anxious to poke holes in that conclusion. I was too. But they looked at darn near every angle I could think of in the report.
"Better" in what way? Better as in faster? Better as in less bugs? Better as in more portable? Better as in more readable? Better as in more extensible?
For any suitable definition of "better" arguments can be made either way. However, it is just about sacred writ that no compiled language is more portable than C. Thus, if one of your goals is to make your application highly portable, C is an excellent choice.
More people understand C than Ada. Writing erlang extensions might be much harder if it was written in Ada, simply because fewer people are conversant with the language.
C code can be highly performant, but I am aware of no comparisons between C and Ada w/r to compiler optimizations.
Ada's type checking might be useful, or it could be a real problem. One presumes that a VM does it's own type checking on the pieces that matter to it. The overhead of RTTC in Ada could impose a completely unnecessary burden.
Perhaps, but what language was your Ada compiler written in? Ada? What about the compiler that write your FIRST Ada compiler?
At some point when you are building software, formal semantics and software processes are much more important than what language something was coded in.