3 ms·

You don't like locks, but you want refcounting that requires a large number of atomic ops for acquire/release semantics and thus scales like crap? Ah, you reall

by vardump 12y ago

You don't like locks, but you want refcounting that requires a large number of atomic ops for acquire/release semantics and thus scales like crap? Ah, you really mean, single threaded as in no other threads? Well... ok. But that'd make Golang a lot less useful. For compiled regular expressions: just use PCRE library for compiled regular expressions. I bet there's already some library that does it for you. Maybe you should take a look at Lua and especially LuaJIT [1]. You might like it. Lua(JIT) is single threaded, but provides co-routines [2] as a language construct. Performance is about same as Golang, sometimes faster, sometimes a bit slower. Lua has GC, but you can control latency by controlled GC invocations. It can be made pretty predictable, a lot of current AAA games use Lua internally. LuaJIT's FFI [3] is excellent, calling native C libraries is a breeze, very easy and requires no bridge libraries or code. [1]: http://luajit.org/ http://luajit.org/ [2]: http://www.lua.org/pil/9.1.html http://www.lua.org/pil/9.1.html [3]: http://luajit.org/ext_ffi.html http://luajit.org/ext_ffi.html

zzzcpan 12y ago
Refcounting and a single threaded runtime, instead of GC and a multithreaded one. By compiled regexpes, I meant replacing things like bytes.Equal(foo, "qwe") with things like foo.m(`^qwe$`) or even foo.m/^qwe$/ that have the same performance. All the loops that scan through slices could benefit from it, golang has a lot of them. Plus more overall matching/scanning consistency, that should lead to fewer mistakes.
- vardump 12y ago
  Well, if you're happy to run them only over byte arrays, then you should be able to use PCRE and satisfy your performance requirements. Your regular expressions will get compiled into native code at runtime. http://sljit.sourceforge.net/pcre.html http://sljit.sourceforge.net/pcre.html
- theseoafs 12y ago
  Go would need to be completely rearchitected in order to move to a single-threaded runtime.
  - im_dario 12y ago
    As far as I know, it should be enough with runtime.GOMAXPROCS(1) to run as single-threaded.
    - yepguy 12y ago
      No, the runtime will still create new threads whenever you call a C function or syscall.
Roboprog 12y ago
Mmmm. Threads + mutable data. What a disaster this industry has unleashed upon itself. Blech. I think that threads are easily up there with null/nil as one of the worst CS mistakes. Communicating via shared variables at the application program level, vs an IPC function / channel, seems like a noose that should be designed away from reach.

by vardump 12y ago

zzzcpan 12y ago

Refcounting and a single threaded runtime, instead of GC and a multithreaded one. By compiled regexpes, I meant replacing things like bytes.Equal(foo, "qwe") with things like foo.m(`^qwe$`) or even foo.m/^qwe$/ that have the same performance. All the loops that scan through slices could benefit from it, golang has a lot of them. Plus more overall matching/scanning consistency, that should lead to fewer mistakes.

vardump 12y ago
Well, if you're happy to run them only over byte arrays, then you should be able to use PCRE and satisfy your performance requirements. Your regular expressions will get compiled into native code at runtime. http://sljit.sourceforge.net/pcre.html http://sljit.sourceforge.net/pcre.html
theseoafs 12y ago
Go would need to be completely rearchitected in order to move to a single-threaded runtime.
- im_dario 12y ago
  As far as I know, it should be enough with runtime.GOMAXPROCS(1) to run as single-threaded.
  - yepguy 12y ago
    No, the runtime will still create new threads whenever you call a C function or syscall.

Roboprog 12y ago

Mmmm. Threads + mutable data. What a disaster this industry has unleashed upon itself. Blech. I think that threads are easily up there with null/nil as one of the worst CS mistakes. Communicating via shared variables at the application program level, vs an IPC function / channel, seems like a noose that should be designed away from reach.