avdicius

Yes, that's true. However in my app this has never caused any problems. Apparently even if the compiler auto-vectorizes anything it does this only with scratch regs or in leaf procedures. I don't have any fp or simd code of myself.

Wow. I used my own stack switch routine for several years now and didn't realize it could be improved until I read this thread. Thank you very much.

This is my old naive version:

https://github.com/ademakov/MainMemory/blob/master/src/base/...

This is what I have now:

https://github.com/ademakov/MainMemory/blob/cstack-switch-re...

Yes, initial benchmark results: https://github.com/M4GNV5/GSoC2018

Thanks, Gopal. I didn't do much, just maintained it on life support. Recently some good contributors arrived: Jakob and Tom. Let's hope this really revives the project.

The development of libjit almost halted a while back. But thanks to the last GSoC it is set to receive a major update soon: https://github.com/ademakov/libjit/pull/14

It's a hardware interrupt from a hardware clock that is handled by the OS kernel. Regular user processes are usually totally forbidden from touching that hardware stuff.

Oops, sorry. Have no idea why I overlooked it.

I have something like this here:

https://github.com/ademakov/MainMemory/blob/master/src/base/... https://github.com/ademakov/MainMemory/blob/master/src/base/...

It seems your variant does not support the common convention to use lone two dashes ('--') to separate options from non-options that for some reason start with dashes too (e.g. strangely named files).

My version supports typed values at a different level integrated with config file parsing. So the command line argument values are just strings for me.

The usual varint is called varint-SU in the Stepanov's paper. The varint-PU is just like what you call FLIT64, at least I don't see any difference.

It seems the algorithm is not very new as it looks pretty much like the one named varint-PU in the following paper: http://stepanovpapers.com/CIKM_2011.pdf

At first I wanted to make an in-memory database. But I disliked libevent, libev and everything else I saw when I started it. Perhaps I would be more or less happy with libuv, but I was not aware of it back then. By the way redis also provides its own event handling machinery. I guess Salvatore did not like libevent too. But redis is single-threaded while my idea was to heavily rely on multi-threading and fibers (M:N threading model). Quite unexpectedly inventing a multi-threaded event handling framework with an added complexity of fibers took enormous time from me. Anyway now I have a cool framework for multi-threaded servers.

As for in-memory database functionality it only provides memcached compatible interface. As I'm done with the server framework stuff so I am going to add more features. Like persistance, basic redis protocol support, etc.

Sorry, I cannot see this as expressing any sort of disagreement. I perhaps can learn how to play piano. If we are talking about some pieces for 6 y.o. kids. Can I learn how to play any Rachmaninov prelude or concerto? No, for me personally, this is not going to happen even if I had an infinite lifetime.

A personal account of perhaps an old timer already. Entirely based on personal experience so probably less than representative.

People are either able to code or not. Teaching does not work. Those who are able to code almost entirely pick all the skills by themseves. If a 'natural born' coder gets into some formal environment, such as university or something, suсh a person in two months surpasses the level of all the peers and the direct instructor as well.

In the university I was trained for automatics. But I quickly learned that coding takes me no effort at all, as opposed to, say, understanding electronics. After reading Wirth, Kernighan & Ritchie, and Stroustrup I often found myselfs hinting students from the programming department how to perform their tasks as they were scratching their heads and I was just passing by.

This has nothing to do with inteligence. I'm perhaps not very smart. When I starred at some scheme I had no idea if this an amplifier or something else, what is the role of one resistor or another. At the same time mates from my group read it as it was written in plain English (err, in plain Russian to be precise). But the very same persons were totally unable to code. It's very strange. For me coding is trivial and takes no inteligence. This is why I do it for living. The path of the least resistance. I'm kind of puzzled why persons smarter than me cannot code.

Anyway, after reading some foundational books the only thing that helps is reading other people's good code. For me it was reading pieces of the old (around 90's) BSD and GNU code.

I never met a person I'd appreciate for directy handing me over any useful coding skill. YMMV.

> but some of these cultural factors I think were pre existing and also help facilitate the pattern..

I would agree with this. Here is a Soviet cartoon based on a Russian folk fairy tale about smart and mighty wife rescuing her husband from king's prison:

https://www.youtube.com/watch?v=CnysHoprhsQ

Here is another version of this fairy tale:

http://www.eliterarysociety.com/tag/stavr-godinovich/

I think Russia never was a classic patriarchal society. At the family level matriarchs always played as important and prominent role as patriarchs. Yes, in the past the official power institutions were almost completely male dominated. However there were notable exceptions such as semi-mythical princess Olga, emperatresses Anna I, Elisabeth, and Catherine II. Also Peter I came to power as the result of power-struggle with regent-princess Sophia Alekseyevna. Actually when the party of Peter I won, the actual power was grabbed by his mother Natalia Naryshkina whose nickname was she-bear. Peter became the true ruler of Russia only after her death. There were other notable historic women in Russian history such as princess Sophia Palaiologina. All in all throughout Russian history there were many much-revered and/or influential women. Also some folk fairy tales feature mighty female warriors. In particular there is a story about a knight Stavr Godinovich who was arrested by the king Vladimir and was rescued by his wife Vasislisa Mikulishna by winning in several contests ranging from wrestling to chess-playing. I believe gender biases for ages were weaker in Russia than in Western Europe let alone Middle East and you name it.

The article totally misses the point. It just picks a single area and wonders why in this particular area women and men are more equal in Russia than in the West. By asking such a narrow question you will never get the right answer. The right answer is that in Russia there is more gender equality in general and therefore in every particular area too.

For instance, from a women-in-business study it follows that the proportion of female-ocuppied senior management positions in Russia is 47% while in the US it's 23% and in UK it's 19%.

https://www.grantthornton.global/en/insights/articles/women-...

A quote from it:

"Eastern Europe continues to top the rankings (see figure 3), with Russia in the lead as the only country in which every business has a woman on its senior leadership team. In Poland, the proportion of senior roles held by women has improved by six percent to 40%. The region owes some of its strong performance to the legacy of communist principles which have placed women as equals for generations."

Of course, such a conclusion goes against the main-stream narrative of communism being all about abuse and human rights violations while the West being the undisputed champion of human rights. So the BBC article just have to provide the following paragraph:

"While Russia is doing something right, it's still not there yet in terms of gender parity."

What is this about? Nothing. Whatever the subject is BBC must retain some reservations about Russia however unsubstantiated they are.

I did something similar in plain C:

https://github.com/ademakov/MainMemory

It was not the first. It was after Allan Chumak made it to the TV. And after lots of other absurdity like teachings of Helena Roerich was thrown in to blow Soviet people's minds. Actually Kuryokhin was making fun of all of this, it's rather a parody than a genuine hoax.

I don't think many people believed it. Actually it was more of a satire than a hoax. A mockery of the BS wave that befell on gullible and unprepared audience upon Perestroika.

There was no valid arguments. Just bogus claims interspersed with irrelevant quotes and a pretence of authority.

Upon return from a non-blocking I/O call the request is either failed or succeeded. Upon return from an async I/O call the request might additionally be in progress thus the fiber is required to wait for its completion. This case has little practical difference from a thread pool. Except with a thread pool it is the worker thread that notifies the fiber scheduler on I/O completion. With async I/O it is the kernel that notifies the application and then the application (from a signal handler or from an auxiliary thread) should propagate the notification to the fiber scheduler.

Yes, fibers/coroutines are good for socket I/O because sockets could be made non-blocking, therefore a fiber could yield on EWOULDBLOCK error from a socket. For file I/O there is no non-blocking I/O option, so the whole OS-thread might block on it along with all the fibers that it owns. Therefore any operation that is not socket I/O and goes beyond CPU and RAM should be delegated from fibers to a good old worker thread pool. The fiber should yield after submitting a request to the pool, and on the request completion the worker thread should notify the fiber scheduler to resume the original fiber.

Coroutines seem to be a very popular topic. And again my shameless plug, I did exactly the thing described in this article in my project: https://github.com/ademakov/MainMemory

I use pthreads and coroutines (actually fibers) inside pthreads and lock-free bounded queues to communicate between pthreads. All pthreads execute coroutines until all of them get blocked, then pthreads go to epoll. If a pthread gets a socket readiness notification for a socket it owns or an orphan socket then it handles I/O itself, without any synchronization. If a socket is owned by a coroutine running on a different pthread then the notification is forwarded to that pthread via the bounded queue. The project is called MainMemory, and it is just here on Show HN.

To put it simply, in my tetsing, if using 4 threads (the default) memcached and my clone run about the same. However if using 8 threads (with -t 8 option), memcached becomes a little slower (!) while my clone becomes a little faster. There are still some optimizations I'm planning to do, so I hope the performance/scalability margin will improve yet more.

1. Right now it tries to solve the problem of better multi-core scalability. 2. Additionally it tries to have a cleaner source base which should allow add in the future new features, such as persistence and replication.

The semantics would be nothing but executing the finally block. As a rule C programs do only what is explicitly coded. No high-level programming language behind the scenes stuff.

If the next C standard were to introduce something like try/finally/throw to replace prehistoric libc-based setjmp/longjmp, it would shrink the gap between it and other languages, well, I'd say roughly by half.

Both are relatively small projects and really there is no much stuff to compare.

I'm slowly working on my own memcached clone and plan to add persistence there eventually. Not so sure about replication, it might be too hard. In principle, after I'm done with getting a better version of memcached, both feature-wise and performance-wise, if time permits, I can also add the redis protocol support.

Therefore, it will be possible to have both in a single package and don't worry finding which one is better.

This is my project, if anyone is interested: https://github.com/ademakov/MainMemory

[Update: my statement was only about cache-related functionality, admittedly redis supports very interesting data structures, persistence, replication. But as just a very fast in-memory cache, there is nothing particularly advanced in either case. On the other hand there are projects like RAMCloud, Seastar that I find inspiring when I work on my own project.]

My version:

  template <class T> INLINE size_t fast_upper_bound5(const vector<T>& vec, T value)
  {
      size_t index = 0;
      size_t size = vec.size();
      while (size > 0) {
          size /= 2;
          size_t probe = index + size;
          if (vec[probe] <= value)
              index = probe + 1;
      }
      return index;
  }

Slightly faster with gcc:

  $ g++-mp-4.9 -std=c++11 -O3 -DNDEBUG -o blog blog.cpp 
  $ ./blog 
  size = 8192:
      stl      : 144.883 miliseconds
      version 1: 145.406 miliseconds
      version 2: 129.713 miliseconds
      version 3: 109.231 miliseconds
      version 4: 103.578 miliseconds
      version 5: 102.282 miliseconds

But sucks with clang, apparently because of the described problem with non-using cmov instruction.

  $ clang++-mp-3.6 -std=c++11 -O3 -DNDEBUG -o blog blog.cpp
  $ ./blog 
  size = 8192:
      stl      : 147.466 miliseconds
      version 1: 145.978 miliseconds
      version 2: 145.547 miliseconds
      version 3: 113.546 miliseconds
      version 4: 106.968 miliseconds
      version 5: 144.231 miliseconds