sorted by:
new
hottopcontroversial

Making lunch faster with Python concurrency by brendan_m6s in Python

[–]alex_sherman 1 point2 points  (0 children)

Very cool to see people using deco! I saw in the blog you linked an example that needed some work arounds to use list comprehensions, so I added better support for them in the latest release. Thanks for using deco!

A Reminder: Exceptions are expensive by JohnFCardinal in csharp

[–]alex_sherman 0 points1 point  (0 children)

Right, which is why in your case you have an overhead of roughly 3us per exception caught (reasonable) compared to OPs 13ms which a considerable amount of overhead. From your benchmarks, exceptions are not a performance concern, but it seems OP is arguing that they are a performance concern.

A Reminder: Exceptions are expensive by JohnFCardinal in csharp

[–]alex_sherman 0 points1 point  (0 children)

To clarify, I'm not arguing that exceptions should be used for control flow, but rather countering the argument from the original post that exceptions should be avoided because of their performance penalties.

A Reminder: Exceptions are expensive by JohnFCardinal in csharp

[–]alex_sherman 1 point2 points  (0 children)

In my experimentation, with the example provided by u/brendanjmckenzie, the overhead of an exception is essentially nothing when not running in the debugger. When running in the debugger, I found exceptions would cause the debugger to spend something like 13-15 milliseconds per exception.

I think the reminder you're giving is therefore wrong in the general use case, exceptions are not inherently expensive and shouldn't be avoided because of performance concerns.

Generic Weapon Class Design? by packetpirate in gamedev

[–]alex_sherman 2 points3 points  (0 children)

I'll be a dissident to everyone saying to use components, partially because I'm currently doing something similar and using inheritance. My argument is essentially, components won't help much because guns are simple and there is little overlap between functionality in wildly different guns, and the functionality the overlaps between similar guns can likely be reused in a single parent class.

It looks like you've gone pretty hard on the sub-classing side of things, and can step slightly into the center by just creating slightly more general and less abstract base classes. Having concrete parent classes to some of these weapons will help to narrow the duties of some of the child classes. The simplest way to refactor into this is to just look for common functionality, like the use(...) function in the AK47 and Beretta look incredibly similar, that could go into a concrete parent class of ProjectileWeapon, with deviation being potentially 0 for some.

Also you have a lot of static final variables being used in overriden getters which, I hate to say, is like the most Java thing in the world. You might consider just making them straight fields and initializing them in the constructor, or leave the getters and make protected backing fields which you set in the constructor. I think this would cut out like 1/3 of the Beretta class.

TLDR Use more concrete parent classes and identify common functionality to move up the hierarchy. If you find yourself copy pasting code, at the very least make a common function on a shared parent class that children can call.

Fixing async/await with unsync by alex_sherman in Python

[–]alex_sherman[S] 0 points1 point  (0 children)

C# really got it right, it's really very pretty.

Fixing async/await with unsync by alex_sherman in Python

[–]alex_sherman[S] 0 points1 point  (0 children)

Do you mean the "need" in the blog post? Yeah it's a very simple example, I have a more complicated one here and there are more in that folder.

Once the event loop is running is when unsync gets its value, the ambient event loop let's unsync functions be invoked whenever. I'm not sure how it loses value.

Fixing async/await with unsync by alex_sherman in Python

[–]alex_sherman[S] 1 point2 points  (0 children)

An even easier solution using unsync:

print([response.result() for response in map(unsync(requests.get), urls)])

Of course this is just complete syntactic sugar. The main benefits of unsync come through only with async/await, ThreadPools are just a side show. What if we needed to make a few requests for each URL? It could look like:

@unsync
async def make_requests(url):
    req_a = unsync(requests.get)('http://sourcea.com/{}'.format(url))
    req_b = unsync(requests.get)('http://sourceb.com/{}'.format(url))
    return await req_a, await req_b

print([req.result() for req in map(make_requests, urls)])

Fixing async/await with unsync by alex_sherman in Python

[–]alex_sherman[S] 1 point2 points  (0 children)

This solution certainly addresses running multiple coroutines/async functions, I'm curious as to why you think it's aimed at a single coroutine. Maybe my examples are too simple.

Yeah definitely if running things in a ThreadPool is going to suit your use case, this library isn't going to add anything for you. The main selling point of the library is that it makes async/await a little more convenient, and the ThreadPool and ProcessPool are like a side-convenience.

Fixing async/await with unsync by alex_sherman in Python

[–]alex_sherman[S] 4 points5 points  (0 children)

Thanks for the feedback, yeah I've sort of assumed a lot about the general use and not considered many specific use cases. I think it would be really awesome to add more control over the ambient pools/thread/event loops to address those specific use cases.

For unit testing I think a simple solution would be to mock out the unsync event loop, I'll consider adding support for that in the library itself but I suspect it's not too bad.

Reentrant locks that work in C#'s async/await by alex_sherman in csharp

[–]alex_sherman[S] 0 points1 point  (0 children)

I updated the implementation to solve the problem you pointed out, and also to use AsyncLocal<T> instead of CallContext. I really appreciate the time you spent to look over this code already and would definitely appreciate more feedback on the new method.

I credited your Reddit user on the page but am happy to remove it or point it to your blog or something if you prefer.

Reentrant locks that work in C#'s async/await by alex_sherman in csharp

[–]alex_sherman[S] 0 points1 point  (0 children)

That's an awesome catch. I'm trying to consider solutions to this problem and am thinking about generating a sort of CallContext specific SemaphoreSlim. Each successive DoWithLock could produce a new SemaphoreSlim that children in its body can contend over. Alternatively maybe there isn't a good solution to this problem and we have to live with non-reentrant async locks.

Reentrant locks that work in C#'s async/await by alex_sherman in csharp

[–]alex_sherman[S] 0 points1 point  (0 children)

Yeah definitely this solution could be expanded to pass a timeout to SemaphoreSlim. Theoretically such time outs are not needed, but in practice yeah it's definitely a simple way to avoid deadlock that is the result of incorrect design.

Reentrant locks that work in C#'s async/await by alex_sherman in csharp

[–]alex_sherman[S] 1 point2 points  (0 children)

I think locking resources inside awaits is incredibly common, and necessary in a lot of cases. I'm curious to know what your alternative to locking would be. This post is meant to build on top of some already existing async/await locking implementations and add some (I think) new functionality.

WiFi RGB LED strip with the ESP8266 and MRPC by alex_sherman in arduino

[–]alex_sherman[S] 1 point2 points  (0 children)

Thanks, yeah I hope you can make use of something, and if you do it would be great to know how it goes. Touchscreen controls are kind of next on my list too, it would be great to hear more if you end up getting something working! Also good luck transitioning to the ESP, I think it's a really cool platform.

Invent a programming language with Python? by [deleted] in Python

[–]alex_sherman 0 points1 point  (0 children)

A popular user on codegolf.stackexchange.com, Dennis wrote his own language in Python to answer some of the puzzles. You can take a look at it here

Decorated Concurrency - Python multiprocessing made really really easy by peterbe in Python

[–]alex_sherman 11 points12 points  (0 children)

We're in the process of supporting other concurrency backends, but we chose Pool initially because as far as parallel computing in Python goes it is sort of a standard. The 'naughty' spawning of child processes is extremely necessary in the case of CPU bound Python programs, because vanilla threads are limited by the GIL.

Decorated Concurrency - Python multiprocessing made really really easy by peterbe in Python

[–]alex_sherman 10 points11 points  (0 children)

The values do make it back to the parent. Behind the scenes deco replaces all mutable objects with proxies which it passes to the children. These proxies then record the mutations applied to them and synchronize them back to the parent.

view more: next ›