4 ms·

I would love to see some benchmarks against c and c++.

nddrylliog 17y ago
Done and done, but it's not such a good idea. ooc translates to C, and as someone mentioned, it's often the C you would write yourself. What you would really be benchmark here is Garbage collector vs vanilla malloc/free. And whether one or the other is fastest depends greatly on your scenario (and on your malloc implementation, e.g. http://goog-perftools.sourceforge.net/doc/tcmalloc.html http://goog-perftools.sourceforge.net/doc/tcmalloc.html is looking good)
- scott_s 17y ago
  That your compiler produces C doesn't imply anything about performance. When you introduce general abstractions, you also make it harder to perform certain optimizations. It's still worthwhile, and potentially informative, to write an idiomatic OOC program, an optimized OOC program, and compare their performance to both an idiomatic C program and an optimized C program. (Solving the same problem, of course.) Your statement "it's often the C you would write yourself" is a claim that you can support with numbers.
  - nddrylliog 17y ago
    It's very difficult to determine what is "idiomatic", and how far to go. For example, in ooc you often have to choose between classes and covers. When you don't need inheritance, covers is often enough, + you get to work on the stack rather than all on the heap (in that respect, ooc offers more flexibility than Java, and a little less than C++) What would also be interesting is offering abstractions for parallelism in ooc, etc. and then differences in benchmarks would show for "idiomatic" implementations. (Very much like Haskell idiomatic solutions are sometimes faster than C ones.) The challenge that programmers are presented with nowadays is much more than just rewriting a few tight loops in assembler ;) Concurrency and parallelism are the most important challenges for us now, imho.
    - scott_s 17y ago
      Hey, you're the designer and implementer. You need to explore what idiomatic OOC codes looks like. If you pick up enough users, they'll evolve it for you, but you need to start it. If you're interested in abstractions for concurrency and parallelism, I suggest you look at both Cilk and Apple's block extension for C (used in conjunction with Grand Central Dispatch). There are many others, of course, but those perhaps are the easiest fit into your language.

Done and done, but it's not such a good idea. ooc translates to C, and as someone mentioned, it's often the C you would write yourself. What you would really be benchmark here is Garbage collector vs vanilla malloc/free. And whether one or the other is fastest depends greatly on your scenario (and on your malloc implementation, e.g. http://goog-perftools.sourceforge.net/doc/tcmalloc.html http://goog-perftools.sourceforge.net/doc/tcmalloc.html is looking good)

scott_s 17y ago
That your compiler produces C doesn't imply anything about performance. When you introduce general abstractions, you also make it harder to perform certain optimizations. It's still worthwhile, and potentially informative, to write an idiomatic OOC program, an optimized OOC program, and compare their performance to both an idiomatic C program and an optimized C program. (Solving the same problem, of course.) Your statement "it's often the C you would write yourself" is a claim that you can support with numbers.
- nddrylliog 17y ago
  It's very difficult to determine what is "idiomatic", and how far to go. For example, in ooc you often have to choose between classes and covers. When you don't need inheritance, covers is often enough, + you get to work on the stack rather than all on the heap (in that respect, ooc offers more flexibility than Java, and a little less than C++) What would also be interesting is offering abstractions for parallelism in ooc, etc. and then differences in benchmarks would show for "idiomatic" implementations. (Very much like Haskell idiomatic solutions are sometimes faster than C ones.) The challenge that programmers are presented with nowadays is much more than just rewriting a few tight loops in assembler ;) Concurrency and parallelism are the most important challenges for us now, imho.
  - scott_s 17y ago
    Hey, you're the designer and implementer. You need to explore what idiomatic OOC codes looks like. If you pick up enough users, they'll evolve it for you, but you need to start it. If you're interested in abstractions for concurrency and parallelism, I suggest you look at both Cilk and Apple's block extension for C (used in conjunction with Grand Central Dispatch). There are many others, of course, but those perhaps are the easiest fit into your language.