[haiku-development] Re: On timeslices and cycles
- From: Urias McCullough <umccullough@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 16 Mar 2009 15:24:05 -0700
On Mon, Mar 16, 2009 at 7:18 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> My point isn't that hard affinity can harm the system -- it can't -- but that
> it will be used in cases where it doesn't make sense, thus slowing down the
> application using it. My general assumption being that in most cases the OS
> will have a better idea about the hardware it is running on than an
> application (respectively its developer). Hence the OS should make the
> scheduling decisions.
I somewhat disagree, but let's not go down that path in the interest
of staying within reasonable discussion boundaries :)
> I have no doubt that there are situations where hard affinity can be put to
> good use, but it's a pretty crude API. I'd rather see an API that allows the
> application to give hints about the resource usage profile of its threads and
> let the OS do that actual scheduling.
I think this is where the question becomes: Do the applications define
the purpose of the OS, or does the OS define the purpose of the
applications? Maybe that's too abstract... but ultimately, it's my
opinion that if a user wishes to run an application for the purpose of
accomplishing what that application was designed to accomplish - then
the OS shouldn't try to prevent it from doing so.
Either way, I think we have come to the conclusion that while hard
affinity *might* have a valid purpose, a minority people believe this
is so, and thus, it's not likely to be implemented. We can probably
leave it at that, no? I mean: this will ultimately boil down to:
"Patches welcome" (or at least I would hope they would be if someone
was to actually put together a reasonable solution.)
>> > Besides, from an environmental
>> > point of view, I'm not even sure I still like those projects.
>>
>> Yeah, I'm beginning to see where you come from. Wasting kWh upon kWh for
>> rebuilding Haiku over and over and over again is Good(TM), but
>> participating in DC efforts for finding cures to AIDS and cancer is bad.
>> Because Haiku is more important than human lives?
>
> I think you're getting carried away a bit. This was merely a side remark and
> I was mostly thinking of cryptographic projects like cracking RC5 keys.
That happens to be one of maybe a hundred different projects that I
have contributed CPU cycles to... I'll admit that SETI@Home and RC5-72
are probably two of the least useful projects out there, and yet,
they're two of the more popular ones.
It just happens that RC5-72, and OGR-27 are two of the *only*
distributed computing projects that have a Haiku-specific client at
this point - thus people who wish to demonstrate the "common" usage of
Haiku to the rest of the distributed computing world are currently
limited to these projects at this moment.
http://stats.distributed.net/misc/platformlist.php?project_id=27&view=tcoy
http://stats.distributed.net/misc/platformlist.php?project_id=8&view=tcoy
But I digress...this is indeed way off topic.
If we do get a sys/shm.h I may have another go at porting the BOINC
client - which opens a lot more interesting project potential :)
- Urias
Other related posts:
