wizzard0

14 ms·

121.
by wizzard0 11y ago
Another .NET version arrived, 2x faster LOL
122.
by wizzard0 11y ago
There's an update for Akka version, which measures 12/8/4.4 seconds on subsequent attempts, so yes, warmup is important... but somehow that seems kinda unfair for other languages too.
123.
by wizzard0 11y ago
It's indeed apples vs oranges vs pies (Actors/Coroutines/Futures). Probably should make a table :)
124.
by wizzard0 11y ago
Returning num instead of Promise.resolve(num) is unfair compared to .NET version ;) but I merged your PR as-is
125.
by wizzard0 11y ago
There's updated Akka version which is a lot faster, btw.
126.
by wizzard0 11y ago
BTW, there's a merged PR which makes Akka a lot faster; can someone measure that on OS X (MB Air or MB'2015) ?
127.
by wizzard0 11y ago
You can't create 1M threads on Windows (or OS X, for that matter) because there won't be enough RAM for stack space. (also, running more threads than physical cores on CPU-bound task is pretty pointless). Maybe you mean we should
128.
by wizzard0 11y ago
Updated to use Task.Run, got only 15% perf decrease, which can be due to the delegate creation too...
129.
by wizzard0 11y ago
See the updated version. Runs about 15-20% slower, which is far less than the difference between single-threaded version and task-based one. Also, it's pretty easy to see in Task manager how all the cores get loaded.
130.
by wizzard0 11y ago
Haskell maybe?
131.
by wizzard0 11y ago
.NET version has 2 variants for exactly this reason :) Single-thread version is fastest of course.
132.
by wizzard0 11y ago
.NET core impl has 2 versions, async and sync. Task.FromResult is synchronous, yes. Look closer :)
133.
by wizzard0 11y ago
> I would imagine a for loop would put all of those to shame. Indeed, see ".net sync" version. The point is to measure process spawn/message passing performance.
134.
by wizzard0 11y ago
Added Erlang on Windows numbers, added .NET synchronous numbers.
135.
by wizzard0 11y ago
(dotnetcore version author here) Please note that Windows and OS X is benchmarked on different CPUs! You're welcome to re-test at dual-boot MacBook together so we can meaningfully compare OS X/Windows
136.
by wizzard0 12y ago
Yep, *nix support is definitely part of the plan.
137.
by wizzard0 12y ago
Author here. Tessel uses modified eLua, I want to use Node modules in vanilla Lua, so naturally that approach was not viable to me.
138.
by wizzard0 12y ago
Take a look what happens if you write something simple, like "a[5]=1": http://es5.github.io/#x15.4.5.1 Or "a > b": http://es5.github.io/#x11.8.5 This, in turn, causes all sorts of wei
139.
by wizzard0 12y ago
Author here. Actually, I wanted to do exactly the reverse - ability to use tons of Node.js modules in Lua, while coding in Lua. Think of it :)
140.
by wizzard0 12y ago
Take a closer look at the enlarged fragment: https://tvori.info/jit/subpixel-resize/halos4x.png What I am trying to avoid are the black rings around white-on-gray lines, which sharpening causes to images. Oh, and
141.
by wizzard0 12y ago
Added the 'antialias' option for you - check it out. There is a ton of knobs under the hood :)
142.
by wizzard0 12y ago
Well, just applying textbook signal processing algorithms properly, without optimizations commonly done to speed things up.
143.
by wizzard0 12y ago
That is, of course, subjective. There are ppl out there who like it clean and sharp - but without "ringing", and there are ppl who prefer smooth lines and hate aliasing. But most imaging software only offers the second option, tha
144.
by wizzard0 12y ago
Update: Changed color for transparent images from bright magenta to white %)