mozilla

Mozilla Nederland Logo De Nederlandse Mozilla gemeenschap

Foutmelding

  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2014 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (regel 2024 van /home/mzilla2013/domains/mozilla-nl.org/public_html/includes/common.inc).

Brendan Eich Steps Down as Mozilla CEO

Mozilla Blog - do, 03/04/2014 - 21:02

Mozilla prides itself on being held to a different standard and, this past week, we didn’t live up to it. We know why people are hurt and angry, and they are right: it’s because we haven’t stayed true to ourselves.

We didn’t act like you’d expect Mozilla to act. We didn’t move fast enough to engage with people once the controversy started. We’re sorry. We must do better.

Brendan Eich has chosen to step down from his role as CEO. He’s made this decision for Mozilla and our community.

Mozilla believes both in equality and freedom of speech. Equality is necessary for meaningful speech. And you need free speech to fight for equality. Figuring out how to stand for both at the same time can be hard.

Our organizational culture reflects diversity and inclusiveness. We welcome contributions from everyone regardless of age, culture, ethnicity, gender, gender-identity, language, race, sexual orientation, geographical location and religious views. Mozilla supports equality for all.

We have employees with a wide diversity of views. Our culture of openness extends to encouraging staff and community to share their beliefs and opinions in public. This is meant to distinguish Mozilla from most organizations and hold us to a higher standard. But this time we failed to listen, to engage, and to be guided by our community.

While painful, the events of the last week show exactly why we need the web. So all of us can engage freely in the tough conversations we need to make the world better.

We need to put our focus back on protecting that Web. And doing so in a way that will make you proud to support Mozilla.

What’s next for Mozilla’s leadership is still being discussed. We want to be open about where we are in deciding the future of the organization and will have more information next week. However, our mission will always be to make the Web more open so that humanity is stronger, more inclusive and more just: that’s what it means to protect the open Web.

We will emerge from this with a renewed understanding and humility — our large, global, and diverse community is what makes Mozilla special, and what will help us fulfill our mission. We are stronger with you involved.

Thank you for sticking with us.

 

Mitchell Baker, Executive Chairwoman

 

Categorieën: Mozilla-nl planet

Joshua Cranmer: If you want fast code, don't use assembly

Mozilla planet - do, 03/04/2014 - 18:52
…unless you're an expert at assembly, that is. The title of this post was obviously meant to be an attention-grabber, but it is much truer than you might think: poorly-written assembly code will probably be slower than an optimizing compiler on well-written code (note that you may need to help the compiler along for things like vectorization). Now why is this?

Modern microarchitectures are incredibly complex. A modern x86 processor will be superscalar and use some form of compilation to microcode to do that. Desktop processors will undoubtedly have multiple instruction issues per cycle, forms of register renaming, branch predictors, etc. Minor changes—a misaligned instruction stream, a poor order of instructions, a bad instruction choice—could kill the ability to take advantages of these features. There are very few people who could accurately predict the performance of a given assembly stream (I myself wouldn't attempt it if the architecture can take advantage of ILP), and these people are disproportionately likely to be working on compiler optimizations. So unless you're knowledgeable enough about assembly to help work on a compiler, you probably shouldn't be hand-coding assembly to make code faster.

To give an example to elucidate this point (and the motivation for this blog post in the first place), I was given a link to an implementation of the N-queens problem in assembly. For various reasons, I decided to use this to start building a fine-grained performance measurement system. This system uses a high-resolution monotonic clock on Linux and runs the function 1000 times to warm up caches and counters and then runs the function 1000 more times, measuring each run independently and reporting the average runtime at the end. This is a single execution of the system; 20 executions of the system were used as the baseline for a t-test to determine statistical significance as well as visual estimation of normality of data. Since the runs observed about a constant 1-2 μs of noise, I ran all of my numbers on the 10-queens problem to better separate the data (total runtimes ended up being in the range of 200-300μs at this level). When I say that some versions are faster, the p-values for individual measurements are on the order of 10-20—meaning that there is a 1-in-100,000,000,000,000,000,000 chance that the observed speedups could be produced if the programs take the same amount of time to run.

The initial assembly version of the program took about 288μs to run. The first C++ version I coded, originating from the same genesis algorithm that the author of the assembly version used, ran in 275μs. A recursive program beat out a hand-written assembly block of code... and when I manually converted the recursive program into a single loop, the runtime improved to 249μs. It wasn't until I got rid of all of the assembly in the original code that I could get the program to beat the derecursified code (at 244μs)—so it's not the vectorization that's causing the code to be slow. Intrigued, I started to analyze why the original assembly was so slow.

It turns out that there are three main things that I think cause the slow speed of the original code. The first one is alignment of branches: the assembly code contains no instructions to align basic blocks on particular branches, whereas gcc happily emits these for some basic blocks. I mention this first as it is mere conjecture; I never made an attempt to measure the effects for myself. The other two causes are directly measured from observing runtime changes as I slowly replaced the assembly with code. When I replaced the use of push and pop instructions with a global static array, the runtime improved dramatically. This suggests that the alignment of the stack could be to blame (although the stack is still 8-byte aligned when I checked via gdb), which just goes to show you how much alignments really do matter in code.

The final, and by far most dramatic, effect I saw involves the use of three assembly instructions: bsf (find the index of the lowest bit that is set), btc (clear a specific bit index), and shl (left shift). When I replaced the use of these instructions with a more complicated expression int bit = x & -x and x = x - bit, the program's speed improved dramatically. And the rationale for why the speed improved won't be found in latency tables, although those will tell you that bsf is not a 1-cycle operation. Rather, it's in minutiae that's not immediately obvious.

The original program used the fact that bsf sets the zero flag if the input register is 0 as the condition to do the backtracking; the converted code just checked if the value was 0 (using a simple test instruction). The compare and the jump instructions are basically converted into a single instruction in the processor. In contrast, the bsf does not get to do this; combined with the lower latency of the instruction intrinsically, it means that empty loops take a lot longer to do nothing. The use of an 8-bit shift value is also interesting, as there is a rather severe penalty for using 8-bit registers in Intel processors as far as I can see.

Now, this isn't to say that the compiler will always produce the best code by itself. My final code wasn't above using x86 intrinsics for the vector instructions. Replacing the _mm_andnot_si128 intrinsic with an actual and-not on vectors caused gcc to use other, slower instructions instead of the vmovq to move the result out of the SSE registers for reasons I don't particularly want to track down. The use of the _mm_blend_epi16 and _mm_srli_si128 intrinsics can probably be replaced with __builtin_shuffle instead for more portability, but I was under the misapprehension that this was a clang-only intrinsic when I first played with the code so I never bothered to try that, and this code has passed out of my memory long enough that I don't want to try to mess with it now.

In short, compilers know things about optimizing for modern architectures that many general programmers don't. Compilers may have issues with autovectorization, but the existence of vector intrinsics allow you to force compilers to use vectorization while still giving them leeway to make decisions about instruction scheduling or code alignment which are easy to screw up in hand-written assembly. Also, compilers are liable to get better in the future, whereas hand-written assembly code is unlikely to get faster in the future. So only write assembly code if you really know what you're doing and you know you're better than the compiler.

Categorieën: Mozilla-nl planet

Joshua Cranmer: If you want fast code, don't use assembly

Thunderbird - do, 03/04/2014 - 18:52
…unless you're an expert at assembly, that is. The title of this post was obviously meant to be an attention-grabber, but it is much truer than you might think: poorly-written assembly code will probably be slower than an optimizing compiler on well-written code (note that you may need to help the compiler along for things like vectorization). Now why is this?

Modern microarchitectures are incredibly complex. A modern x86 processor will be superscalar and use some form of compilation to microcode to do that. Desktop processors will undoubtedly have multiple instruction issues per cycle, forms of register renaming, branch predictors, etc. Minor changes—a misaligned instruction stream, a poor order of instructions, a bad instruction choice—could kill the ability to take advantages of these features. There are very few people who could accurately predict the performance of a given assembly stream (I myself wouldn't attempt it if the architecture can take advantage of ILP), and these people are disproportionately likely to be working on compiler optimizations. So unless you're knowledgeable enough about assembly to help work on a compiler, you probably shouldn't be hand-coding assembly to make code faster.

To give an example to elucidate this point (and the motivation for this blog post in the first place), I was given a link to an implementation of the N-queens problem in assembly. For various reasons, I decided to use this to start building a fine-grained performance measurement system. This system uses a high-resolution monotonic clock on Linux and runs the function 1000 times to warm up caches and counters and then runs the function 1000 more times, measuring each run independently and reporting the average runtime at the end. This is a single execution of the system; 20 executions of the system were used as the baseline for a t-test to determine statistical significance as well as visual estimation of normality of data. Since the runs observed about a constant 1-2 μs of noise, I ran all of my numbers on the 10-queens problem to better separate the data (total runtimes ended up being in the range of 200-300μs at this level). When I say that some versions are faster, the p-values for individual measurements are on the order of 10-20—meaning that there is a 1-in-100,000,000,000,000,000,000 chance that the observed speedups could be produced if the programs take the same amount of time to run.

The initial assembly version of the program took about 288μs to run. The first C++ version I coded, originating from the same genesis algorithm that the author of the assembly version used, ran in 275μs. A recursive program beat out a hand-written assembly block of code... and when I manually converted the recursive program into a single loop, the runtime improved to 249μs. It wasn't until I got rid of all of the assembly in the original code that I could get the program to beat the derecursified code (at 244μs)—so it's not the vectorization that's causing the code to be slow. Intrigued, I started to analyze why the original assembly was so slow.

It turns out that there are three main things that I think cause the slow speed of the original code. The first one is alignment of branches: the assembly code contains no instructions to align basic blocks on particular branches, whereas gcc happily emits these for some basic blocks. I mention this first as it is mere conjecture; I never made an attempt to measure the effects for myself. The other two causes are directly measured from observing runtime changes as I slowly replaced the assembly with code. When I replaced the use of push and pop instructions with a global static array, the runtime improved dramatically. This suggests that the alignment of the stack could be to blame (although the stack is still 8-byte aligned when I checked via gdb), which just goes to show you how much alignments really do matter in code.

The final, and by far most dramatic, effect I saw involves the use of three assembly instructions: bsf (find the index of the lowest bit that is set), btc (clear a specific bit index), and shl (left shift). When I replaced the use of these instructions with a more complicated expression int bit = x & -x and x = x - bit, the program's speed improved dramatically. And the rationale for why the speed improved won't be found in latency tables, although those will tell you that bsf is not a 1-cycle operation. Rather, it's in minutiae that's not immediately obvious.

The original program used the fact that bsf sets the zero flag if the input register is 0 as the condition to do the backtracking; the converted code just checked if the value was 0 (using a simple test instruction). The compare and the jump instructions are basically converted into a single instruction in the processor. In contrast, the bsf does not get to do this; combined with the lower latency of the instruction intrinsically, it means that empty loops take a lot longer to do nothing. The use of an 8-bit shift value is also interesting, as there is a rather severe penalty for using 8-bit registers in Intel processors as far as I can see.

Now, this isn't to say that the compiler will always produce the best code by itself. My final code wasn't above using x86 intrinsics for the vector instructions. Replacing the _mm_andnot_si128 intrinsic with an actual and-not on vectors caused gcc to use other, slower instructions instead of the vmovq to move the result out of the SSE registers for reasons I don't particularly want to track down. The use of the _mm_blend_epi16 and _mm_srli_si128 intrinsics can probably be replaced with __builtin_shuffle instead for more portability, but I was under the misapprehension that this was a clang-only intrinsic when I first played with the code so I never bothered to try that, and this code has passed out of my memory long enough that I don't want to try to mess with it now.

In short, compilers know things about optimizing for modern architectures that many general programmers don't. Compilers may have issues with autovectorization, but the existence of vector intrinsics allow you to force compilers to use vectorization while still giving them leeway to make decisions about instruction scheduling or code alignment which are easy to screw up in hand-written assembly. Also, compilers are liable to get better in the future, whereas hand-written assembly code is unlikely to get faster in the future. So only write assembly code if you really know what you're doing and you know you're better than the compiler.

Categorieën: Mozilla-nl planet

Christian Heilmann: For Fox’s sake!

Mozilla planet - do, 03/04/2014 - 18:04

summit-fox

I work at Mozilla. The non-profit organisation to keep the open web, well, open and alive. I work here because of a few reasons:

  • We have a manifesto. Not a “company guideline” or “our vision” or “about us”. We mean business, but not in the sense of “what brings us the most money”.
  • We have people, not employment figures. Amazing people, creative people, misfits and average people. From all over the globe, with all kind of ideas and beliefs and backgrounds. And they work together. They clash, they disagree, they flood my inbox with CCs as I should know the answer to how they can work on this. They all have different setups and ways to work.
  • We empower people. We work with a lot of people who we don’t pay. We help them learn, we help them become speakers for a good cause, we help them communicate and we let them be our communicators in regions and languages and manners we have no idea about. We trust them. And it shows. Going to a Mozilla summit is like going to a concert or festival. You have a lot of fun, you have a lot of noise and boy do you get a lot of demands. People are hungry to do good, and are ravenous to learn all about it.
  • We are a stepping stone. Quite a few people who I trained on public speaking and tech evangelism got better jobs immediately after that. I write more recommendation letters than ever before. And I see people getting a chance to move to another country and get a job they beforehand only dreamed about.
  • We are more than a company in the Silicon Valley. We are world-wide, everybody has the right to work from home and most people do. We trust you to use your time wisely and only ask you to show up for video meetings where we need to sync. This means we release much more than I have ever seen in any other company. Your output speaks for you, not how on time you arrive in the office, how you look or where you are from.
  • We value passion and personality – I can be a total pain in the lower backside. Other people drive me crazy. We don’t have to have the same ideas, instead we find a common ground and analyse what is good for the project as a whole. Then we do that together. There is no problem disagreeing with a director, a manager, or even a CEO. If you have a good point, it will be taken in and – after peer review – taken on. You can get away with a lot more than you could in other companies. And this isn’t about “yeah, let them rant – it makes them happy” – if you are professional and have a good point, you find an ear to listen to you.
  • We disagree and discuss. The old saying “Arguing with an engineer is like wrestling with a pig in mud – you realise far too late it is enjoying it” is very much alive here. All discussions and disagreements are public. Personal disagreements are normally taken on head-on and in direct messaging. Nobody is asked to agree with anything without having had their say. This delays things, this makes things much more complex, but it also makes us who we are. A free, open product can not be created behind closed walls. Open Source does not mean “code is on GitHub”. It is pure transparency and a messy process. But it makes for strong products that can not be killed if one person leaves or gets bored. Open Source means the big red bus has no power. What is shared can not get taken away, neither by organisational changes, nor by outside powers, nor by silly things like hardware failure.
  • We work with the competition. – I have no problem speaking to Google, Microsoft, Opera, Twitter, Facebook and whoever else I please. I speak at their events, I share upcoming work on our part with them. I applaud and publicly promote the great things they do. We work on standards and best practices. These can not be done in one place. They have to have peer review.
  • We allow you to speak freely. – there is no censorship, there is no “you have to use this channel to communicate”. The latter drives me crazy, as I have many a time to react to things people say about our products on their personal blogs or find amazing examples and code randomly on the web. People prefer to write on their own channels about products they built on company time rather than using an official channel. In other companies, that is an HR issue. Hell, I had contracts that said that whatever code written on company hardware belongs to it. Not here. You can talk and you should also be aware of the effects your communication has. Many times this means we have to help you out when you miscommunicated. That is tough, but it also means we learn.

many voices - one mozilla

All of this is the messy craziness that is Mozilla. And that’s why I am here. It is not a 9-5 job, it is not an easy job. But damn is it rewarding and interesting.

When I started, I took a paycut. I continuously get better offers from the outside. I had a six hour interview with six people. These were the best brainstorming I had done for years. When I met volunteers on my way out and saw them giving their time for Mozilla with a smile that was contagious, I knew I am up to something good.

When I interviewed, nobody asked me about my personal or religious beliefs. This would be illegal – at least where I am from. I don’t have to agree with everyone I work with on a personal level. All I have to do is to allow you your freedom to be who you are and flag up when your personal views inconvenience or hurt others and are just not appropriate in a work situation.

So when you tell me because I work for Mozilla I share ideas of other people “above me” in the hierarchy, you don’t know me and you have no idea how Mozilla works. We are different, and we work differently. You make something that thrives on communication and helping another and having thousands of personal voices something you understand: a hierarchical company with one person who is the embodiment of everything the company does. A figure like that exists – it is a one-man startup or a movie superhero. It doesn’t work for a loosely connected and open construct like Mozilla.

I’ve had moments where I was ready to give up. I had some very painful months lately where all my work of the last years was questioned and I felt I ran out of things to excite me. Then I concentrated on the people who give their free time on us and talked to them. And I found the spark again.

I am here for all the people who spend time to keep the web open, to teach web literacy, to give people a voice where it would be hard for them to get heard. They may be my colleagues, they may be volunteers, they may be people in other companies with similar goals. This is bigger than me and bigger than you. I hope it stays, I hope it thrives and I hope people understand that what Mozilla did and does is incredibly important. Information wants to be out and free. The internet allows for this. We made it our passion to protect this internet and give you software that is yours to use – for free, without backdoors or asking you for your information upfront. If that’s not your thing, fine. But don’t give it up because you disagree with one person’s personal actions and beliefs. I don’t.

Categorieën: Mozilla-nl planet

Andrew Sutherland: monitoring gaia travis build status using webmail LED notifiers

Thunderbird - do, 03/04/2014 - 15:58

usb LED webmail notifiers showing build status

For Firefox OS the Gaia UI currently uses Travis CI to run a series of test jobs in parallel for each pull request.  While Travis has a neat ember.js-based live-updating web UI, I usually find myself either staring at my build watching it go nowhere or forgetting about it entirely.  The latter is usually what ends up happening since we have a finite number of builders available, we have tons of developers, each build takes 5 jobs, and some of those jobs can take up to 35 minutes to run when they finally get a turn to run.

I recently noticed ThinkGeek had a bunch of Dream Cheeky USB LED notifiers on sale.  They’re each a USB-controlled tri-color LED in a plastic case that acts as a nice diffuser.  Linux’s “usbled” driver exposes separate red/green/blue files via sysfs that you can echo numbers into to control them.  While the driver and USB protocol inherently support a range of 0-255, it seems like 0-63 or 0-64 is all they give.  The color gamut isn’t amazing but is quite respectable and they are bright enough that they are useful in daylight.  I made a node.js library at https://github.com/asutherland/gaudy-leds that can do some basic tricks and is available on npm as “gaudy-leds”.  You can tell it to do things by doing “gaudy-leds set red green blue purple”, etc.  I added a bunch of commander sub-commands, so “gaudy-leds –help” should give a lot more details than the currently spartan readme.

I couldn’t find any existing tools/libraries to easily watch a Travis CI build and invoke commands like that (though I feel like they must exist) so I wrote https://github.com/asutherland/travis-build-watcher.  While the eventual goal is to not have to manually activate it at all, right now I can point it at a Travis build or a github pull request and it will poll appropriately so it ends up at the latest build and updates the state of the LEDs each time it polls.

Relevant notes / context:

  • There is a storied history of people hooking build/tree status up to LED lights and real traffic lights and stuff like that.  I think if you use Jenkins you’re particularly in luck.  This isn’t anything particularly new or novel, but the webmail notifiers are a great off-the-shelf solution.  The last time I did something like this I used a phidgets LED64 in a rice paper lamp and the soldering was much more annoying than dealing with a mess of USB cables.  Also, it could really only display one status at a time.
  • There are obviously USB port scalability issues, but you can get a 24-port USB hub for ~$40 from Amazon/monoprice/etc.  (They all seem to be made by the same manufacturer.)  I coincidentally bought 24 of the notifiers after my initial success with 6, so I am really prepared for an explosion in test jobs!
  • While I’m currently trying to keep things UNIXy with a bunch of small command-line tools operating together, I think I would like to have some kind of simple message-bus mechanism so that:
    • mozilla-central mach builds can report status as they go
    • webhooks / other async mechanisms can be used to improve efficiency and require less manual triggering/interaction on my end.  So if I re-spin a build from the web UI I won’t need to re-trigger the script locally and such.  Please let me know if you’re aware of existing solutions in this space, I didn’t find much and am planning to just use redis as glue for a bunch of small/independent pieces plus a more daemonish node process for polling / interacting with the web/AMQP.
  • There are efforts underway to overhaul the continuous integration mechanism used for Gaia.  This should address delays in starting tests by being able to throw more resources at them as well as allow notification by whatever Mozilla Pulse’s successor is.
Categorieën: Mozilla-nl planet

Pagina's