Tuesday, May 30, 2017

Performance between BoneCP and HikariCP

I've been assessing HikariCP as a replacement for BoneCP for my server in the past week, and the result is somewhat surprising to me.
Sharing it here in case other people were doing the same thing.

The short conclusion is: BoneCP is slightly faster than HikariCP.

Test environment:
 - BoneCP version: 0.8.0-RELEASE
 - HikariCP version: 2.6.1
 - Tested on 2 groups of servers located on Amazon AWS, with DB servers in the same availability zone.
 - The only difference in the version of jar deployed is the connection pooling library difference (as well as the configuration difference)

The variation in configuration does not seem to make a big difference.

Tested by using the recommended configuration from each library, and for
1st test: trying to map the configuration by meaning
2nd test: match number of connections per host

Both tests give me the same result: the measured wall time for HikariCP is constantly 1~2ms slower than using BoneCP.

This is tested on a live product which has >100K concurrent users all the time and the range of tested queries has covered a few benchmark tests.

For faster database queries, this can be pretty significant: running an indexed select queries from a table costs 1ms on avg for BoneCP group but 2ms for HikariCP

Similarly this affects other queries including inserts & updates & deletes. Due to the range of the queries I have, the difference is 1~2ms.

After reading through this:

I started to wonder if it's the validation overhead that's causing the performance difference.

And the awesome developer for HikariCP told me there are ways to configure that:

So I did a 3rd & 4th test by:
- increase the window of validation check from 500ms to 5s
- override the test connection query from using jdbc isValid method to a simple "SELECT 1"

Unfortunately the result is the same, and the difference is roughly the same too.
So the connection test is not the culprit for performance different, at least on my environment.

Although I think the validation check is good and should be there, I've stopped at this point because I know BoneCP would probably be my go-to option given the performance result.

For now I'm unable to explain the performance different, and that's what needs to be updated. I'll dig the source code a bit further when I have some more time to spend on this.

Tuesday, May 7, 2013

Progressive Photon Mapper

During the past few weeks I've been trying to write a new tracer. After careful consideration I choose to implement a progressive photon mapping integrator within my own architecture, which I simplified and customized based on the one in PRBT book.

Right now I have only a simple scene to show the result of the integrator, later I'll focus more on the other part of the tracer (bsdf, weighting system, sampling, performance etc).

Here's a comparison image of the PPM integrator

First one has only one photon gathering pass, and second with 10 photon gathering pass. Each pass has 200K photons.

Direct lighting and indirect light are not decoupled, which makes the most mathematical sense to me.
pass 1

pass 10

Well I just realized this is not convincing enough. I should do a comparison between 200K photons per pass with 10 pass and 2M photon with 1 pass, and that would be my next post with other features added.

Monday, February 18, 2013

New demo reel

I made a new demo reel yesterday, adding the projects I've been working on recently into it.

Here's my new reel:

Thursday, February 14, 2013

the game: Penguin Planet

Last semester (Fall 2012) I took the CIS 568: Game Design Practicum, and I'm working with Nop for a game in Unity3D.

We both love arcade games, so made a game called "Penguin Planet", which is similar to the arcade game "Fill It".

We collaborated to design all the aspects of this game, and lots of technologies are involved in this game in order to implement all the features included. We like it a lot and we're proud of it.

Here's a demo for our game:

And here's the link for downloading our game:

Hope you enjoy it!

Implemented accurate solid-fluid interaction for my FLIP solver

For the past few days I've been working on my fluid simulation project.
I've incoporated Christ Batty's Siggraph 2007 paper into this project.

Here's a demo about the result:

generate levelset for stanford bunny, apply fast poisson disk sampling method to get 128k particles.
grid size 100 cubic.
used anisotropic kernel for surface reconstruction. 
pretty much include everything I've done for fluid simulation, except for marching cube.

Monday, February 4, 2013

Triangle mesh to level set

Well I had the idea for this project since last summer, but I did not put it into practice until today.

Level set field data is extremely useful in all kinds of simulation, especially in fluid simulation. Also level set is a good interface for blue noise sampling technique.

Generating level set for a implicit surface is easy, all you have to do is to calculate the function value, and it's always somehow related to the minimum distance(signed).

However, things are not that easy when it comes to general case. You'll always be given a triangle mesh(obj file or ply file) as input. The problem for triangle mesh to level set is: triangle mesh is not continuous.

For a single point-triangle minimum distance, it's sometimes ambiguous how to determine the sign of the distance. For those points within the prism of the triangle, judging sign is easy, but for the those who's nearest point is on edge or vertex, it's hard to determine the sign.

So the idea I had is to calculate normal for all vertices(if not given from input) and all edges. I'm using a weighted sum for all surfaces normal related to the vertex/edge. The weight is the incident angle.

By using this method, the sign of a certain point to an arbitrary triangle is obvious and easy to compute.

No one would like to compute the signed distance for all sample points against all triangles. Two possible solutions:
1. using spacial subdivision data structure like KD tree. calculating signed distance for each sample points in a local region.
2. going the other way around. splat each triangle to a certain neighbor region, forming a narrow-band level set, and propagate the date to the whole field.

The second one is obviously faster but technically harder meanwhile. Since I've already spend a lot of time implementing fast sweeping, this approach fits me better. In fact it took me only a few hours to finish this method.

It cost 3.6s to calculate the level set data of a Stanford bunny using a 105*104*82 grid, running on single core laptop without any optimization. I'm pretty satisfied with the performance, since this conversion has to be done only once off-line.

Here's a demo showing the result of the level set. In order to show the correctness of the data, I shrink the whole field by a certain rate.

Friday, January 25, 2013

Global Intersection Analysis: a great idea for collision detection

For the past few days I've been dedicated to solve the self-collision problem in cloth simulation, and here's some insights I've found for self-collision detection:

1. collisions are generated because of positions of vertices are changed. So ideally, assuming the cloth starts without any self-collision, a naive collision detection need to be performed as long as   all vertices are moved.

2. there're two types of collision: continuous collision and static collision.
    continuous collisions are detected by testing the trajectory against a surface. That is a ray-triangle intersection test for common case. The ray starts from the position of a vertex in last frame, and ends on the current position.
    static collisions are detected by testing whether a vertex is under a certain surface, which is testing signed distance of a vertex and a triangle in general case.

3. problem for cloth simulation: cloth is just one single sheet of mesh, which means there's no negative distance for vertex against triangle. So static collision detection would fail because in case like a vertex is below triangle, you cannot distinguish if it is penetrating from above or coming from below without penetration.

4. problem for PBD: as I mentioned before, ideally a naive collision detection(contains either one type of the collision detection) has to be performed once vertices are moved. If PBD is being used, the problem would arise because the positions of vertices are moved in the resolving constraints pass without performing collision detection per iteration.
    So as always is the case, some vertices are move into a certain surface by resolving constraints, while no collision are detected. In the following frame, this kind of collision will not be detected because continuous collision will not treat this one as a collision, while static collision fails because of cloth is too thin to have a negative value.

5. Possible solution: a. GIA(global intersection analysis). b. potential collision constraints.

a. GIA is proposed in this paper. Yet as mentioned in the paper, this method has limitations when it comes to a boundary-penetrating case. I had an idea for perfecting this method, by running flood-fill on both edge and surface.

b. potential collision constraints is the idea I come up with after these days. When doing intersection test, we set a proper threshold for particle-triangle intersection. And add potential collision constraints for resolving pass. They have not collide yet, but since the distance is smaller than the threshold, it's possible for them to collide in the resolving pass. So if they collide in the resolving path, collision will be corrected. Make sure all self-collisions are resolved before entering next frame, so that even the collision detection only support continuous collision, there won't be any problem.

These are two of my ideas, and I'll start a independent project on this. Since for the first idea I'm not sure how to implement it. There're too many topological things related. And for the second idea, I don't have any idea how to set a proper threshold.

Good luck to me!