Vi skaber Linux-programmer med Java på kode-serveren - men fortryder det hele og gør noget andet

24. april 2020 kl. 04:589
Men hvad er det andet, vi gør? Svaret vil overraske dig! (Måske.) (Måske ikke.)
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

I sidste episode af Version2’s open source-eventyr besluttede vi os for at compile vores Java-program, der kan udtrække oplysninger fra dokumenter til et regnearksformat, til hjemmefødte programmer, der kan køre på egen hånd uden Javas afviklingsmiljø.

Det skulle gøre det nemmere for mindre tekniske brugere at benytte programmet, og det var jo mine journalist-kolleger, jeg havde i tankerne i sin tid.

Og nu kan man faktisk det ønskede - bruge en nem kommando som

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
9 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
10
29. april 2020 kl. 16:17

Husk</p>
<p>ldd -v /bin/grep</p>
<p>når du skal finde /bin/grep's størrelse.

Det vil inkludere hele libc.so som indeholder en masse kode som grep ikke bruger. En passende måling ville være at linke grep statisk så kun den nødvendige kode bliver inkluderet. Men for at være sammenligneligt skal graal kan noget lignede med at eleminere ubrugte klasser, som måske ikke er muligt pga. javas introspection-funktionalitet.

9
25. april 2020 kl. 21:59

Mange glemmer løkke-kroppes størrelse og deres betydning for køretiden. Kan man dele en løkke op i 2-4 underløkker, kan det mærkes på køretiden. Men det en balance imellem i-cache udnyttelse (til gentagelser) og d-cache, til de behandlede dataelementer, "Your milage may vary!" (Charles E. Leiserson). Nogle af Intel nyere bibliotekerkan noget man ikke kan hacke sig til ret hurtigt. Mit yngligeksempel er kvadratisk matrix-multiplikation: AxB=C=A .Bt, hvor Bt=transposed(B) og "." er den tilsvarende multiplikation af to liniære rækker, samme komplexitet, men elementiden er en anden - og det kan ses! Spændende serie, men code size og performance?

6
25. april 2020 kl. 07:27

Det er der også andre sprog der er, igen fx D og Nim.

Benchmarken siger sandsynligvis ikke noget, om sprogets hastighed. Deres mål er, at presse maksimal performance, ud af kompileren. Det opnår de, ved at skrive kode, som ingen normalt ville gøre. Koden de benchmarker, er ikke ækvivalent på tværs af sprog, så det er en test af biblioteker. Havde koden været ækvivalent, ville det have været, en test af kompiler frontends. Givet den samme kompiler backend, LLVM i Rusts tilfælde, vil sprogenes performance potentiale, være det samme.

Der findes denne, måske mere relevante benchmark, hvor målet er at se hvordan ideomatisk kode performer: https://github.com/kostya/benchmarks/blob/master/README.md

Det er stadig ikke sprogets hastighed, men burde i det mindste, være mere realistisk, omkring den performance, man bør forvente.

Ja det bliver spændende. Jeg gætter på en mindre nedgang i linjer, mod en mængde, programmets størrelse taget i betragtning, unødig kompleksitet. Men det kommer an på, hvor gode biblioteker, der er til rådighed. Med det rigtige bibliotek til Java, og det forkerte til Rust, vil Java jo alligevel være det "hurtigste sprog".

4
24. april 2020 kl. 17:15

Et programmeringssprog er et værktøj. Jeg vil hellere beskære min hæk, med en motoriseret hækkeklipper, end en hækkesaks. Hvad gør Rust, til et godt valg, til denne opgave? Eller er motivationen blot, at lære et nyt sprog? I så fald, kunne det måske også være en idé, at prøve flere sprog, fx D og Nim.

2
24. april 2020 kl. 10:08

Det her er det bedste mini serie har fulgt med i, nå ja, i meget lang tid.

1
24. april 2020 kl. 07:47

Husk

  1. ldd -v /bin/grep

når du skal finde /bin/grep's størrelse.