4 ms·

The object oriented part of Objective-C was never meant for high performance code. Apple documentation always recommended using C when performances are an issue

The object oriented part of Objective-C was never meant for high performance code. Apple documentation always recommended using C when performances are an issue, which can be easily done because Objective-C is in fact C plus a bunch of object oriented concepts. However, in the end if you want every bit of performance you have to use SIMD intrinsics or write asm directly, so even C can be 8x times or more slower than a manually optimized code.

robomartin 3y ago
The key point is: As a percentage of the totality of software engineering, virtually nobody looks at energy optimization. Smart phones? Well, the manufacturers likely pay attention to this to some degree. However, I can guarantee you that almost none of the millions of app developers working on third party apps ever look at energy as an optimization vector. That was my point, the carbon footprint of computing systems is dominated --and permanently marked-- by the energy-dominant language running on it.
- saagarjha 3y ago
  It’s actually dominated by the time complexity of the code running on it.
  - bruce343434 3y ago
    All things being equal, no. It's the language.
    - saagarjha 3y ago
      All things are never equal, so this isn’t particularly relevant or useful.
      - bruce343434 3y ago
        That philosophy isn't particularly relevant or useful. How else can you truthfully compare 2 things? Do you always pre-emptively give up and say "well things are always kind of different anyway so it doesn't matter how they compare"? PS, big O isn't everything. The constant factors that big O hides are in fact meaningful and can make or break an algorithm. Some languages make some constants worse by having extra overhead in some places or better when they have special facilities. See also: sorting algorithms deferring to insertion sort O(n²) for small runs, galactic algorithms. See also: languages where everything is a pointer to dynamic memory, vs languages that have actual values. The language default "dictionary" implementation and its time and space complexities. I could go on. For energy efficiency, or memory efficiency, or speed, choice of language does matter, and depending on the size and nature of the data, can overshadow algorithmic choices.
        saagarjha 3y ago
        I'm not saying those things don't matter, or that it's not possible that you can overcome some algorithmic complexity just by brute forcing it with a smaller constant. I'm saying that it is exceptionally rare that you are ever in a situation where you can go "oh I have these two identical pieces of software, let's just pick the one that uses the efficient language". Really, it comes down to this question: "this code is slow, what should I do to improve it?". The answer is usually "fix the time complexity somewhere or do less work" and it becomes good enough. Maybe in some isolated cases I might rewrite a bit of it in a different language if appropriate. When I say "time complexity dominates footprint" I mean that most of the code changes I make along the lines of changing something to take "100 ms → 2 ms" where the other language would be "25 ms → 0.5 ms" but you can see why I would not say that the language dominates here.
  - robomartin 3y ago
    > It’s actually dominated by the time complexity of the code running on it. No. Please read the paper I posted. It’s the language.
    - saagarjha 3y ago
      I’ve read it; it’s a garbage paper. I don’t fault the authors for doing the study but applying the results to anything in reality is almost tantamount to malpractice. It just means AWS people go up on stage and make fools of themselves pushing Rust for environmental impact or people like you try to explain how iOS apps kill your battery to one of the few people who actually has worked to optimize this. The first thing we always investigated was doing less work and fixing bad algorithms, followed by very localized language replacement on hot paths, then as a last resort wholesale rewrites. The ratio of these options was close to 90:9:1.
      - robomartin 3y ago
        You sound angry. You also sound like you are talking to a bunch of morons who don't understand the difference between time complexity and the computational/implementation realities of different languages. On a personal note, I started my hardware/software development career in the early '80's, writing non-trivial applications in assembly language for a dozen different processors and, of course, designing entire computers from scratch. On from there through languages such as C, C++, Forth, APL, LISP, various Basics and, eventually pretty much all of the "modern" languages. During that time I designed and manufactured custom bit-sliced micro-coded processors with discrete chips in the early days and, PLD/PAL's and, later-on, FPGA's. Sure, I use Python a lot today, yet, I know what I am walking into when I do. I also use lots of C/C++ and, these days, ARM assembler. Slow code that is both time and energy inefficient is a modern reality. Virtually nobody coming out of a typical university CS curriculum today is exposed to coding without objects. Bloated, slow and, yes, high energy-consuming code is almost normal these days. Look at almost any open source codebase for evidence of this. And, frankly, as machines become faster, nobody cares, because inefficient code works just fine. Sometimes I compare it to sailing. When there's lots of wind everyone is a sailor. When wind is minimal, you better know what you are doing. Today people benefit from processors running multiple cores at multi-GHz clock rates with tens of gigabytes of memory and terabytes of storage. Of course that leads to bloat and inefficiency at every level! Why wouldn't it?
saagarjha 3y ago
Objective-C isn’t actually that bad as long as you’re aware of what constraints it puts on the compiler. People like to go “oh method calls are so slow!” but you can do a billion of them a second. The real performance win comes from selective use of optimization-friendly code on hot paths that don’t act as a black box to the compiler. Some teams move at Lightspeed to some weird janky architecture that just sucks in every aspect because they think it will help, and it usually doesn’t.
- meisel 3y ago
  The real slowdown of Objective-C method calls is at startup where the caches haven't been filled. Pure Objective-C apps typically spend 5-15% of startup time on objc_msgSend
  - saagarjha 3y ago
    I haven’t looked into this for a while, but are method caches not included in the dyld closure?
    - meisel 3y ago
      I’m not sure
pjmlp 3y ago
NeXTSTEP drivers were written in Objective-C.

robomartin 3y ago

The key point is: As a percentage of the totality of software engineering, virtually nobody looks at energy optimization. Smart phones? Well, the manufacturers likely pay attention to this to some degree. However, I can guarantee you that almost none of the millions of app developers working on third party apps ever look at energy as an optimization vector. That was my point, the carbon footprint of computing systems is dominated --and permanently marked-- by the energy-dominant language running on it.

saagarjha 3y ago
It’s actually dominated by the time complexity of the code running on it.
- bruce343434 3y ago
  All things being equal, no. It's the language.
  - saagarjha 3y ago
    All things are never equal, so this isn’t particularly relevant or useful.
    - bruce343434 3y ago
      That philosophy isn't particularly relevant or useful. How else can you truthfully compare 2 things? Do you always pre-emptively give up and say "well things are always kind of different anyway so it doesn't matter how they compare"? PS, big O isn't everything. The constant factors that big O hides are in fact meaningful and can make or break an algorithm. Some languages make some constants worse by having extra overhead in some places or better when they have special facilities. See also: sorting algorithms deferring to insertion sort O(n²) for small runs, galactic algorithms. See also: languages where everything is a pointer to dynamic memory, vs languages that have actual values. The language default "dictionary" implementation and its time and space complexities. I could go on. For energy efficiency, or memory efficiency, or speed, choice of language does matter, and depending on the size and nature of the data, can overshadow algorithmic choices.
      - saagarjha 3y ago
        I'm not saying those things don't matter, or that it's not possible that you can overcome some algorithmic complexity just by brute forcing it with a smaller constant. I'm saying that it is exceptionally rare that you are ever in a situation where you can go "oh I have these two identical pieces of software, let's just pick the one that uses the efficient language". Really, it comes down to this question: "this code is slow, what should I do to improve it?". The answer is usually "fix the time complexity somewhere or do less work" and it becomes good enough. Maybe in some isolated cases I might rewrite a bit of it in a different language if appropriate. When I say "time complexity dominates footprint" I mean that most of the code changes I make along the lines of changing something to take "100 ms → 2 ms" where the other language would be "25 ms → 0.5 ms" but you can see why I would not say that the language dominates here.
- robomartin 3y ago
  > It’s actually dominated by the time complexity of the code running on it. No. Please read the paper I posted. It’s the language.
  - saagarjha 3y ago
    I’ve read it; it’s a garbage paper. I don’t fault the authors for doing the study but applying the results to anything in reality is almost tantamount to malpractice. It just means AWS people go up on stage and make fools of themselves pushing Rust for environmental impact or people like you try to explain how iOS apps kill your battery to one of the few people who actually has worked to optimize this. The first thing we always investigated was doing less work and fixing bad algorithms, followed by very localized language replacement on hot paths, then as a last resort wholesale rewrites. The ratio of these options was close to 90:9:1.
    - robomartin 3y ago
      You sound angry. You also sound like you are talking to a bunch of morons who don't understand the difference between time complexity and the computational/implementation realities of different languages. On a personal note, I started my hardware/software development career in the early '80's, writing non-trivial applications in assembly language for a dozen different processors and, of course, designing entire computers from scratch. On from there through languages such as C, C++, Forth, APL, LISP, various Basics and, eventually pretty much all of the "modern" languages. During that time I designed and manufactured custom bit-sliced micro-coded processors with discrete chips in the early days and, PLD/PAL's and, later-on, FPGA's. Sure, I use Python a lot today, yet, I know what I am walking into when I do. I also use lots of C/C++ and, these days, ARM assembler. Slow code that is both time and energy inefficient is a modern reality. Virtually nobody coming out of a typical university CS curriculum today is exposed to coding without objects. Bloated, slow and, yes, high energy-consuming code is almost normal these days. Look at almost any open source codebase for evidence of this. And, frankly, as machines become faster, nobody cares, because inefficient code works just fine. Sometimes I compare it to sailing. When there's lots of wind everyone is a sailor. When wind is minimal, you better know what you are doing. Today people benefit from processors running multiple cores at multi-GHz clock rates with tens of gigabytes of memory and terabytes of storage. Of course that leads to bloat and inefficiency at every level! Why wouldn't it?

saagarjha 3y ago

Objective-C isn’t actually that bad as long as you’re aware of what constraints it puts on the compiler. People like to go “oh method calls are so slow!” but you can do a billion of them a second. The real performance win comes from selective use of optimization-friendly code on hot paths that don’t act as a black box to the compiler. Some teams move at Lightspeed to some weird janky architecture that just sucks in every aspect because they think it will help, and it usually doesn’t.

meisel 3y ago
The real slowdown of Objective-C method calls is at startup where the caches haven't been filled. Pure Objective-C apps typically spend 5-15% of startup time on objc_msgSend
- saagarjha 3y ago
  I haven’t looked into this for a while, but are method caches not included in the dyld closure?
  - meisel 3y ago
    I’m not sure

pjmlp 3y ago

NeXTSTEP drivers were written in Objective-C.