Recent

Author Topic: WIN64 RTL patch using INTEL SIMD  (Read 4118 times)

guest59697

  • Guest
WIN64 RTL patch using INTEL SIMD
« on: July 20, 2017, 02:16:32 pm »
Mem manager multithreaded from 70seconds to 4seconds

check www.dellapasqua.com

please feel free to test it or join me to enlarge it with many functions from IPP Intel

Best regards

Roberto Della Pasqua
(does somebody wants join me to add other IPP functions to the RTL of Delphi/FPC?)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: WIN64 RTL patch using INTEL SIMD
« Reply #1 on: July 20, 2017, 03:48:53 pm »
I only see a Delphi version? Where is the FPC version?

How does the default FPC memory manager perform, relatively?

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: WIN64 RTL patch using INTEL SIMD
« Reply #2 on: July 20, 2017, 04:04:29 pm »
Mem manager multithreaded from 70seconds to 4seconds

check www.dellapasqua.com

please feel free to test it or join me to enlarge it with many functions from IPP Intel

Best regards

Roberto Della Pasqua
(does somebody wants join me to add other IPP functions to the RTL of Delphi/FPC?)

Roberto, the internals of the FPC memory manager are not Delphi compatible... Delphi has a much simpler (and more correct*) model, whereas FPC's model needs a size field to be filled in. (That's duplicate code...)
It is probably doable to translate, though. (For silly folks, I am not talking about actual code, but about some very low level architecture detail)
Note that the overall performance of FPC's manager in pure Pascal has been proven superior to most, but not all,  pure Pascal Delphi ones.

Will have a look... And my daughter is coming to Italy tomorrow so be warned  8-)

*
 The issue is Delphi determines by definition slot size on allocation. No further bookkeeping required.
 Same - almost - goes for FPC, but that NEEDS to store the size of the allocation too...Why? No clue. Been complaining for neigh 20 years, I guess... But it is still fast.
 Actually I know why: some other implementation details in the compiler rely on the implementation details of the memory manager......
« Last Edit: July 20, 2017, 04:16:12 pm by Thaddy »
Specialize a type, not a var.

guest59697

  • Guest
Re: WIN64 RTL patch using INTEL SIMD
« Reply #3 on: July 20, 2017, 05:25:40 pm »
Queste is Located the Fpc MM? I take a look

guest59697

  • Guest
Re: WIN64 RTL patch using INTEL SIMD
« Reply #4 on: July 20, 2017, 06:57:34 pm »
https://software.intel.com/en-us/node/506259
seems them don't have return value

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: WIN64 RTL patch using INTEL SIMD
« Reply #5 on: July 20, 2017, 07:36:31 pm »
Queste is Located the Fpc MM? I take a look

It is the default in every FPC/Lazarus installation

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: WIN64 RTL patch using INTEL SIMD
« Reply #6 on: July 20, 2017, 08:02:36 pm »
Queste is Located the Fpc MM? I take a look

It is the default in every FPC/Lazarus installation

And hardly fixable if the compiler code relies on field size.... Get the point?

But Roberto's code looks adaptable and my daughter is really going to Italy tomorrow...
Specialize a type, not a var.

guest59697

  • Guest
Re: WIN64 RTL patch using INTEL SIMD
« Reply #7 on: July 20, 2017, 08:29:33 pm »
Wish her a nice vacation, beach, sea, and tasty food :-)

guest59697

  • Guest
Re: WIN64 RTL patch using INTEL SIMD
« Reply #8 on: July 20, 2017, 08:47:29 pm »
errata corrige:
using FastMM4 NoThreadContention 22098 msec
using ScaleMM2 22393 msec
using Windows 10 / Windows 2016 Heap 5102 msec
using Intel TBB + Intel IPP 3975 msec

 

TinyPortal © 2005-2018