|
[Sponsors] |
October 30, 2015, 17:29 |
Inefficient implementation of UList::swap ?
|
#1 |
Member
Join Date: Aug 2015
Posts: 37
Rep Power: 11 |
In OF 2.4., UList::swap is implemented as a member-by-member trade, which has computational complexity O(nElements) [see definition in https://github.com/OpenFOAM/OpenFOAM.../UList/UList.C]. It seems to me that it could instead be implemented by trading the data pointers of the two ULists, as is done in std::vector::swap. This has computational complexity O(1).
Is there a reason that swap is implemented this way? |
|
October 31, 2015, 06:14 |
|
#2 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,981
Blog Entries: 45
Rep Power: 128 |
Greetings knuckles,
As far as I can figure out, the likely reasons are as follows:
Best regards, Bruno edit: I've taken a look at the origin of this method "swap" and it exists at least since OpenFOAM 1.1. Perhaps this could use some revising...
__________________
Last edited by wyldckat; October 31, 2015 at 11:32. Reason: see "edit:" |
|
November 1, 2015, 12:13 |
|
#3 |
Member
Join Date: Aug 2015
Posts: 37
Rep Power: 11 |
Thanks for your input wyldckat!
Perhaps references are the motivation? Client code could store a reference to element 0 of the list, but this operation would actually bind the reference to the data for element 0. The current implementation of swap() would update the data that the reference points to, maintaining that referenceToZero = list[0], but swapping the data pointers would have no impact on the previously-stored reference to element 0. In code: Code:
List<scalar> list = ...; scalar& refToFirstElement = list[0]; list.swap(otherList); assert(refToFirstElement == list[0]); // Not guaranteed if swap() just exchanges pointers |
|
November 1, 2015, 15:25 |
|
#4 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,981
Blog Entries: 45
Rep Power: 128 |
Hi knuckles,
Good point! I didn't think/remember about that possibility. OpenFOAM's code is very reliant on accessing data by reference, given that it's more efficient in many situations, so that would certainly be a good reason for having a hard data swap. Best regards, Bruno |
|
Tags |
lists, optimization |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Free CFD code with implementation of Menter's k-omega SST model | nikola_m | Main CFD Forum | 2 | May 8, 2020 12:13 |
Issues in FGM combustion model implementation | Lisandro Maders | OpenFOAM Programming & Development | 15 | April 22, 2020 19:18 |
a little confused with the implementation of compressibleInterFoam | su_junwei | OpenFOAM Running, Solving & CFD | 2 | May 7, 2014 17:33 |
Implementation issues of fvSchemes / laplacianScheme, in particular gaussLaplacianSch | thomek | OpenFOAM Programming & Development | 0 | October 18, 2010 05:10 |
Please explain the implementation of species transport Eqn in reactingFoam | kallipygian | OpenFOAM Running, Solving & CFD | 0 | October 13, 2008 07:29 |