Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Latency of fadda #7

Open
rj-jesus opened this issue Mar 8, 2022 · 1 comment
Open

Latency of fadda #7

rj-jesus opened this issue Mar 8, 2022 · 1 comment

Comments

@rj-jesus
Copy link

rj-jesus commented Mar 8, 2022

According to the specification of the A64FX (v1.6), the latency of a fadda for doubles (<V> = D) with VL = 512 is 9 / 6 / ([1,2]9 / [1]6) x 6 / [1,2]9. I believe this should correspond to an overall latency of 9 + (9+6)*6 + 9 = 108, assuming the second micro-op can execute alongside the first. However, the actual latency of faddas as measure on hardware seems to be 72.

Could anyone please help me understand where this discrepancy is coming from?

-Ricardo

P.S. Here's the program I'm using to measure the latency of faddas:

//----------------------------------------------------------------------------
// Copyright (C) 2022 Ricardo Jesus, UK. All rights reserved.
//
// Redistribution and use of this software, with or without modification, is
// permitted provided that the following conditions are met:
//
// 1. Redistributions of this script must retain the above copyright
//    notice, this list of conditions and the following disclaimer.
//
// THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED
// WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
// EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
// PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
// OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
// WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
// OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
// ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
//----------------------------------------------------------------------------

#include <iostream>
#include <chrono>
#include <cstdint>
#include <cstdlib>

extern "C" void kernel(std::uint64_t);

asm(R"(
    .global kernel
kernel:
    fadda d0, p0, d0, z0.d
    fadda d0, p0, d0, z1.d
    fadda d0, p0, d0, z2.d
    fadda d0, p0, d0, z3.d
    fadda d0, p0, d0, z4.d
    fadda d0, p0, d0, z5.d
    fadda d0, p0, d0, z6.d
    fadda d0, p0, d0, z7.d
    sub x0, x0, 1
    cmp x0, #0
    bgt kernel
    ret
)");

int main(int argc, char *argv[])
{
    using namespace std;

    const double clock = 1.8e9;  // GHz
    const uint64_t iters = 1000000ul;  // > 0
    const uint64_t insts = 8 * iters;  // match kernel asm

    auto start = chrono::steady_clock::now();
    kernel(iters);
    auto end = chrono::steady_clock::now();

    chrono::duration<double> elapsed_seconds = end-start;
    chrono::duration<double> lat = elapsed_seconds*clock/insts;

    cout << insts << " fadda in " << elapsed_seconds.count() << " seconds" << endl;
    cout << "Latency: " << lat.count() << " cycles" << endl;

    return 0;
}
@mikio-hondou
Copy link
Collaborator

Thank you for pointing out.
After checking the document, we found that the latency information of a fadda was incorrect.
We fixed the document at v1.8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants