- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a significany drop in performance between ifort and ifx. For Intel CPUs:
Intel(R) Xeon(R) Gold 6246R CPU @ 3.40GHz (16+16=32 core)
Intel ifort 2021.13.1
CFLAGS= -free -warn all -diag-disable=10448 -nogen-interfaces -no-prec-div -O3 -fp-model=fast=2 -xHost
real 124m20.650s
user 3049m40.783s
sys 10m40.430s
Intel ifx 2025.3.0
CFLAGS= -free -warn all -nogen-interfaces -O3 -xHost -qopenmp
real 162m36.896s
user 3966m5.817s
sys 12m34.195s
albeit faster than gfortran at 216m. The problem is double precision complex algebra. The code
is also using openmp.
In addition, ifort runs much faster on AMD CPU:
AMD Ryzen Threadripper PRO 7975WX @ 4.0GHz 32-Cores
Intel ifort 2021.13.1
CFLAGS= -free -warn all -nogen-interfaces -diag-disable=10448 -Ofast -march=SSE4.2,CORE-AVX2,znver4 -qopenmp
real 67m37.749s
user 1744m37.811s
sys 13m21.562s
Intel ifx 2025.3.0
CFLAGS= -free -warn all -nogen-interfaces -O3 -Ofast -march=znver4 -qopenmp
real 113m5.164s
user 2487m13.638s
sys 13m46.812s
Intel seems to have removed some of the optimization features for AMD processorts from
ifx....can't use SSE4.2,CORE-AVX2 anymore.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please share a code showing this performance drop?
Note that LLVM IR doesn't have complex data types and thus code with complex type algebra is a known issue vs ifort (there Intel had native complex type support on the proprietary IR level). It should be improved in the next major release of ifx.
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The report from which the beam model originated is:
Post-Tensioned Box Girder Design Manual, June 2016.
https://www.fhwa.dot.gov/bridge/concrete/hif15016.pdf
According to the text in the report, in Chapter 7 – Longitudinal Analysis & Design:
"Additional nodes (3, 15, 17, 22, 35, and 47) were added for ease in using the results of the analysis. These nodes coincide with the design cross section for shear (d or h/2 from the centerline of pier, depending on the approach in finding nominal capacity). Two other nodes (1 and 49) were added behind the first and last bearing locations to facilitate the modeling of post-tensioning consistent with end anchor details."
The approach taken above seems to be an attempt at mesh refinement.
@JohnNichols Would you be willing to share the code so that I could have a go at running the model?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »