Assessment of the difficulty in porting CPU architecture for nfft #137
Comments
|
I agree that the porting complexity should be very simple. The NFFT
package already works "as is" on the Debian architecture RISCV64 and
also the unit tests validate the numerical accuracy of the results on
this architecture, see the logs
https://buildd.debian.org/status/fetch.php?pkg=nfft&arch=riscv64&ver=3.5.3-1&stamp=1691323460&raw=0
Am 17 Nov 2023 um 09:06 schrieb xuanbao:
…
Hello everyone! I am working on implementing a tool to assess the
complexity of CPU architecture porting. It primarily focuses on RISC-V
architecture porting. In fact, the tool may have an average estimate
of various architecture porting efforts.My focus is on the overall
workload and difficulty of transplantation in the past and future,even
if a project has already been ported.As part of my dataset, I have
collected the *nfft* project. *I would like to gather community
opinions to support my assessment. I appreciate your help and
response!* Based on scanning tools, the porting complexity is
determined to be simple, with a small amount of code related to the
CPU architecture in the project. Is this assessment accurate?Do you
have any opinions on personnel allocation and consumption time？ I look
forward to your help and response.
—
Reply to this email directly, view it on GitHub
<#137>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEHP7F75MHBJEBEG2O7EJ7DYE4LJFAVCNFSM6AAAAAA7PMSNQOVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4TQNJQG43DGMQ>.
You are receiving this because you are subscribed to this
thread.Message ID: ***@***.***>
--------------ah5KF2xkeShjv4RfxURyrF8w
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I agree that the porting complexity should be very simple. The NFFT
package already works "as is" on the Debian architecture RISCV64 and
also the unit tests validate the numerical accuracy of the results
on this architecture, see the logs
<a class="moz-txt-link-freetext" href="https://buildd.debian.org/status/fetch.php?pkg=nfft&arch=riscv64&ver=3.5.3-1&stamp=1691323460&raw=0">https://buildd.debian.org/status/fetch.php?pkg=nfft&arch=riscv64&ver=3.5.3-1&stamp=1691323460&raw=0</a><br>
<br>
<br>
<div class="moz-cite-prefix">Am 17 Nov 2023 um 09:06 schrieb
xuanbao:<br>
</div>
<blockquote type="cite"
***@***.***">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p dir="auto">Hello everyone! I am working on implementing a tool
to assess the complexity of CPU architecture porting. It
primarily focuses on RISC-V architecture porting. In fact, the
tool may have an average estimate of various architecture
porting efforts.My focus is on the overall workload and
difficulty of transplantation in the past and future,even if a
project has already been ported.As part of my dataset, I have
collected the <strong>nfft</strong> project. <strong>I would
like to gather community opinions to support my assessment. I
appreciate your help and response!</strong> Based on scanning
tools, the porting complexity is determined to be simple, with a
small amount of code related to the CPU architecture in the
project. Is this assessment accurate?Do you have any opinions on
personnel allocation and consumption time？ I look forward to
your help and response.</p>
<p
style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>
Reply to this email directly, <a
href="#137"
moz-do-not-send="true">view it on GitHub</a>, or <a
href="https://github.com/notifications/unsubscribe-auth/AEHP7F75MHBJEBEG2O7EJ7DYE4LJFAVCNFSM6AAAAAA7PMSNQOVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4TQNJQG43DGMQ"
moz-do-not-send="true">unsubscribe</a>.<br>
You are receiving this because you are subscribed to this
thread.<img
src="https://github.com/notifications/beacon/AEHP7F3SSFXAGHYZTU5XXMLYE4LJFA5CNFSM6AAAAAA7PMSNQOWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHHOHWOOA.gif"
alt="" moz-do-not-send="true" width="1" height="1"><span
style="color: transparent; font-size: 0; display: none;
visibility: hidden; overflow: hidden; opacity: 0; width: 0;
height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
ID: <span><NFFT/nfft/issues/137</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#137",
"url": "#137",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
</blockquote>
<br>
</body>
</html>
--------------ah5KF2xkeShjv4RfxURyrF8w--
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello everyone! I am working on implementing a tool to assess the complexity of CPU architecture porting. It primarily focuses on RISC-V architecture porting. In fact, the tool may have an average estimate of various architecture porting efforts.My focus is on the overall workload and difficulty of transplantation in the past and future,even if a project has already been ported.As part of my dataset, I have collected the nfft project. I would like to gather community opinions to support my assessment. I appreciate your help and response! Based on scanning tools, the porting complexity is determined to be simple, with a small amount of code related to the CPU architecture in the project. Is this assessment accurate?Do you have any opinions on personnel allocation and consumption time？ I look forward to your help and response.
The text was updated successfully, but these errors were encountered: