<trungnt2910[m]>
Can't because 1. I don't know how and searching didn't work, only saw a way to enable summary and 2. Timing benchmark is broken on WSL1 for some reason.
<waddlesplash>
bleh
<trungnt2910[m]>
Well using WSL2 would just make things abysmally slower on VMWare.
<waddlesplash>
you don't have a Linux VM in your VMware?
<trungnt2910[m]>
I have two but both are nuked after upgrading packages.
<waddlesplash>
lol, classic linux
<trungnt2910[m]>
Some pthread assert failure in glibc.
<jmairboeck>
trungnt2910[m]: Have you tried running Haiku directly on Hyper-V instead of VMware?
<trungnt2910[m]>
jmairboeck: I don't have the money to buy Windows Pro edition...
<trungnt2910[m]>
And trying to add Hyper-V using Windows cabinet hacks broke my Windows installation once. Had to install everything again from scratch.
HaikuUser has joined #haiku
HaikuUser has quit []
<jmairboeck>
Oh, I didn't realize you could run WSL 2 on the Home Edition without the real Hyper-V.
<x512[m]>
WSL 1
<waddlesplash>
you can run WSL 2 on Home without real hyper-v
<waddlesplash>
that's using Windows Hypervisor Platform
<waddlesplash>
trungnt2910[m]: appears syscall overhead on Linux running in VMware is around 76.5ns
<trungnt2910[m]>
<trungnt2910[m]> "I have two but both are nuked..." <- And somehow setting up Linux VMs takes an abysmally long amount of time regardless of distro.
<trungnt2910[m]>
Compared to extracting WSL1 rootfs tarballs.
<waddlesplash>
uh. maybe that's your poor VMware performance :)
<trungnt2910[m]>
Hmm maybe VMWare blocked some serial keys obtained in the Vietnamese black market...
<waddlesplash>
lol
<trungnt2910[m]>
Maybe they throttled the performance because of that?
<waddlesplash>
who knows
<waddlesplash>
maybe try using QEMU with Windows Hypervisor Platform
<waddlesplash>
see if that performs better
<waddlesplash>
though I'm not sure that works right with Haiku anyway, other users may have reported problems, can't recall
<waddlesplash>
trungnt2910[m]: syscall overhead on my Haiku VM is 95ns, compared to Linux 58ns
<waddlesplash>
that's not great, but it's also not terrible either
<waddlesplash>
I would expect Linux syscall entry to be optimized almost to the point of insanity
<waddlesplash>
meanwhile on WSL1, on the host (yes, same machines with VMs running): overhead 143ns
<trungnt2910[m]>
<waddlesplash> "uh. maybe that's your poor..." <- Or probably the Australian internet. Linux installer `iso`s seem to like downloading stuff.
<waddlesplash>
so, VMware is outperforming WSL1 on raw overhead
<waddlesplash>
no I mean nothing else is using AMD-V
<waddlesplash>
like Hyper-V or Windows Hypervisor Platform
<OscarL>
Letme try VMware 16
<waddlesplash>
OscarL: oh, well, VBox and VMware can't both have virtualization
<OscarL>
I won't be trying both at the same time, of course :-(
<OscarL>
s/:-(/:-)/
<waddlesplash>
I mean installed
<waddlesplash>
I think
<waddlesplash>
there can only be one kernel-level driver interacting with AMD-V
<waddlesplash>
Windows Hypervisor Platform / Hyper-V takes precedence
<waddlesplash>
if it's not installed/enabled, I don't know whether VMware or VirtualBox win out next
<waddlesplash>
whichever "loses" will have massively degraded performance
<OscarL>
I've no Hyper-V installed, and I haven't noticed any perf difference in VBox after I installed VMware.
<waddlesplash>
well then it's probably Vbox being Vbox lol
<waddlesplash>
VMware is way more performant
<OscarL>
not by that much on this PC.
<OscarL>
I've tried.
<waddlesplash>
again: do you have AMD-V enabled in BIOS?
<OscarL>
yes, of course.
<waddlesplash>
huh. idk then
<OscarL>
For compile tasks, for example, VBox gives me around 75% of bare metal performance. VMware around 80% and Qemu on some old ass Ubuntu, around 85%.
<OscarL>
(that's comparing "time" outputs)
<Habbie>
qemu or qemu-kvm?
<waddlesplash>
but that syscall overhead is insane
jjido has joined #haiku
<waddlesplash>
especially compared to bare metal
<OscarL>
waddlesplash: that's true.
<waddlesplash>
literally 30 times worse!
<OscarL>
Habbie: IIRC, the kvm one.
<OscarL>
VMware 16, Win10, Max perf:
<Habbie>
OscarL, ack
<Habbie>
OscarL, 85% would be incredible without it :)
<OscarL>
avg: 159.06400ns
<waddlesplash>
now that's more reasonable!
<waddlesplash>
so it's just VirtualBox being VirtualBox
<Habbie>
vbox should just get in the sea
<OscarL>
reasonable? I get 158ns on bare metal :-D
<waddlesplash>
it's a whole 1ns worse, less than 1% :p
<Habbie>
noise
<OscarL>
"reasonable?" as in.... actually amazing.
<OscarL>
I guess CPU crunch and I/O "performace" render most of those differents moot for my use case.
<OscarL>
VMware on "Balanced" power profile: "avg: 205.479000ns"
Blendie has quit [Quit: Connection closed for inactivity]
<Habbie>
nice
<OscarL>
s/on/with Win10 on/
<OscarL>
erysdren: those are in "IOM" (Icon-O-Matic) format, if I'm not mistaken.
<erysdren>
ahh
<erysdren>
so i'm gonna get a friend to make a Haiku-esque Quake icon
<erysdren>
what format is that vector in inside QuakeSpasm.rdef.in?
<OscarL>
you can export to .hvif (and even to the .rdef "vector-icon" format) using Icon-O-Matic.
<OscarL>
.hvif in text-safe format.
<erysdren>
so let's say they can make it as an SVG and then i can import it, touch it up if necessary, and ad to QuakeSpasm.rdef?
<OscarL>
IOM can import SVG, and you can save it to ".iom" (extension not really needed, of course), and "export" to "hvif" or "hvif .rdef"
<erysdren>
thanks
<OscarL>
np!
<erysdren>
anything else i should put together for my HaikuPorts PR?
<OscarL>
Just what Begasus already commented, I think.
<OscarL>
erysdren: and the comment that I've added a couple hours ago.
<OscarL>
do you plan to squash/clean up your upstream PR, I assume? (at least to remove those commits that cancell each other :-D).
<erysdren>
i wasn't sure how to do that in my already existing PR
<OscarL>
you can force push after you cleaned up your commit history.
<Begasus>
'lo erysdren OscarL
<OscarL>
Hey Begasus :-)
<Begasus>
erysdren, if you could address the comments there (didn't check a build) I'm fine (hope) :)
<erysdren>
so app:quakespasm instead of cmd:quakespasm?
<OscarL>
yeah, with no "$secondaryArchSuffix".
<selfish->
Hello
<erysdren>
so
<selfish->
Is any package supposed to provide a 'gl' pkg-config module? glew wants glu, which wants gl, but mesa_devel has only osmesa and egl
<jmairboeck>
That depends on whether you want to hypothetically support secondary architectures for other primaries as well (when we finally get 32 bit support on x86_64)
<OscarL>
what I think it is needed, is better/simpler wording on that section of the Guideline. or a more concrete example.
<OscarL>
maybe it is my poor english (and broken brain) that makes me always trip over that section.
<Begasus>
I think it's something introduced by fbrosson?
<OscarL>
Either we need to add an extra "if [" (I've done that already on a couple of recipes), or you go against the "Ordering", as in this chocolate-doom recipe PR :-/
<Begasus>
at least for me it's pointless at this time (even if we get other primary architectures I doubt those will include a secondary ...
<jmairboeck>
If the package provides only commands, there is no need to use secondaryArch for anything else than x86 on x86_gcc2, because there is no need to have multiple versions installed in parallel
<Begasus>
well, it's not a big deal, I can live with that, just my 2 cents :)
<jmairboeck>
if there are libraries, the situation could become different
<Begasus>
right, and even then, the ammount of gcc2 libraries will get lower in time
<jmairboeck>
then we could have x86 (and maybe x86_gcc2) as secondary arch on x86_64 primary
<Begas_VM>
OscarL, still getting no mudule sphinx found running the test for ...
<OscarL>
I can go whatever way, too Begasus, just having some confusion about what I think are conflicting/confusing guidelines/examples.
<Begas_VM>
been there OscarL :)
<OscarL>
Begas_VM: re: sphinx: alright, then. Thanks for testing!
<Begas_VM>
k, time to close some things here
<jmairboeck>
but I think for BeOS compatibility, that would need a hack in packagefs, so that for 32 bit teams, the x86_gcc2 subdir is not visible. Something similar to what Windows does with "Program Files (x86)" and "SysWoW64"
Begas_VM has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
Why the change on "cp $sourceDir/Quake/quakespasm.pak $dataDir/QuakeSpasm/quakespasm.pak" vs "cp $sourceDir/Quake/quakespasm.pak $dataDir/QuakeSpasm" ? (should be the functionally the same? , or I missed that part of the chat)
<Begasus>
missed that too then OscarL
<Begasus>
second one should be good
<Begasus>
same for the html file :)
<OscarL>
Do patch sets need black lines separating "Subject:" from the actual patch?
<Begasus>
erysdren, doing it as it's done for the binary should be fine
<botifico>
[haikuports/haikuports] augiedoggie cbebf4f - ugrep: update to 3.12.0 (#8787)
<Begasus>
me is closing up for today, will see progress in the morning :)
<OscarL>
later Begasus!
<Begasus>
cu peeps! :)
Begasus has quit [Quit: Leaving]
<OscarL>
"Warning: games-fps/quakespasm-0.96.0~git is overruled by duplicate in games-fps - please remove one of them" LOL WUT? (already removed the dep info file.
<OscarL>
ah... I stil have my previous version of the recipe liying around elsewhere on the hp tree :-D
jmairboeck has quit [Quit: Konversation terminated!]
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
<OscarL>
QuakeSpasm builds, installs, and runs OK with latest changes.
<OscarL>
mmm, but only if I use "hp -G quakespasm" to build it (it fails to apply the patchset without -G, that's a first)
<OscarL>
guess it DOES needs those extra blank lines then?
<OscarL>
(my bad, a failed "hp -e" left that file empty)
<OscarL>
erysdren: **ultimate nitpick**: you can run "hp -c quakespasm", "hp -b quakespasm", "hp -e quakespasm", for a slighly smaller .patchset (avoids "diff-stats" lines).
<OscarL>
btw, thanks again for working on this one :-)
<OscarL>
just to make waddlesplash scream: VBox, Win10 on eco mode.... "> ./syscall-overhead" "avg: 13827.347000ns" :-D
<Habbie>
ouch
townsfolkPravda has quit [Quit: townsfolkPravda]
AlaskanEmily has quit [Remote host closed the connection]
Ampilin has joined #haiku
Ampilin has quit [Quit: Vision[]: i've been blurred!]