Vasily Kirichenko's blog articles

0
comment
on 12/22/2021 7:08 AM
5 years ago I showed a way to fight with "all-threads-busy" problem while writing Hopac code. The same problem exists on JVM as well. The root is in the cooperative concurrency model, which is based on thread pools, async/futures/etc. are scheduled to run on them. So, if an async is blocked by an IO call of if it's just executing some computation, the OS thread is not able to do anything else: the scheduler is unable to "pause" such a blocked async and execute anothe one. So, asynchronous code on .NET, JVM[...]
>> Read the full article
.
0
comment
on 8/13/2016 8:28 AM
Rancher has a load balancer built it (HAProxy). Let's compare its performance vs Docker Swarm one. I will use 3 identical nodes:192GB RAM28-cores i5 Xeon1GBit LANCentOS 7Docker 1.12Rancher 1.1.2I will benchmark against a hello world HTTP server written in Scala with Akka-HTTP and Spray JSON serialization (I don't think it matters though), sources are on GitHub. I will use Apache AB benchmark tool.As a baseline, I exposed the web server port outside the container and run the following command:ab -n 100000 -[...]
>> Read the full article
.
0
comment
on 6/11/2016 12:48 PM
Hopac uses a bounded pool of worker threads, number of which is equal to number of CPU cores (by default). A dangerous thing about this design is that a situation is possible where all the threads are busy doing some CPU intensive work and no other Hopac jobs can proceed. A good solution for this is running such a CPU bound computations on the standard .NET thread pool, freeing Hopac pool for more intelligent work. I found a nice code in one of the older Hopac GitHub discussions which schedules a ordinary [...]
>> Read the full article
.
0
comment
on 5/27/2016 10:21 AM
Don Syme has been working on struct tuples for F# language. Let's see if they are more performant than "old" (heap allocated) tuples in simple scenario: returning tuple from function. The code is very simple: Decompiled code in Release configuration: Everything we need to change to switch to struct tuples, is adding "struct" keyword in front of constructor and pattern matching: Decompiled code in Release configuration: I don't know about you, but I was surprised with those results. The performance roughly[...]
>> Read the full article
.
0
comment
on 5/22/2016 9:00 AM
Let's compare performance of hashmap implementation in Rust, .NET, D (LDC) and Go.Rust: F#: As you can see, Rust is slower at about 17% on insersions and at about 21% on lookups. UpdateAs @GolDDranks suggested on Twitter, since Rust 1.7 it's possible to use custom hashers in HashMap. Let's try it: Yes, it's significantly faster: additions is only 5% slower than .NET implementation, and lookups are 32% *faster*! Great. Update: D addedLDC x64 on windows It's very slow at insertions and quite fast on loo[...]
>> Read the full article
.
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper