Description
Hi. Recently I started some side project which will involve work with big numbers and I require to have an BigInteger collections, but atm tested it on a smaller scale. My solution is basically generating some numbers and then feeding them up into multiple collections in most case on 1-1 relation. I wrote some code which involved multiple tasks (equal to CPU core amount) and expected to see 100% (or about to it) CPU load, but instead my values was way lower than this. After doing some experiments I discovered that it is related to the fact of adding number into collection. Once I drop that part of the code - load gets back to 100% CPU.
Later I isolated that test scenario into that project: https://github.com/21a1ss3/BigIntPerfIssue .
In that project you can see multiple test cases (currently 9) with parallel code based on tasks which generates numbers and adding them into collections on relation 1 task - 1 collection. If you launch (don't forget to adjust amount of cores) cases from 1-5, 7 and 9 you will see that your CPU is not loaded to 100%, instead load will be around 50-60% despite you do not have any synchronization locks in your code.
Configuration
Tested on:
.NET Core 3.1.415
.NET 7.0.1.31918
.NET 7.4.223.48029
CPU:
Intel i7-4750HQ
Intel i5-2310
Windows 10 x64 (don't think it matters significantly)
Data
My benchmarking showing CPU load around 50-70% of the overall system CPU usage on both setups when I launched solution without debugging for slow test cases (1-5, 7, 9). And 100% (or about to it) for cases 6 and 8.
Analysis
Initially I suspected BigInteger (based on tests 1-6), but later with few more tests I discovered that it is not the case, problem caused by node structure.
I've used Concurrency Visualizer to try to analyze the source of the problem, but because it hasn't picked up my managed code correctly I only been abnle to see a fraction of the results. Although the results there where pointing towards new operator and GC.
Description
Hi. Recently I started some side project which will involve work with big numbers and I require to have an BigInteger collections, but atm tested it on a smaller scale. My solution is basically generating some numbers and then feeding them up into multiple collections in most case on 1-1 relation. I wrote some code which involved multiple tasks (equal to CPU core amount) and expected to see 100% (or about to it) CPU load, but instead my values was way lower than this. After doing some experiments I discovered that it is related to the fact of adding number into collection. Once I drop that part of the code - load gets back to 100% CPU.
Later I isolated that test scenario into that project: https://github.com/21a1ss3/BigIntPerfIssue .
In that project you can see multiple test cases (currently 9) with parallel code based on tasks which generates numbers and adding them into collections on relation 1 task - 1 collection. If you launch (don't forget to adjust amount of cores) cases from 1-5, 7 and 9 you will see that your CPU is not loaded to 100%, instead load will be around 50-60% despite you do not have any synchronization locks in your code.
Configuration
Tested on:
.NET Core 3.1.415
.NET 7.0.1.31918
.NET 7.4.223.48029
CPU:
Intel i7-4750HQ
Intel i5-2310
Windows 10 x64 (don't think it matters significantly)
Data
My benchmarking showing CPU load around 50-70% of the overall system CPU usage on both setups when I launched solution without debugging for slow test cases (1-5, 7, 9). And 100% (or about to it) for cases 6 and 8.
Analysis
Initially I suspected BigInteger (based on tests 1-6), but later with few more tests I discovered that it is not the case, problem caused by node structure.
I've used
Concurrency Visualizerto try to analyze the source of the problem, but because it hasn't picked up my managed code correctly I only been abnle to see a fraction of the results. Although the results there where pointing towardsnewoperator and GC.