4 ms·

Really? It's that simple? I wonder then why all these compiler writers spend so much time on getting the type system right if all they need to do is just add so

Really? It's that simple? I wonder then why all these compiler writers spend so much time on getting the type system right if all they need to do is just add some if statements and then add a JIT. Guess I can also solve all pointer aliasing problems by just adding "if p != q {...}".

wfunction 10y ago
> Really? It's that simple? Yeah. > I wonder then why all these compiler writers spend so much time on getting the type system right if all they need to do is just add some if statements then add a JIT. Because (1) JIT has a latency hit users like to avoid, and (2) you still have to solve the same problem during JIT time, it doesn't magically go away.
DannyBee 10y ago
Yes. Actually, it kind of is. Note: I'm one of these compiler writers. In fact, i'm one of the compiler writers who wrote the current aliasing implementations for the two major compilers everyone uses, among other things. If you are going to disagree, please be concrete. I'm stating that good enough aliasing algorithms exist to do what you want, and where you can't, you can do runtime checks. People who truly care about performance hand the compiler the whole program, and want it to do a great job. It can and will. Your counter argument is what, exactly. That because people spend time getting type systems right, this must be false? If so, that's just silly. People spend time on getting type systems right to make it easier to reason about for people. Not because it's impossible at the compiler level. But because they'd rather not have to do it if they can avoid it. That doesn't mean it can't be done, and isn't done.
- dkarapetyan 10y ago
  You know I have some Ruby code that could use your skills. I really do wish my Ruby would run as fast as my C and you seem to know the magic to making that happen. Can I see some of that code and those papers? I really do want the dynamism of Ruby but combined with the runtime static goodness of C with none of the runtime checking I currently have to deal with. Your confident tone has convinced me those type system folks are a bunch of quacks. The compiler really doesn't need all that information to optimize anything. Seems like all I need to do is bone up on alias analysis, JITing, and inlining and I'm good to go.
  - DannyBee 10y ago
    Okay, i give up. you don't want to actually have a conversation here. In the meantime, i'll just point out, you can have the nicest type system in the world. It still has to translate into concrete aliasing info about pointers that is usable by both high and lower levels, and is queryable in O(1) time, without taking up a ton of space. Otherwise, it's just sitting there making guarantees no one can use. "Seems like all I need to do is bone up on alias analysis, JITing, and inlining and I'm good to go." For most code, yes, actually, that's probably just about right.
    - dkarapetyan 10y ago
      We indeed could have had a conversation but you opened right out of the gate with "This is trivially wrong". Instead of assuming good faith and seeing the example for what it was, a stand-in for sufficiently complicated code with sufficiently complicated code paths that a compiler would be unable to sufficiently analyze and be sufficiently clever with unless the programmer gave the compiler more information. Instead you made a bunch of disparaging remarks, trivialized large swaths of CS theory, and failed to see the actual point of my comment in connecting type annotations as mechanically verifiable invariants/assumptions that can be used in optimization pipelines.
      - DannyBee 10y ago
        Throughout this entire thread, your responses to roughly everyone amount to saying that everyone but you is both 1. wrong 2. just not understanding you. When pressed, you change your arguments and become super-snarky. I would re-evaluate the way you are communicating here. IMHO, it is not effective at communicating whatever interesting and useful insights you may have here.
        dkarapetyan 10y ago
        I didn't have insights. Everything I said is pretty standard fare in optimizing compiler design. You can't turn the optimizer crank without assumptions that the type system lets the programmer express and that the compiler can mechanically verify. Information for optimization passes doesn't come for free and as terminating programs compilers can only fill-in so many holes before the programmer must fill-in the rest or barring that pay a performance penalty which is what happens in dynamic languages even with a JIT.

wfunction 10y ago

> Really? It's that simple? Yeah. > I wonder then why all these compiler writers spend so much time on getting the type system right if all they need to do is just add some if statements then add a JIT. Because (1) JIT has a latency hit users like to avoid, and (2) you still have to solve the same problem during JIT time, it doesn't magically go away.

DannyBee 10y ago

Yes. Actually, it kind of is. Note: I'm one of these compiler writers. In fact, i'm one of the compiler writers who wrote the current aliasing implementations for the two major compilers everyone uses, among other things. If you are going to disagree, please be concrete. I'm stating that good enough aliasing algorithms exist to do what you want, and where you can't, you can do runtime checks. People who truly care about performance hand the compiler the whole program, and want it to do a great job. It can and will. Your counter argument is what, exactly. That because people spend time getting type systems right, this must be false? If so, that's just silly. People spend time on getting type systems right to make it easier to reason about for people. Not because it's impossible at the compiler level. But because they'd rather not have to do it if they can avoid it. That doesn't mean it can't be done, and isn't done.

dkarapetyan 10y ago
You know I have some Ruby code that could use your skills. I really do wish my Ruby would run as fast as my C and you seem to know the magic to making that happen. Can I see some of that code and those papers? I really do want the dynamism of Ruby but combined with the runtime static goodness of C with none of the runtime checking I currently have to deal with. Your confident tone has convinced me those type system folks are a bunch of quacks. The compiler really doesn't need all that information to optimize anything. Seems like all I need to do is bone up on alias analysis, JITing, and inlining and I'm good to go.
- DannyBee 10y ago
  Okay, i give up. you don't want to actually have a conversation here. In the meantime, i'll just point out, you can have the nicest type system in the world. It still has to translate into concrete aliasing info about pointers that is usable by both high and lower levels, and is queryable in O(1) time, without taking up a ton of space. Otherwise, it's just sitting there making guarantees no one can use. "Seems like all I need to do is bone up on alias analysis, JITing, and inlining and I'm good to go." For most code, yes, actually, that's probably just about right.
  - dkarapetyan 10y ago
    We indeed could have had a conversation but you opened right out of the gate with "This is trivially wrong". Instead of assuming good faith and seeing the example for what it was, a stand-in for sufficiently complicated code with sufficiently complicated code paths that a compiler would be unable to sufficiently analyze and be sufficiently clever with unless the programmer gave the compiler more information. Instead you made a bunch of disparaging remarks, trivialized large swaths of CS theory, and failed to see the actual point of my comment in connecting type annotations as mechanically verifiable invariants/assumptions that can be used in optimization pipelines.
    - DannyBee 10y ago
      Throughout this entire thread, your responses to roughly everyone amount to saying that everyone but you is both 1. wrong 2. just not understanding you. When pressed, you change your arguments and become super-snarky. I would re-evaluate the way you are communicating here. IMHO, it is not effective at communicating whatever interesting and useful insights you may have here.
      - dkarapetyan 10y ago
        I didn't have insights. Everything I said is pretty standard fare in optimizing compiler design. You can't turn the optimizer crank without assumptions that the type system lets the programmer express and that the compiler can mechanically verify. Information for optimization passes doesn't come for free and as terminating programs compilers can only fill-in so many holes before the programmer must fill-in the rest or barring that pay a performance penalty which is what happens in dynamic languages even with a JIT.