Opened 16 months ago

Last modified 16 months ago

#54342 new update

atlas @3.10.2_2: update to 3.10.3

Reported by: l2dy (Zero King) Owned by: Veence (Vincent)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: Schamschula (Marius Schamschula)
Port: atlas

Description


Change History (3)

comment:1 Changed 16 months ago by Veence (Vincent)

Yup, will do that tomorrow. Thanks for the heads-up!

comment:2 Changed 16 months ago by Schamschula (Marius Schamschula)

Cc: Schamschula added

comment:3 Changed 16 months ago by Veence (Vincent)

Sorry, got somehow a but stuck-up.

I am facing a dilemma here. Trying to explain:

Atlas works like this: it has a certain number of "kernels", that is C or ASM versions of a given BLAS function. It runs all of them, measures execution times, then picks the most efficient. So atlas is highly focussed on optimisation. That leads to a very high CPU usage.

However, since MacOS 10.11 I think, Apple has added a functionality within the kernel, whereby when CPU usage is too high for a given period of time, the task responsible for the “overload” gets docked and put on the back burner. Which, in other words, means that the task stalls for extended periods of time, and thus its execution time becomes irrelevant, which totally defeats Atlas's purpose.

I had begun to search for a way to bypass this policy, got a lead but then was "taken away by life" and forgot about it. I'm going to pick up the slack and see what I can find. As far as I remember, it involved some sort of delicate operation only a kernel extension could do, i.e. setting a special flag of a CPU register.

As long as that hasn't been fixed, I wouldn't recommend using Atlas. Rather turn to Apple's libraries in the Accelerate framework. As far as I can tell, the API should be 100% compatible.

Sorry again for being so long to answer and coming back with such a wishy-washy excuse.

Note: See TracTickets for help on using tickets.