4 ms·

> You say "a" test suite as if this was universal truth In my comment I wrote "As an example ..." and I absolutely did not say this is a universal truth. It ap

> You say "a" test suite as if this was universal truth In my comment I wrote "As an example ..." and I absolutely did not say this is a universal truth. It appears like you are able to comprehend basic English, and should be able to read my commentary. You wrote the following in another comment > but feeding this troll is sort of fun Who do you think you are to write stuff like that? Why do you feel like it is OK to make these types of personal attacks on a forum like this?

tharkun__ 4y ago
"As an example ..." and I absolutely did not say this is a universal truth Fair enough that you may have meant it like that. However it can also read as "an example of the M1 being nothing more than a high end office computer" is that "a test suite" (universally) runs slower. The next example might be that say "a C compiler runs slower", "a web server will run slower" etc. As I understand you now, you meant that one of your test suites ran slower. You could have made it more clear by saying exactly that: "As an example, one of our main test suites ran ..." I read it the other way as just an example of test suite, compiler, web server etc. specifically because you then went on to say that it's just a glorified office computer, where it basically doesn't matter that this happens, because it's gonna be good enough to run a browser to look at Facebook ;) Who do you think you are to write stuff like that? This has nothing to do with "who". And also nothing with you. That's between him/her and me. It has to do with the fact that trap_goes_hot completely ignored anything you or I wrote and proceeded to accuse me of criticizing you. Again "criticizing" can be taken in multiple ways: To find fault with To judge the merits and faults of; analyze and evaluate. I think he meant that I was finding fault with in a harsh way. That's not what I was doing. I was analyzing and evaluating and responding to that. I analyzed your sentences and tell you that I read it such that you were saying the test suite thing "as if this was universal truth". That is how I read it and the rest of my reply is to be taken under that premise. He then went on to reply with yet another trolling reply. I simultaneously didn't want to validate it with a reply but I really had to. I bet we could have gone on from one thing to another for another 20 replies and gotten nowhere.
- madsbuch 4y ago
  To be precise: An Elixir test suite written using ExUnit, heavily reliant on a Postgres container. The Postgres container is being emulated. I realise that this might not be due to the architecture or the M1 per se but due to the fact that we are emulating an x86 docker image. Regardless the test suite runs significantly slower, than if my computer would have been x86, which is the experience I am commenting on – a point that I also fleshed out even. However, I love browsing the web, watching movies, writing email, etc. on the computer, at which it excels. ---- I read the troll judgement as being passed towards me, if that was not the case, I apologise. Yes, internet communication can be difficult.
  - tharkun__ 4y ago
    Ah yes. That's why I wrote that your suspicion on why it was slow is probably correct. We had the same thing. Emulated stuff either runs not better, way slower or even crashes and you gotta get a new image/package/compile it for the M1/M2. A database is a prime example of where any minor slowdown due to emulation can be disastrous. A database does lots of things in an optimal way to make it fast. For that it has to make assumptions (or know) how certain things behave, what properties they have. Emulation can screw with that. This is also why running your production database in a VM against virtualized storage (not even thinking docker/k8s etc. here - tho that's also bad in the same way - just plain old running that postgres in production in a VM provided by your vmware esx cluster) is not a good idea. It's just going to be abysmally slow and slow down at exactly the wrong moments even if it "usually" runs "just fine". If your tests rely on that postgres database in any significant way, I am not the least surprised that your test suite slows down like that. My advice would be to replace it with a native image or better yet, write less tests that rely on that postgres database and write the integration tests that aren't reliant on actual postgres behavior against an in-memory database like hsqldb and only have a very thin layer of tests running against an actual postgres, if you still need them at all. Fun exercise: take an ARM version of postgresql and run it under emulation on an x86 computer and see how your test suite behaves ;)
    - madsbuch 4y ago

tharkun__ 4y ago

"As an example ..." and I absolutely did not say this is a universal truth Fair enough that you may have meant it like that. However it can also read as "an example of the M1 being nothing more than a high end office computer" is that "a test suite" (universally) runs slower. The next example might be that say "a C compiler runs slower", "a web server will run slower" etc. As I understand you now, you meant that one of your test suites ran slower. You could have made it more clear by saying exactly that: "As an example, one of our main test suites ran ..." I read it the other way as just an example of test suite, compiler, web server etc. specifically because you then went on to say that it's just a glorified office computer, where it basically doesn't matter that this happens, because it's gonna be good enough to run a browser to look at Facebook ;) Who do you think you are to write stuff like that? This has nothing to do with "who". And also nothing with you. That's between him/her and me. It has to do with the fact that trap_goes_hot completely ignored anything you or I wrote and proceeded to accuse me of criticizing you. Again "criticizing" can be taken in multiple ways: To find fault with To judge the merits and faults of; analyze and evaluate. I think he meant that I was finding fault with in a harsh way. That's not what I was doing. I was analyzing and evaluating and responding to that. I analyzed your sentences and tell you that I read it such that you were saying the test suite thing "as if this was universal truth". That is how I read it and the rest of my reply is to be taken under that premise. He then went on to reply with yet another trolling reply. I simultaneously didn't want to validate it with a reply but I really had to. I bet we could have gone on from one thing to another for another 20 replies and gotten nowhere.

madsbuch 4y ago
To be precise: An Elixir test suite written using ExUnit, heavily reliant on a Postgres container. The Postgres container is being emulated. I realise that this might not be due to the architecture or the M1 per se but due to the fact that we are emulating an x86 docker image. Regardless the test suite runs significantly slower, than if my computer would have been x86, which is the experience I am commenting on – a point that I also fleshed out even. However, I love browsing the web, watching movies, writing email, etc. on the computer, at which it excels. ---- I read the troll judgement as being passed towards me, if that was not the case, I apologise. Yes, internet communication can be difficult.
- tharkun__ 4y ago
  Ah yes. That's why I wrote that your suspicion on why it was slow is probably correct. We had the same thing. Emulated stuff either runs not better, way slower or even crashes and you gotta get a new image/package/compile it for the M1/M2. A database is a prime example of where any minor slowdown due to emulation can be disastrous. A database does lots of things in an optimal way to make it fast. For that it has to make assumptions (or know) how certain things behave, what properties they have. Emulation can screw with that. This is also why running your production database in a VM against virtualized storage (not even thinking docker/k8s etc. here - tho that's also bad in the same way - just plain old running that postgres in production in a VM provided by your vmware esx cluster) is not a good idea. It's just going to be abysmally slow and slow down at exactly the wrong moments even if it "usually" runs "just fine". If your tests rely on that postgres database in any significant way, I am not the least surprised that your test suite slows down like that. My advice would be to replace it with a native image or better yet, write less tests that rely on that postgres database and write the integration tests that aren't reliant on actual postgres behavior against an in-memory database like hsqldb and only have a very thin layer of tests running against an actual postgres, if you still need them at all. Fun exercise: take an ARM version of postgresql and run it under emulation on an x86 computer and see how your test suite behaves ;)
  - madsbuch 4y ago