Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement KT-73565 and basic box tests for memcpy, memmove, memset and memcmp intrinsics #5385

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

KitsuneAlex
Copy link

As described in the associated YouTrack issue, this PR aims to add memory intrinsics for Kotlin/Native for functions such as memset, memcpy, memmove and memcmp (throught libc). This allows optimizing a lot of per-element loop based functions with much faster optimized code.

I also implemented a public API for the intrinsics, supporting both untyped NativePointed addresses, and type safe extension functions for CPointer.

Very basic tests have been implemented in kt73565.kt for every function to make sure they work.

If you have any comments or nitpicks, feel free to let me know.
Cheers.

@KitsuneAlex
Copy link
Author

Adding some changes to this, i wasn't happy with the names of the extension functions for CPointer and i also forgot to add the TARGET header for the box test.

import kotlin.collections.set
import kotlin.collections.sortedBy
import kotlin.collections.toList
import kotlin.collections.toTypedArray
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know why my formatter did this with the project settings.. can fix if desired.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please.

@sbogolepov sbogolepov self-requested a review December 12, 2024 09:15
Copy link
Contributor

@sbogolepov sbogolepov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Great work overall, but it requires a few minor adjustments :)

@@ -90,6 +98,65 @@ internal object nativeMemUtils {
fun copyMemory(dest: NativePointed, length: Int, src: NativePointed) =
unsafe.copyMemory(src.address, dest.address, length.toLong())

fun memset(mem: NativePointed, value: Byte, size: Int) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no need to add intrinsics to the JVM interop as they are unused there.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, it didn't compile without them for me in my personal fork, that's odd. Will remove ^^

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah i have to add them there too it seems, at least if i want to add this to nativeMemUtils, the code does not compile when the functions are not defined in both files. Everything breaks :/

import kotlin.collections.set
import kotlin.collections.sortedBy
import kotlin.collections.toList
import kotlin.collections.toTypedArray
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please.

@@ -391,8 +419,14 @@ internal class StackLocalsManagerImpl(
val bbInitStackLocals: LLVMBasicBlockRef
) : StackLocalsManager {
private var scopeDepth = 0
override fun enterScope() { scopeDepth++ }
override fun exitScope() { scopeDepth-- }
override fun enterScope() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A nitpick: it is usually a good idea to separate formatting changes from actual ones. Beyond other things, it makes review easier :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, will keep that in mind. I'm just way too used to hitting CTRL+ALT+L after everytime i finish writing something somewhere hahaha.

@TypedIntrinsic(IntrinsicType.INTEROP_READ_PRIMITIVE) external fun getDouble(mem: NativePointed): Double
@TypedIntrinsic(IntrinsicType.INTEROP_WRITE_PRIMITIVE) external fun putDouble(mem: NativePointed, value: Double)
@TypedIntrinsic(IntrinsicType.INTEROP_SET_MEMORY)
external fun memset(mem: NativePointed, value: Byte, size: Int)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need both 32 and 64-bit versions? Are they equally portable?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what i know about LLVM, they should be equally portable.
However, there's a reason why i split them up:

All major native platforms apart from some mobile and embedded applications are 64-bit now.
Using 64-bit everywhere for things like memcpy could waste CPU cycles for applications where 64-bits will never be used (since this affects the internal index size of the intrinsic implementation afaik), like when copying between native memory <-> kotlin arrays, only if it's probably very little.
It is still important to offer the 64-bit API to allow utilizing the full capability of the host CPU when working with unmanaged memory.

If you want, we can drop the small 32-bit optimization entirely and just cast to 64-bit size types when dealing with things like arrays etc.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could be wrong to be honest, will look into this a little deeper.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All major native platforms apart from some mobile and embedded applications are 64-bit now.

Unfortunately, we still have 32-bit targets, and providing 64-bit API for them might be wrong.

Copy link
Author

@KitsuneAlex KitsuneAlex Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we should offer both, since Kotlin does not have a size type, i think. 32-bit only is very mediocre for more serious applications imo.

}

@ExperimentalForeignApi
public fun copyMemory(destMem: NativePointed, srcMem: NativePointed, size: Long) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need both moveMemory and copyMemory functions? The second one is less safe and performance benefits might not worth it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No real reason i added memmove apart from "might as well complete the set of three" when i was reading the LLVM manual to look up the copy intrinsic. Can remove if you want :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I tend to think that memmove should be sufficient for now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, not entirely happy with that to be honest, since 99% of the time you'd use memcpy, not memmove but that works.

}

@ExperimentalForeignApi
public inline fun <reified T : CVariable> CPointer<T>.compareBlock(dest: CPointer<T>, length: Int): Int {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe compareContentsWith?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that, will change.

}

@ExperimentalForeignApi
public inline fun <reified T : CVariable> CPointer<T>.setBlock(value: Byte, length: Int) {
Copy link
Contributor

@sbogolepov sbogolepov Dec 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just fillWith?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also a good name, will change.

@@ -727,3 +735,43 @@ public fun COpaquePointer.readBytes(count: Int): ByteArray {
nativeMemUtils.getByteArray(this.reinterpret<ByteVar>().pointed, result, count)
return result
}

@ExperimentalForeignApi
public fun setMemory(mem: NativePointed, value: Byte, size: Long) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add a small KDoc for all new public functions?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do!

data1.usePinned { pinned ->
pinned.addressOf(0).setBlock(0, data1.size)
}
if (data1.contentEquals(data2)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking the new value directly would be more robust.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, will fix.

import kotlin.test.*
import kotlinx.cinterop.*

fun box(): String {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add tests for top-level functions as well.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, don't know why i didn't think of that, will add.

@KitsuneAlex
Copy link
Author

Will update this in the following days, was a little busy this weekend :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants