|
|
a45ddd2dc0
|
use easy_parallel from smol project instead of std::thread. No performance improvement, but easier
|
2024-08-27 13:23:51 +02:00 |
|
|
|
e832475fc3
|
stuff
|
2024-08-27 11:48:08 +02:00 |
|
|
|
608cbb59e5
|
managed to get faster again by searching hashmap using &str and only converting to String on insertion. Removed FxHashMap again
|
2024-08-27 10:57:23 +02:00 |
|
|
|
53ea542f36
|
update dependencies, create benches
|
2024-08-19 14:58:34 +02:00 |
|
|
|
d246c54cd9
|
removed polars example because it wouldn't compile anymore, even when updating to latest version. It also massively reduced the number of downloaded crates
|
2024-08-19 13:55:19 +02:00 |
|
|
|
2a89d061a0
|
Use FxHashMap for multi_threaded_smol.rs
|
2024-08-19 10:57:18 +02:00 |
|
|
|
7add8793a5
|
managed to get library version on par with the reference implementation by using memmap2. I'm understanding scoped threads a little better now... I think
The fixed line length solution is still just as slow, even using memmap
|
2024-08-19 10:39:19 +02:00 |
|
|
|
b1d7ebaaea
|
Create multi threaded version using smol for async reading of the file ~1 seconds faster
|
2024-08-13 14:14:42 +02:00 |
|
|
|
bbc89aa2b3
|
Create single threaded version using smol for async reading of the file 46 -> 40 seconds
|
2024-08-13 13:50:49 +02:00 |
|
|
|
b53212103b
|
Tried looking at what the performance would be if I read the data from a file where every line would have the same length ie. not having to read until eol. But despite not having to search the \n byte (or ; because every station name and temperatures are padded with null bytes) and having a fixed size array instead of vec this is slower (the normal read_until version is actually still just as fast, while the new one is 10x slower)
|
2024-08-12 10:48:07 +02:00 |
|
|
|
8ffea918c4
|
either it's slightly faster or it's a measurement error
|
2024-08-05 12:52:57 +02:00 |
|
|
|
3b3801ba0d
|
Going back because compile times trippled
|
2024-08-05 11:22:08 +02:00 |
|
|
|
1c066ec113
|
accidentally committed bug
|
2024-08-05 10:54:59 +02:00 |
|
|
|
13c54a2811
|
FxHashMap made me faster, memmap makes me slower, guess I'm using it wrong
|
2024-08-05 10:53:17 +02:00 |
|
|
|
40627f9aeb
|
add solution using libraries to see how fast I can get. For now no difference
|
2024-08-02 11:43:23 +02:00 |
|
|
|
45ae29d3cd
|
organize differently, added criterion as dev-dependency for benchmarks
|
2024-08-01 15:02:24 +02:00 |
|
|
|
8eefe06e8b
|
Formatting
|
2024-08-01 10:23:14 +02:00 |
|
|
|
34768d3ec1
|
forgot feature flag in last commit
|
2024-07-31 14:00:00 +02:00 |
|
|
|
0ffbff4cbf
|
added 2 new implementations from users who commented on my reddit post as a comparison
|
2024-07-31 13:58:42 +02:00 |
|
|
|
25d20169aa
|
some improvements by reducing the casts, implemented a get_pos function to get position of byte in byteslice by bitmasking... slightly slower
|
2024-07-31 12:49:16 +02:00 |
|
|
|
2c23e30fe0
|
hash stationnames myself for faster HashMap
|
2024-07-31 09:27:02 +02:00 |
|
|
|
da72f38e42
|
don't need own parse_line function
|
2024-07-29 12:09:05 +02:00 |
|
|
|
5aa94e67d1
|
use read_until method instead of custom function because it is faster than mine using the Bytes struct
|
2024-07-25 15:35:10 +02:00 |
|
|
|
c6b8273d65
|
applied clippy
|
2024-07-25 13:05:53 +02:00 |
|
|
|
e230a5ce2c
|
My multi-treaded version is now faster than polars and takes less time to compile. It's a little more complex though
|
2024-07-25 10:03:37 +02:00 |
|
|
|
dcaca0cc65
|
managed to make my solution super fast... but it's also incorrect
|
2024-07-24 15:19:17 +02:00 |
|
|
|
16cf4ca2ca
|
moved from reading String to reading bytes. A little faster, still need to implement for multithreaded solution
|
2024-07-23 16:30:50 +02:00 |
|
|
|
b4e3992c65
|
mostly made output a bit nicer
|
2024-07-23 13:23:26 +02:00 |
|
|
|
393f802741
|
remove the need for mutex by using channels
|
2024-07-23 13:23:26 +02:00 |
|
|
|
327fe8564e
|
use scopes to allow to use mutex without arc
apply clippy to my implementations
|
2024-07-23 13:23:26 +02:00 |
|
|
|
14d608b209
|
Fastest yet with scaled integers instead of floats
|
2024-07-23 13:23:26 +02:00 |
|
|
|
2f82e8788d
|
moved rust implementation to /src/main/rust
|
2024-07-23 13:23:26 +02:00 |
|
|
|
91adbf4c1c
|
Actually I just needed to add target-cpu=native to [build] in Cargo.toml, did that and create HashMap with capacity, also added reference implementation (which uses libraries unlike my solution)
|
2024-07-23 13:23:26 +02:00 |
|
|
|
00096647ee
|
The polars solution I saw on reddit a few months ago is also super slow. I'm thinking it might be my macbook
|
2024-07-23 13:23:26 +02:00 |
|
|
|
fe1053b74a
|
Multi threaded works now but it's slower than single threaded...
|
2024-07-23 13:23:26 +02:00 |
|
|
|
3ffed9099c
|
Still broken but it compiles. For some reason lines are not properly being read and only one thread is being run
|
2024-07-23 13:23:26 +02:00 |
|
|
|
65df621cf6
|
use hashbrown instead of std hashmap, no performance improvements
|
2024-07-23 13:23:26 +02:00 |
|
|
|
bd83b9bc2c
|
not working multi threaded solution
|
2024-07-23 13:23:26 +02:00 |
|
|
|
15525282d6
|
modified .gitignore
|
2024-07-23 13:23:26 +02:00 |
|
|
|
6cc29fb645
|
single threaded solution in bin
|
2024-07-23 13:23:26 +02:00 |
|
|
|
6f548678f2
|
single threaded solution
|
2024-07-23 13:23:26 +02:00 |
|
Antonio Goncalves
|
3372b6b290
|
Adding Antonio Goncalves' blog post
|
2024-03-08 11:58:47 +01:00 |
|
Ruslan Kovtun
|
dfec2cdbe6
|
Fixes progress bar for create_measurements.py
|
2024-03-03 13:10:46 +01:00 |
|
Daniel Patrick
|
6125ba4dfa
|
Explicit float in commented out code
|
2024-03-03 13:10:15 +01:00 |
|
Daniel Patrick
|
6daa93cca1
|
More accurate file size estimate
|
2024-03-03 13:10:15 +01:00 |
|
Gunnar Morling
|
c92346790e
|
Adding blog post
|
2024-02-22 09:30:39 +01:00 |
|
Gunnar Morling
|
fe9b527995
|
Adding a blog post
|
2024-02-21 14:31:48 +01:00 |
|
Gunnar Morling
|
00a309e5c7
|
Adding some articles
|
2024-02-05 22:43:54 +01:00 |
|
Gunnar Morling
|
3be4a50875
|
Updating PR template
|
2024-02-05 10:17:19 +01:00 |
|
Gunnar Morling
|
0f284680e8
|
Status update
|
2024-02-04 18:27:42 +01:00 |
|
