[OT] GCC vs Intel C++ compiler benchmark

[OT] GCC vs Intel C++ compiler benchmark

[Claus Fischer]

The rather biased article on http://www.open-mag.com/754088105111.htm
compares Intel's C++ favourably to GCC, without disclosing many
enlightening details.

I'm not concerned with that but with the notable OS difference
between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a CPU bound
benchmark should see less than 1 % influence from OS and C library.
The graphics shows roughly 7% better performance on Windows for the
same (Intel) compiler.

Are there any ABI differences which would justify such a difference?
Register use conventions? Other stuff that you could identify?

Unfortunately the benchmark gives no details about compiler options,
so presumably the answer is `the benchmark is flawed' and `go ask
them'. In this case don't bother to answer.

Claus

-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

Re: [OT] GCC vs Intel C++ compiler benchmark

[Florian Weimer]

Claus Fischer <claus.fischer@clausfischer.com> writes:

> I'm not concerned with that but with the notable OS difference
> between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a CPU bound
> benchmark should see less than 1 % influence from OS and C library.
> The graphics shows roughly 7% better performance on Windows for the
> same (Intel) compiler.
>
> Are there any ABI differences which would justify such a difference?

A few years ago, I noticed the following difference: The Microsoft C
library on Win32 switches the FPU to 64 bit precision.  GNU/Linux uses
80 bit precision, which used to be slower.  Depending on the working
set, VM performance can affect benchmark results, too.  For example,
Windows 95 taints the first-level data cache of the processor
regularly, measurably decreasing performance.

However, I haven't got any current data.

Re: [OT] GCC vs Intel C++ compiler benchmark

[Claus Fischer]

On Sun, Jan 27, 2002 at 01:45:16PM +0100, Florian Weimer wrote:
: A few years ago, I noticed the following difference: The Microsoft C
: library on Win32 switches the FPU to 64 bit precision.  GNU/Linux uses
: 80 bit precision, which used to be slower.  Depending on the working
: set, VM performance can affect benchmark results, too.  For example,
: Windows 95 taints the first-level data cache of the processor
: regularly, measurably decreasing performance.

The FPU settings could indeed help explain it. I doubt that the VM
would work against Linux in a CPU bound benchmark (as long as no
swapping or extensive scheduling between multiple jobs is done).

Claus

-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

RE: [OT] GCC vs Intel C++ compiler benchmark

[Scott Robert Ladd]

I've been a professional compiler reviewer (Computer Language,
Dr. Dobb's, for starters), so I have a bit of experience in this
area -- and in my judgment, the Open Magazine article is badly
written, blatantly biased, and poorly researched.

I've been reviewing C++ compilers since the cfront days; you'll
find my two-month-old comparisons of Intel C++ and gcc at:

	http://www.coyotegulch.com/hpc/reviews.html

I haven't had time to do a really thorough analysis of both
compilers, but my initial impressions and benchmarks can be
found at the web site above. My conclusion: in most tests,
Intel's compiler produces faster code.

Does that mean gcc is dead?

NO. NO. NO.

Compared to the entire gcc package, Intel's compiler is a
singleton, a highly-focused tool that accomplishes good things
in a limited arena. That's it. Intel is not cross-platform, it
only supports two languages, and it makes no attempt to support
the current C99 standard. And, while the Intel compiler is
"free" to a limited extent, it is not a tool that most "free"
software advocates will use for their work (see my writings
about the Intel license.)

Clearly, the Open Magazine review is written by someone who sees
only Intel and Microsoft.
The facts and underlying assumptions are just plain wrong -- but
because this is in a "magazine", it will get far too much
attention from the scaremongers and sensationalists.

Now, in my work, Intel's compiler has replaced gcc for two
purposes. First, I need OpenMP support for a project, something
Intel has and gcc does not. Second, I recently had a
non-commercial project that required Fortran 95, something Intel
can provide that is (as yet) unavailable in gcc. The g95 project
may solve that problem, but it's inclusion in standard gcc
appears to be some time off.

I am OPEN TO SUGGESTIONS regarding my benchmarks. If I have
missed some magic gcc switch, let me know, please. I want to
produce accurate information that helps people make wise
choices.

Different tools for different purposes; gcc is in no danger of
being supplanted by Intel's compiler, but the gcc community does
need to recognize that the Intel compiler has some good points,
too. Articles like the one on Open Magazine, however, do nothing
to help anyone make wise choices about compilers.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
Visit Coyote Gulch, a Free Developer Resource at
http://www.coyotegulch.com


--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
Visit Coyote Gulch, a Free Developer Resource at
http://www.coyotegulch.com



> -----Original Message-----
> From: gcc-owner@gcc.gnu.org
> [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Claus Fischer
> Sent: Sunday, January 27, 2002 06:48
> To: gcc@gcc.gnu.org
> Subject: [OT] GCC vs Intel C++ compiler benchmark
>
>
>
> The rather biased article on
> http://www.open-mag.com/754088105111.htm
> compares Intel's C++ favourably to GCC, without
> disclosing many
> enlightening details.
>
> I'm not concerned with that but with the notable OS difference
> between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a
> CPU bound
> benchmark should see less than 1 % influence from OS
> and C library.
> The graphics shows roughly 7% better performance on
> Windows for the
> same (Intel) compiler.
>
> Are there any ABI differences which would justify
> such a difference?
> Register use conventions? Other stuff that you could identify?
>
> Unfortunately the benchmark gives no details about
> compiler options,
> so presumably the answer is `the benchmark is flawed'
> and `go ask
> them'. In this case don't bother to answer.
>
> Claus
>
> --
> Claus Fischer <claus.fischer@clausfischer.com>
> http://www.clausfischer.com/
>

Re: [OT] GCC vs Intel C++ compiler benchmark

[Andreas Jaeger]

Claus Fischer <claus.fischer@clausfischer.com> writes:

> The rather biased article on http://www.open-mag.com/754088105111.htm
> compares Intel's C++ favourably to GCC, without disclosing many
> enlightening details.
>
> I'm not concerned with that but with the notable OS difference
> between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a CPU bound
> benchmark should see less than 1 % influence from OS and C library.
> The graphics shows roughly 7% better performance on Windows for the
> same (Intel) compiler.

I've done some measurements myself on Linux and the Intel compiler on
Linux is really superior. 


> Are there any ABI differences which would justify such a difference?

The Intel compiler uses different calling conventions for local
functions, can handle whole program optimizations, ...  I don't have a
full list of optimizations that the Intel compiler handles better but
it would be interesting to know what kind of optimizations really help
most for which CPUs.  

GCC 3.1 is in some areas already superior to GCC 3.0 and I expect
further improvements for the future with the ongoing projects like the
AST-Optimizer Branch, the new register allocator, midlevel RTL and the
work on the cfg-branch.

> Register use conventions? Other stuff that you could identify?
>
> Unfortunately the benchmark gives no details about compiler options,
> so presumably the answer is `the benchmark is flawed' and `go ask
> them'. In this case don't bother to answer.

Just have a look at my SPEC pages which also point to some Windows
results using the Intel Compilers as comparison:
http://www.suse.de/~aj,

Note, I didn't check the URL you've given,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [OT] GCC vs Intel C++ compiler benchmark

[Tim Prince]

On Sunday 27 January 2002 04:45, Florian Weimer wrote:
> Claus Fischer <claus.fischer@clausfischer.com> writes:
> > I'm not concerned with that but with the notable OS difference
> > between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a CPU bound
> > benchmark should see less than 1 % influence from OS and C library.
> > The graphics shows roughly 7% better performance on Windows for the
> > same (Intel) compiler.
> >
> > Are there any ABI differences which would justify such a difference?
>
> A few years ago, I noticed the following difference: The Microsoft C
> library on Win32 switches the FPU to 64 bit precision.  GNU/Linux uses
> 80 bit precision, which used to be slower. 
The Intel compilers follow the usual Windows vs linux practice, as you point 
out.  Thus, x87 divide and square root are significantly slower and more 
accurate on linux.  Choosing the sse code generation options eliminates this 
difference. 
> Depending on the working
> set, VM performance can affect benchmark results, too.  For example,
> Windows 95 taints the first-level data cache of the processor
> regularly, measurably decreasing performance.
>
> However, I haven't got any current data.
In my experience, Win2K takes better advantage of L2 cache than linux, 
provided that the machine is dedicated to a single task, the time slice is 
set long, and nothing special is done in linux to take advantage of that.  At 
most a 2% differential there.

Re: [OT] GCC vs Intel C++ compiler benchmark

[Tim Prince]

On Sunday 27 January 2002 04:05, Andreas Jaeger wrote:
> Claus Fischer <claus.fischer@clausfischer.com> writes:
> > The rather biased article on http://www.open-mag.com/754088105111.htm
> > compares Intel's C++ favourably to GCC, without disclosing many
> > enlightening details.
> >
> > I'm not concerned with that but with the notable OS difference
> > between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a CPU bound
> > benchmark should see less than 1 % influence from OS and C library.
> > The graphics shows roughly 7% better performance on Windows for the
> > same (Intel) compiler.
>
> I've done some measurements myself on Linux and the Intel compiler on
> Linux is really superior.
I think you mean superior to gcc on certain benchmarks, when the best options 
are selected.
>
> > Are there any ABI differences which would justify such a difference?
>
> The Intel compiler uses different calling conventions for local
> functions, can handle whole program optimizations, ...  I don't have a
> full list of optimizations that the Intel compiler handles better but
> it would be interesting to know what kind of optimizations really help
> most for which CPUs.
The whole program optimizations remain problematical for large projects.
The peer review system of gcc has performed well in sorting out which 
optimizations are generally applicable and reliable.
>
> GCC 3.1 is in some areas already superior to GCC 3.0 and I expect
> further improvements for the future with the ongoing projects like the
> AST-Optimizer Branch, the new register allocator, midlevel RTL and the
> work on the cfg-branch.
As I understand it, Honza and Andreas have improved gcc-3.1 by 5% over 
gcc-3.0 on 6 of the SPEC CPU2000 benchmarks.  This is HUGE, particularly 
since the improvements they made apply generally, not just to these specific 
benchmarks, and not simply to the specific CPU model they tested.
>

Re: [OT] GCC vs Intel C++ compiler benchmark

[Tim Prince]

On Sunday 27 January 2002 03:48, Claus Fischer wrote:
> The rather biased article on http://www.open-mag.com/754088105111.htm
> compares Intel's C++ favourably to GCC, without disclosing many
> enlightening details.
>
> I'm not concerned with that but with the notable OS difference
> between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a CPU bound
> benchmark should see less than 1 % influence from OS and C library.
> The graphics shows roughly 7% better performance on Windows for the
> same (Intel) compiler.
Both gcc and icc (beta versions available to customers) have improved 
significantly since then.
>
> Are there any ABI differences which would justify such a difference?
> Register use conventions? Other stuff that you could identify?
glibc vs Windows libraries; greater maturity of the Windows version under 
test; different default compiler options
>
> Unfortunately the benchmark gives no details about compiler options,
> so presumably the answer is `the benchmark is flawed' and `go ask
> them'. In this case don't bother to answer.
Probably many of the comparisons are deficient in matching compiler options
gcc				icc			icl
-fstrict-aliasing (default on) 	-ansi (default off)		-Qansi (default off)
according to data type		-pc64 (default 80)	pc64, no choice
-march=pentiumpro		-tpp6			-G6
-march=pentium4 (gcc-3.1)	-tpp7			-G7
-msse2	(gcc-3.1)		-xW			-QxW

and the default for the Intel compilers resembles
 gcc -ffast-math -Os -funroll-loops -mpreferred-stack-boundary=4
to mention only a few of the simpler comparisons which will affect performance

>
> Claus

RE: [OT] GCC vs Intel C++ compiler benchmark - don't forget ia64

[Duraid Madina]

On x86, just use the compiler that doesn't ICE on your code. ;-)

What people shouldn't forget is that Intel C++ is insanely better than
GCC on IA-64 - we're talking "factor of two" here. Whether or not future
IA-64 chips become popular probably doesn't have a whole lot to do with
GCC's performance on that platform, but as it stands, you're pretty
crazy to use GCC for serious production work on IA-64 hardware.

Anyone interested in seeing daily GCC-on-ia64 performance charts, like
aj's? I'll grab the scripts and run them on an itanium box here if you'd
like...

	Duraid

Re: [OT] GCC vs Intel C++ compiler benchmark - don't forget ia64

[marius aamodt eriksen]

On Mon, Jan 28, 2002 at 02:36:54PM +1100, Duraid Madina wrote:

> What people shouldn't forget is that Intel C++ is insanely better than
> GCC on IA-64 - we're talking "factor of two" here. Whether or not future
> IA-64 chips become popular probably doesn't have a whole lot to do with
> GCC's performance on that platform, but as it stands, you're pretty
> crazy to use GCC for serious production work on IA-64 hardware.

well, do keep in mind that the ia-64, being an epic architecture, relies
on the compiler for *much* more optimizations in order to perform well.
this translates to time, effort and availability, all three which intel
has a lot of.

marius.

-- 
marius@{umich.edu,crockster.net,linux.com}, http://www.citi.umich.edu/u/marius

RE: [OT] GCC vs Intel C++ compiler benchmark - don't forget ia64

[Scott Robert Ladd]

> this translates to time, effort and availability, all
> three which intel has a lot of.

Then perhaps it is in gcc's interest to focus on processors
other than Intel's. Has anyone approached AMD about assistance
im making sure that gcc produces the best possible code on
Athlon/Duron processors?

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
Visit Coyote Gulch, a Free Developer Resource at
http://www.coyotegulch.com

RE: [OT] GCC vs Intel C++ compiler benchmark - don't forget ia64

[Daniel Berlin]

On Sun, 27 Jan 2002, Scott Robert Ladd wrote:

> > this translates to time, effort and availability, all
> > three which intel has a lot of.
> 
> Then perhaps it is in gcc's interest to focus on processors
> other than Intel's. Has anyone approached AMD about assistance
> im making sure that gcc produces the best possible code on
> Athlon/Duron processors?

They do, AFAIK.
They contract with SuSE to do this type of thing (optimize gcc for the 
Athlon).
Andreas, Jan, am I wrong?
--Dan

Re: [OT] GCC vs Intel C++ compiler benchmark - don't forget ia64

[Andreas Jaeger]

"Scott Robert Ladd" <scott@coyotegulch.com> writes:

>> this translates to time, effort and availability, all
>> three which intel has a lot of.
>
> Then perhaps it is in gcc's interest to focus on processors
> other than Intel's. Has anyone approached AMD about assistance
> im making sure that gcc produces the best possible code on
> Athlon/Duron processors?

There's an Athlon optimization guide - like there're Intel
optimizations guide out.  I've contacts to AMD folks that can give
sometimes additional insight into optimization issues.

The SPEC testing of GCC I do (http://www.suse.de/~aj/SPEC) uses AMD
Athlon systems.

There're different optimizations for let's say Athlons:
- scheduling etc.  This has been done long ago (included in GCC 3.0
  for Athlon) and smaller adjustments are done over the time.
- generic optimizations that need platform specific support,
  e.g. recently prefetch
- generic optimizations that help all architectures but might have a
  different impact on different architectures

Generic optimizations are most needed and I expect that those are
difficult to convince most companies to support since they help
everybody.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [OT] GCC vs Intel C++ compiler benchmark

[Andreas Jaeger]

Tim Prince <tprinceusa@mindspring.com> writes:

> On Sunday 27 January 2002 04:05, Andreas Jaeger wrote:
>> Claus Fischer <claus.fischer@clausfischer.com> writes:
>> > The rather biased article on http://www.open-mag.com/754088105111.htm
>> > compares Intel's C++ favourably to GCC, without disclosing many
>> > enlightening details.
>> >
>> > I'm not concerned with that but with the notable OS difference
>> > between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a CPU bound
>> > benchmark should see less than 1 % influence from OS and C library.
>> > The graphics shows roughly 7% better performance on Windows for the
>> > same (Intel) compiler.
>>
>> I've done some measurements myself on Linux and the Intel compiler on
>> Linux is really superior.
> I think you mean superior to gcc on certain benchmarks, when the best options 
> are selected.

That's what I meant.

>> > Are there any ABI differences which would justify such a difference?
>>
>> The Intel compiler uses different calling conventions for local
>> functions, can handle whole program optimizations, ...  I don't have a
>> full list of optimizations that the Intel compiler handles better but
>> it would be interesting to know what kind of optimizations really help
>> most for which CPUs.
> The whole program optimizations remain problematical for large projects.
> The peer review system of gcc has performed well in sorting out which 
> optimizations are generally applicable and reliable.

Does anybody have a list of optimizations that are in icc and inferior
or missing in GCC - and would help to improve performance of GCC on
common platforms?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

RE: [OT] GCC vs Intel C++ compiler benchmark - don't forget ia64

[Richard B. Kreckel]

Hi,

On Mon, 28 Jan 2002, Duraid Madina wrote:
> On x86, just use the compiler that doesn't ICE on your code. ;-)

Err, could you please elaborate on this cryptic remark?

> What people shouldn't forget is that Intel C++ is insanely better than
> GCC on IA-64 - we're talking "factor of two" here. Whether or not future
> IA-64 chips become popular probably doesn't have a whole lot to do with
> GCC's performance on that platform, but as it stands, you're pretty
> crazy to use GCC for serious production work on IA-64 hardware.

Duraid, in all fairness: IIRC it was you who made us try our symbolic
computation code in C++ on some commercial compilers (Intel's was one of
them).  You sure remember this was a complete fiasco.  Maybe our code is
just strange, because GCC generates the best code on it.  ;-)

Regards
    -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel@GiNaC.DE>
<http://www.ginac.de/~kreckel/>

Re: [OT] GCC vs Intel C++ compiler benchmark

[Jan Hubicka]

> 
> The rather biased article on http://www.open-mag.com/754088105111.htm
> compares Intel's C++ favourably to GCC, without disclosing many
> enlightening details.
> 
> I'm not concerned with that but with the notable OS difference
> between Linux (SuSE 7.3) and Windows (XP Pro). IMHO a CPU bound
> benchmark should see less than 1 % influence from OS and C library.
> The graphics shows roughly 7% better performance on Windows for the
> same (Intel) compiler.
> 
> Are there any ABI differences which would justify such a difference?
> Register use conventions? Other stuff that you could identify?

The common purposes I've hit are:
1) 64bit floating point control word settings in windows versus 90bit in Linux.
   This can make measurable difference on Athlons and P3/P4.
2) register passing conventions - they helps just slightly for Intel's compiler
   as it is using them anyway in local functions.
3) better optimized memcpy/memset in windows - this plays important role
   for graphics...
> 
> Unfortunately the benchmark gives no details about compiler options,
> so presumably the answer is `the benchmark is flawed' and `go ask
> them'. In this case don't bother to answer.
> 
> Claus
> 
> -- 
> Claus Fischer <claus.fischer@clausfischer.com>
> http://www.clausfischer.com/

RE: [OT] GCC vs Intel C++ compiler benchmark - don't forget ia64

[Duraid Madina]

> > On x86, just use the compiler that doesn't ICE on your code. ;-)
> 
> Err, could you please elaborate on this cryptic remark?

If GCC builds your code fine, use GCC. If Intel C++ builds your code
fine, use Intel C++. I've got a few different sources (some of which
aren't terribly complex) that build fine on one and kill the other.
 
>> but as it stands, you're pretty crazy to use GCC for serious
production
>> work on IA-64 hardware.
> 
> Duraid, in all fairness: IIRC it was you who made us try our 
> symbolic computation code in C++ on some commercial compilers 
> (Intel's was one of them).

You did pick up a coding error or two thanks to this effort, right?
(hmm, I have pretty nasty selective memory sometimes ;-)

> You sure remember this was a complete fiasco.

*cough* Yes *cough*

> Maybe our code is just strange, because GCC generates the best code on
> it.  ;-)

No comment. Well okay maybe just one - GMP+CLN+GiNaC is one of the most
admirably portable codes I have ever seen, and yet it is inextricably
linked to GCC in ways I could have never even dreamt of, until I had
seen it.

	Happy now? ;-)

	Duraid

Re: [OT] GCC vs Intel C++ compiler benchmark

[Tim Prince]

On Sunday 27 January 2002 23:50, Andreas Jaeger wrote:

> Does anybody have a list of optimizations that are in icc and inferior
> or missing in GCC - and would help to improve performance of GCC on
> common platforms?
>
> Andreas

When generating sse code, gcc does not optimize the situation where a 
"reverse" subtract or divide is called for. icc chooses to gnerate x87 code 
sequences which involve fdivr or fsubr, rather than generate sse[2] code with 
an additional move.  A better solution, where loop unrolling might be used to 
resolve the situation, would be to alternate register assignments over pairs 
of loop iterations, when that permits use of efficient sse code.  No doubt, 
other architectures could benefit from such an optimization.

gcc has no ability to generate parallel sse instructions.  There may be ways 
to do this beyond those which icc uses, which is to recognize repeated 
operations in unrolled loops which are eligible for auto-vectorization.  icc 
has an option to force unrolling even when the size of the loop exceeds the 
normal threshold, in order to facilitate auto-vectorization.

Several standard optimizations are lacking in both icc and gcc.  Loop fission 
or fusion should be considered in order to approach (not exceed) optimum use 
of the register set and the associativity of the write buffering system.  On 
pentiumpro architectures, associativity for write buffering is 4 
(documentation available on developer.intel.com); the pentium4 equivalent 
limit is 6.   Loops should be arranged so that the number of array sections 
written accords with this value, where that is feasible.  For nested 
loops, outer loop unrolling may be needed, keeping inner loop unrolling to 
the minimum which is used effectively for parallelization.  Outer loop 
unrolling may reduce the need for consideration of loop nest inversions.

Loop fusion by the compiler has proven difficult to use effectively in C, but 
is essential in Fortran.  Examples which come to mind are the MipsPro and the 
IA64 compilers.  I don't know that fission has been explored adequately; the 
MipsPro compilers seemed to always split loops as much as possible and then 
recombine, possibly in a different way from the original source, and that 
seemed possibly not a good strategy for C.

Re: [OT] GCC vs Intel C++ compiler benchmark

[Florian Weimer]

Tim Prince <tprinceusa@mindspring.com> writes:

> In my experience, Win2K takes better advantage of L2 cache than
> linux, provided that the machine is dedicated to a single task, the
> time slice is set long, and nothing special is done in linux to take
> advantage of that.  At most a 2% differential there.

Yes, I observed that when I ran the HINT benchmark on Windows 95, NT,
Linux 2.0.34 and 2.1.108 a few years ago (on identical hardware, using
identical machine code).  Using Linux, performance started to drop
well before the 512 KB L2 cache is fully used by the benchmark, in
contrast to NT.  However, when the working set approaches 4 MB and
beyond, Linux was faster again.

Re: [OT] GCC vs Intel C++ compiler benchmark

[Florian Weimer]

Florian Weimer <fw@deneb.enyo.de> writes:

> Yes, I observed that when I ran the HINT benchmark on Windows 95, NT,
> Linux 2.0.34 and 2.1.108 a few years ago (on identical hardware, using
> identical machine code).  Using Linux, performance started to drop
> well before the 512 KB L2 cache is fully used by the benchmark, in
> contrast to NT.  However, when the working set approaches 4 MB and
> beyond, Linux was faster again.

I've recovered the original web page. It is now available at:

        http://www.enyo.de/fw/hint-1998/

Are similar results available for today's machines and operating
systems?