Inlining functions

77 views
Skip to first unread message

david.h...@gmail.com

unread,
Dec 4, 2014, 12:30:17 PM12/4/14
to ooc-...@googlegroups.com
Running Cachegrind on my program revealed that the most common call I was making was this:

[FloatExtension.ooc]

extend Float {
...
squared: func -> This {
this * this
}
}

so I tried inlining it, because I'm pretty sure I've seen that being done in the SDK code:

extend Float {
...
squared: inline func -> This {
this * this
}
}

However in the generated C code, the function is still there:

[FloatExtension.c]

lang_Numbers__Float lang_Numbers__Float_squared(lang_Numbers__Float this) {
#line 66 "/home/david/versioned/ooc/ooc-kean/source/math/FloatExtension.ooc"
return this * this;
}

and the ooc code that called it is still calling it.

In the SDK, there's a function (among others, probably)

[File.ooc]

_isDirHardlink?: inline func (dir: CString) -> Bool {
(dir[0] == '.') && (dir[1] == '\0' || ( dir[1] == '.' && dir[2] == '\0'))
}

that also doesn't seem to be inlined in the generated C code. One call

[FileUnix.ooc]
...
_getChildren: func <T> (T: Class) -> ArrayList<T> {
...
if (!_isDirHardlink?(entry@ name)) {
...

is translated to

[FileUnix.c]

if (!io_File___isDirHardlink__quest((*(entry)).d_name)) {

and the function itself is declared as

[File.c]

lang_types__Bool io_File___isDirHardlink__quest(lang_Character__CString dir)

which doesn't look like it's going to be inlined to me.

At first I thought I was doing something wrong, but it looks like I'm not alone. Are inline functions supposed to be inlined in the C code, or not? There are many other functions like this in my codebase that are called a very large number of times and that would be very convenient to inline to keep the code tidy.

House Zet

unread,
Dec 11, 2014, 5:48:30 AM12/11/14
to ooc-...@googlegroups.com, david.h...@gmail.com
I don't think inline is implemented in current rock...

Now we are just setting isInline flag but nothing more.

David Hesselbom

unread,
Dec 11, 2014, 6:21:08 AM12/11/14
to House Zet, ooc-...@googlegroups.com
Ok. I think I read somewhere that inlining virtual functions can't be done in C anyway, and since all functions are virtual in ooc, well... I guess that settles that.

David Hesselbom

unread,
Dec 11, 2014, 7:46:03 AM12/11/14
to House Zet, ooc-...@googlegroups.com
Wait, C doesn't even have virtual functions. *facepalm* But in C++, at least, virtual functions cannot be inlined. So I guess the same would be true for ooc.

Amos Wenger

unread,
Dec 12, 2014, 12:58:50 PM12/12/14
to David Hesselbom, House Zet, ooc-...@googlegroups.com
Yes, inlining is delicate.

For methods.. it would require non-virtual methods, which ooc doesn't have (except for covers).

For functions, once upon a time, using the ooc `inline` keyword *did* indeed generate C code with the C `inline` keyword, which *might* have in turn generated inlined code — but if I recall correctly, C compilers are under no obligation to do so, and it's one of the top ten things programmers do when they think it's going to make code faster, but it doesn't. C compilers inline themselves when they feel like it's going to be a performance increase, IIRC. (Of course, things get more complicated across modules...)

One thing related to inlining that has been experimented with in a rock branch was Generic specialization: I did my bachelor project on that. https://speakerdeck.com/nddrylliog/generic-specialization-in-ooc — I didn't land in master yet, because it's not straightforward, and needs proper testing before it's thrown in.

So, no trivial solution to your request, I'm afraid.

Cheers,
- A

--
You received this message because you are subscribed to the Google Groups "ooc-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ooc-lang+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

david.h...@gmail.com

unread,
Dec 15, 2014, 4:44:51 AM12/15/14
to ooc-...@googlegroups.com, david.h...@gmail.com, zhai...@gmail.com, amosw...@gmail.com
That "talk" was amazing! I'll have to take a look at that branch of yours. Shame it's not there in master yet :) One thing though, is this line

data[index.._size - 1] = data[index + 1.._size]

supposed to work in the current version of rock, or only in that specialized version?

Anyway, yeah, I'm confusing ooc inline and C inline. C compilers indeed aren't guaranteed to inline functions just because you tell them to, and they may inline functions that you didn't tell them to, as well. Not sure what the purpose of such a keyword is... In ooc though, the keyword could (should?) be an actual command to rock, so that in the resulting C code, the function calls are actually replaced by their code.

Amos Wenger

unread,
Dec 16, 2014, 11:19:59 AM12/16/14
to David Hesselbom, ooc-...@googlegroups.com, House Zet
The "range assignment" syntax was just an idea, I don't think it was ever implemented. It's interesting, but one would also have to consider operator overloading, bounds checking, etc. For example, arr[0..3] = arr[0..1] doesn't make sense.

I used to be of the opinion that compilers should respect inline unconditionally, like you — but looking into JIT compilers changed my mind. Sometimes inlining is harmful. Having small code with invocations is sometimes better than trashing the cache because the code is too big to fit in there. It really depends. For that reason — and also the complexity of inlining code, it's not done by rock this way yet. The keyword is reserved, as some C keywords are, without effect right now.

Amos Wenger

unread,
Dec 16, 2014, 11:42:00 AM12/16/14
to David Hesselbom, ooc-...@googlegroups.com
Ah, rock isn't a JIT compiler, but nothing would prevent someone from writing an ooc implementation on top of a JIT :) There isn't really a language spec for ooc per se, but if there was I wouldn't make the potency of the "inline" keyword an absolute requirement.

I think we mostly agree here, including on the fact that it's kind of sad that nobody has yet taken the time to properly implement inlining in rock.

On Tue, Dec 16, 2014 at 5:36 PM, David Hesselbom <david.h...@gmail.com> wrote:
Yes, inlining is possibly harmful, but I'd imagine quite a lot of work would have to go into making rock clever enough to figure out when inlining is a good idea and when it's a bad one, so better leave it to the person writing the code, who can then benchmark which is faster, at least the platform they're currently on. Neither C nor ooc are JIT compiled anyway, are they?

david.h...@gmail.com

unread,
Jul 15, 2015, 2:34:39 AM7/15/15
to ooc-...@googlegroups.com, zhai...@gmail.com, david.h...@gmail.com, amosw...@gmail.com
Another question about ranges: Is it possible to define a function

getNumbers(range: Range)

so that you can call it as

getNumbers(x .. y)

? Also, is the Range cover used under the hood in for loops?

Amos Wenger

unread,
Jul 15, 2015, 5:24:50 AM7/15/15
to David Hesselbom, ooc-...@googlegroups.com, House Zet
Answering off the top of my head, since my current rock is broken due to refactoring and have little time:

No, the Range cover isn't used in for loops, rock translates them to a C for loop.

And yes, outside of that context, `x .. y` is of type Range and you can access its members etc. I'll let you try and see what actually works, but we have this test, and it passes: https://github.com/fasterthanlime/rock/blob/master/test/compiler/literals/range-literal.ooc

Would be good to mention in the official docs, since I'm assume, you're asking because it's not in there.

Cheers,
- Amos
Reply all
Reply to author
Forward
0 new messages