I compiled American Fuzzy Loop for macOS yesterday and the performance

>Reddit: the show
go back

>>61340111
Reddit wasted those trips.

>>61340124
>>61340152
>trying to derail a decent technology thread because the picture has something you don't like in it
Hmmm I wonder why /g/ is such shit

>>61340164
because of dumb phone posters like you

>>61340170
calling someone a phoneposter because you disagree with what they say is not an argument

>>61340188
good job turning off the auto capitalization kid

>>61340199
>capitalization automatically means phoneposting
I get that phones do that sort of thing but how is it proof?

>>61340111
Did you look up your questions first?

>>61340265
Yes, there are general statements, but nothing specific. I'm aware of the possibility that it is a variety of factors in unison, but it appears no one has really dug into XNU source and pulled out an answer.

>>61340164
Is ironic how /g/ absolutely hates while being completely useless themselves. I'd wager that if I had posted this to some systems programming subreddit I'd have a thread filled with constructive responses by now. Why do I even come here anymore?

File: 1492464790738.png (41KB, 507x832px) Image search: [Google]

41KB, 507x832px

>>61340111
>mac
Found your problem.

How did you benchmark your 'performance'. At least prove that you did your part of work. Where do you think the bottleneck is. How you tested/measured it.

>>61340667
Ran the compiled AFL against a sample binary with known flaws. Took AFL around 4x longer on average compared to Linux 4.10.x on Fedora 25.

The AFL github has an issue citing XNU's extremely shit process/thread forking as the primary problem, but there are no details beyond that. Creating an artificial benchmark to confirm that only gives me a "yep, it's slow" answer. I'm looking for a more detail driven answer, perhaps explaining why Apple chose not to optimize something like this.

all >hurr durr Applel/mac/macOS/steve jebs memes will be discarded.

>>61340609
The lack of kernel documentation is purposeful. Apple doesn't want developers tinkering with the private parts of the kernel and fucking shit up.
I agree that HFS is shit, luckily the horrors are almost behind us.

It is also possible to modify, compile, and run your own (modern) XNU kernel. A simple google would have showed this.

Darwin is weird, but that's because of the legacy from which it came. The mach portions and APIs come from nextstep, BSD provides the *nix interface, and I/O Kit provides kernel extensibility. It's complex yes, and questionable in some places, but it's a very unique and well-executed kernel design. While his input is useful,he's not the god many people worship him as. I doubt Linus would know anything about cohesive or stable design, look at the fucking mess that he calls a kernel. He's an accidental revolutionary, whose kernel happened to be in the right place at the right time.

>>61340801

Since it seems nobody else on this board knows anything but how to shitpost, here's some helpful info:

Forking on XNU consists of either forking via the mach portion of the kernel using mach_task(), or the mach *and* BSD portions of the kernel using pthreads. Now the kernel provides functions exposed to userspace in an effort to speed up some operations, but certain things - like pthreads - still rely partially on userspace code. Calling a pthread fork forces the kernel to rapidly copy pages from memory and to perform at least two context switches: one to execute the mach_task and another to switch back to the userspace thread (In this case AFL). XNU is notoriously slow when it comes to context switches and moving large amounts of virtual memory around, so a program that relies on both of those things repeatedly in rapid succession naturally performs terribly. It's why Apple has gone through so much trouble to abstract away threading as much as possible with things like timers, GCD, and cocoa threads. In addition, the system performs many checks during execution to protect the itself from malicious or bad code. This ranges from things like lock state checking to in the kernel to userspace isolation via sandboxd. It a big system with a lot of moving parts, so there is no definitive or easy answer.