Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Validate kllama Apple native-kernel fix (PR #315) on real iOS/macOS hardware

Abierto
  • ¿Algo no está bien?
#316 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
kotlin
Área
mobile-dev, performance

Línea de trabajo

The remaining work is a before/after packed-quant matmul throughput comparison on real Apple hardware; the issue does not name a benchmark file or command. First read PR #315 and the engine’s #958/#959 performance results, then locate the benchmark entry point. Record comparable results for the old stub and the fix on an Apple Silicon device; simulator or compile results alone do not meet the stated goal.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

help wanted

Context

PR #315 fixed llm-runtime/kllama's PlatformNativeKernels.ios.kt/.macos.kt,
which were stale no-op stubs — both cited SKaiNET#959 as "not shipped yet" when
it had in fact shipped, meaning kllama's registerPlatformBackends() facade
was silently leaving packed-quant matmul on the scalar floor on iOS and macOS,
despite the engine's native-cinterop NEON/Accelerate kernels being built and
available.

The fix itself (calling installNativeKernels(), mirroring linuxMain's
actual) was written and reviewed, but could not be compiled or run in the
session that produced it — that environment was Linux only, and Kotlin/Native
requires a macOS host to compile Apple targets at all. Verification there was
limited to code review and cross-target compilation (jvm/linuxX64/android/js).

What needs a Mac

  • ./gradlew :llm-runtime:kllama:compileKotlinIosArm64 :llm-runtime:kllama:compileKotlinIosSimulatorArm64 :llm-runtime:kllama:compileKotlinMacosArm64 — confirm the fix actually compiles (the installNativeKernels() import/call was written against the API but never type-checked on an Apple target). Update: it did not compile as originally written — implementation(libs.skainet.backend.nativeCpu) was still scoped to linuxMain only, not nativeMain, so macosMain/iosMain never got the dependency. Fixed in PR #315 commit 9bb3707; all three Apple targets now compile.
  • At runtime, confirm KernelRegistry.bestAvailable()?.name (or equivalent) reports native-cinterop on iOS/macOS after registerPlatformBackends() runs, not scalar. Confirmed via KernelRegistry.availableNames() on both macosArm64Test and iosSimulatorArm64Test: reports [native-cinterop].
  • A real before/after comparison: packed-quant matmul throughput with the old no-op stub vs. the fix, on an actual Apple Silicon device/simulator — the engine's own NEON/cinterop work (#958/#959) reported real numbers on Android-equivalent hardware; this fix has none yet for Apple.
  • Run kllama's existing test suite on iosSimulatorArm64Test/macosArm64Test (both currently skip on CI/Linux — kotlin.native.ignoreDisabledTargets). Both green, including the cross-target SmolLm2InferenceSpike (commonTest).

Related

  • Fixed by #315
  • Exercised end-to-end by SKaiNET-examples' KernelRace sample — see SKaiNET-examples#33, which needs this issue resolved before its iOS build shows real NEON acceleration instead of scalar.

Good fit for whoever on the team has a Mac + Xcode handy — no deep kernel-SPI knowledge needed, mostly "build it, run it, check the numbers." Remaining: real-device throughput numbers (needs physical hardware time, not just simulator/compile verification).

Lenguaje dominante
Kotlin
Estrellas
8
Forks
3
Merge medio
1 d 16 h
PR fusionados (30 d)
48

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de SKaiNET-developers/SKaiNET-transformers

Todos los issues de SKaiNET-developers/SKaiNET-transformers

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.