/[escript]/trunk/esysUtils/src/blocktimer.h
ViewVC logotype

Log of /trunk/esysUtils/src/blocktimer.h

Parent Directory Parent Directory | Revision Log Revision Log


Sticky Revision:
(Current path doesn't exist after revision 5951)

Revision 3981 - (view) (annotate) - [select for diffs]
Modified Fri Sep 21 02:47:54 2012 UTC (6 years, 9 months ago) by jfenwick
File length: 1117 byte(s)
Diff to previous 3911
First pass of updating copyright notices

Revision 3911 - (view) (annotate) - [select for diffs]
Modified Thu Jun 14 01:01:03 2012 UTC (7 years, 1 month ago) by jfenwick
File length: 998 byte(s)
Diff to previous 2881
Copyright changes

Revision 2881 - (view) (annotate) - [select for diffs]
Modified Thu Jan 28 02:03:15 2010 UTC (9 years, 5 months ago) by jfenwick
File length: 998 byte(s)
Diff to previous 2548
Don't panic.
Updating copyright stamps


Revision 2548 - (view) (annotate) - [select for diffs]
Modified Mon Jul 20 06:20:06 2009 UTC (9 years, 11 months ago) by jfenwick
File length: 998 byte(s)
Diff to previous 2078
Updating copyright notices

Revision 2078 - (view) (annotate) - [select for diffs]
Added Thu Nov 20 16:10:10 2008 UTC (10 years, 7 months ago) by phornby
File length: 998 byte(s)
Two changes.

1. Move blocktimer from escript to esysUtils.
2. Make it possible to link to paso as a DLL or .so.

Should have no effect on 'nix's

In respect of 1., blocktimer had begun to spring up everywhere, so
for the moment I thought it best to move it to the only other library that
pops up all over the place.

In respect of 2., paso needed to be a DLL in order to use the windows intelc /fast
option, which does aggressive multi-file optimisations. Even in its current form, it either
vectorises or parallelises  hundreds more loops in the esys system than appear in the pragmas.

In achieving 2. I have not been too delicate in adding

PASO_DLL_API

declarations to the .h files in paso/src. Only toward the end of the process of
the conversion, when the number of linker errors dropped below 20, say, did I choosy about what
functions in a header I declared PASO_DLL_API. As a result, there are likely to be many routines
declared as external functions symbols that are in fact internal to the paso DLL. 
Why is this an issue?  It prevents the intelc compiler from getting aggressive on the paso module.
With pain there is sometimes gain. At least all the DLL rules in windows give good
(non-microsoft) compiler writers a chance to really shine.

So, if you should see a PASO_DLL_API on a function in a paso header file,
and think to yourself, "that function is only called in paso, why export it?", then feel free to
delete the PASO_DLL_API export declaration.

Here's hoping for no breakage.....

This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, enter a numeric revision.

  Diffs between and
  Type of Diff should be a

  ViewVC Help
Powered by ViewVC 1.1.26