On Sat, May 4, 2013 at 5:01 PM, Sasha Pachev <[email protected]> wrote:
> Thanks for the contribution. It was very educational. So Haskell can > do mmap() - that's great, and you got better performance than the > version in Perl, Python, or Java posted so far. > > Did you mean 0.045 s for the non-unicode version? Probably. I experimented with several versions. > I am still going to argue that it cannot beat C - it might be able to > beat my implementation, but if it does, I can just run it in a > debugger, see how, and code up the idea in C - given enough time that > is. C has the ultimate performance winner - __asm() macro in case the > compiler and the optimizer cannot get it right :-) Haskell can escape to other languages as well. One of ghc's backends is LLVM, and there's a fairly cool Haskell LLVM library that lets you do whatever you'd like with the LLVM infrastructure at runtime. It's also got an easy C FFI, if you want to access a pre-existing library or do some low-level stuff that way. And although inline assembly in C is pretty common, it's not a required part of the standard and it's very implementation specific anyway, so it's questionable whether it should count as a 'C' optimization. > Regarding the primitives, I agree that a skillful scripting language > programmer can cut down the number of primitives for a good number of > problems, but at the same time I can think of a string operation that > would require a lot of primitives in a scripting language to perform. > E.g - what if you needed to something crazy like this: > > for each byte: > rotate the bits > swap bits 1 and 7 > and bits 4 and 5 with some bitmask > or bits 4 and 3 with another bitmask > etc > > 20 really odd bit operations If I needed to do that, I'd probably swear very loudly at whoever thought it was a good idea and then write up some C with a bunch of tests, because man is that crap ever error-prone. > For something like this, even if the development time was an issue and > not just the performance, I would choose see just because I can do the > bit magic without having to look anything up, while in Perl or Python > - my scripting languages of choice - I could not do it without having > to use a reference. Maybe if you spent a bit of time becoming as proficient in a higher-level language as you are in C, you would be more productive overall due to not reaching for C at every opportunity? > BTW, how many of us could? - if you can rotate the bits (let's be > specific and say down) of each byte in a string in Perl or Python > without having to look anything up, go ahead and post. Perl has, and Python borrowed from Perl, a very convenient binary pack/unpack syntax that I'd way prefer to use than C's terribly cumbersome binary data facilities. I can't tell how how many times I curse C for its ridiculously bad (for a supposedly low-level language, anyway) binary tools. It's got all sorts of things that are *almost* good solutions, but the low-level details are intentionally left to be implementation-defined, so you can't actually use them for anything portable. So, you either write out a bunch of really stupid and error-prone bit-twiddling operations or you hope you never have to use a different architecture or compiler. And most of the interesting ways around the crappy bits of low-level binary access are forbidden by style guides like MISRA. As I said originally, you *can* do quite a lot of low-level stuff in C, and with enough time and effort you can even make it run fast. But it's error-prone, the code is hard to follow, and it takes forever to do anything interesting in C. Your points of advocacy really don't resonate with me at all. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
