Sujet : Re: Instruction Tracing
De : cr88192 (at) *nospam* gmail.com (BGB)
Groupes : comp.archDate : 10. Aug 2024, 23:49:42
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v98qq8$ukip$1@dont-email.me>
References : 1 2
User-Agent : Mozilla Thunderbird
On 8/10/2024 2:41 PM, John Dallman wrote:
In article <2024Aug10.121802@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
IIRC IA-64 has no FP division.
You recall correctly. It has an "approximation to reciprocal" instruction,
which gives you about 8 bits of precision, and then requires the compiler
to generate Newton-Raphson sequences. Intel's manual, 2010 edition, says
this is advantageous because users can generate only the precision they
need. Writing Itanium assembler for customised precision? Not many people
would have wanted to do that in 2001, let alone 2010.
In, I think, 1996, my employers had visitors from Intel trying to
persuade us to adopt their C/C++ compiler for IA-32. They had been able
to speed up one of our competitors' code by a factor of two, and hoped to
do the same for us.
They failed. We already had that factor of two, which was "ordinary
compiler optimisation." That competitor had some rather odd coding
standards at the time, which meant most compilers failed if asked to
optimise their code. Someone from Intel had stayed at their site for most
of a year, reporting the bugs and getting them fixed until Intel's
compiler could optimise the code.
While visiting us, Intel asked what may have been a significant question
about the mixture of floating-point arithmetic instructions we used. We
didn't have precise figures, but were sure that we used at least as many
square roots as divides. IA-64 does square roots like divides, with a
starter approximation and Newton-Raphson sequences. Slowly, because the
N-R instructions all depend on the previous instruction, and can't be run
in parallel.
FWIW:
In my case it is similar (if not using the FDIV) instruction, where there are approximations for divide / reciprocal / square root.
Meanwhile, saw a video recently where someone had ported Doom to a 233 MHz PowerPC (running Windows NT4) machine and, its performance was not good...
Not obvious is what combination of factors conspired to cause Doom to apparently run at single-digit framerates.
Video mentioned that it was drawing using GDI calls, but this by itself wouldn't explain the level of slowness seen in the video.
Like, presumably, this would require around 90% + of the clock cycles going into overhead, which seems a bit much.
Reference:
https://www.youtube.com/watch?v=LAkSJ-HqKw8John