# Why is a staggering 30% of the CPU profile not accounted for?

**URL:** <https://discourse.julialang.org/t/why-is-a-staggering-30-of-the-cpu-profile-not-accounted-for/97478>\
**Category:** Performance\
**Created:** [April 14, 2023, 4:03pm UTC](https://discourse.julialang.org/t/why-is-a-staggering-30-of-the-cpu-profile-not-accounted-for/97478 "2023-04-14T16:03:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [April 14, 2023, 4:03pm UTC](https://discourse.julialang.org/t/why-is-a-staggering-30-of-the-cpu-profile-not-accounted-for/97478/1 "2023-04-14T16:03:14Z")

</div>

How come that 30% (on the right-hand side) of the CPU performance profile here is not accounted for?

 ![cpu_profile](https://global.discourse-cdn.com/julialang/original/3X/0/1/013e4f2e90e6ce97ae39ad8fcf0699144fecf63c.webp)

This is in the preview version of the (VS) Code Julia extension, with Julia 1.9.0-rc2, on Linux.

This seems reproducible so far, so here’s a script if someone wants to reproduce:

```julia
# Might be too small, some runs fail with Tulip's ITERATION_LIMIT
setprecision(BigFloat, 6 * 2^7)

import FindMinimaxPolynomial, Tulip, MathOptInterface
const FMP = FindMinimaxPolynomial
const MMX = FMP.Minimax
const mmx = MMX.minimax_polynomial
const MOI = MathOptInterface

function make_lp()
  lp = Tulip.Optimizer{BigFloat}()
  MOI.set(lp, MOI.RawOptimizerAttribute("IPM_IterationsLimit"), 2000)
  MOI.set(lp, MOI.RawOptimizerAttribute("Presolve_Level"), 0)
  lp
end

monomials_4_odd = 1:2:7
itv_sin = (big"0.1", big"0.2");
@profview mmx(
  make_lp,
  sin,
  (itv_sin,),
  monomials_4_odd,
);
@profview mmx(
  make_lp,
  sin,
  (itv_sin,),
  monomials_4_odd,
);

```

I used the development version of the `FindMinimaxPolynomial` package, commit `0161913770ed36a5ca79f87be7dc8c99bfc10800` on the `main` branch. EDIT: a new version, v0.2.1, is now registered with the general registry, adding the package is enough.

EDIT: increasing the `n` parameter with `Profile.init` doesn’t help.

---

<div class="post-metadata">

**Author:** ![mikkoku](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikkoku/32/16274_2.png) [@mikkoku](https://discourse.julialang.org/u/mikkoku)\
**Post date:** [April 15, 2023, 8:47am UTC](https://discourse.julialang.org/t/why-is-a-staggering-30-of-the-cpu-profile-not-accounted-for/97478/2 "2023-04-15T08:47:52Z")

</div>

Recently I encountered a similar profile. In my case the missing portion was C calls (hidden by default) that for some reason were not attached to where I would think they should be.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [April 15, 2023, 10:23am UTC](https://discourse.julialang.org/t/why-is-a-staggering-30-of-the-cpu-profile-not-accounted-for/97478/3 "2023-04-15T10:23:42Z")

</div>

Thanks! Executing the following after the code in the original post makes it clear that the “not accounted for” samples were spent mostly in the GMP (GNU Multiple Precision) C library:

```julia
view_profile(C = true)

```

It’s too bad that the call graph is incorrect though, with the libgmp calls belonging to `root` directly. It would be nice to know where were the calls made from. The GMP calls in question were all architecture-specific (AMD-specific) calls, so I guess GMP does some kind of runtime dispatch which confuses the Julia profiler.