The Tech Preview Of Servo/Browser.html Is Imminent!

[phoronix]

Phoronix: The Tech Preview Of Servo/Browser.html Is Imminent!

For months there's been talk of a Servo/Browser.html technical preview in June and there's just one week left to the month... It looks like Mozilla is still planning on meeting this milestone!..

http://www.phoronix.com/scan.php?page=news_item&px=Servo-Tech-Preview-Soon

[chuckula]

You know, posting a 404'd link to the URL of the blog post doesn't exactly inspire confidence.

Good news, I was able to actually find the post here: https://blog.servo.org/2016/06/27/twis-69/

[Michael]

You know, posting a 404'd link to the URL of the blog post doesn't exactly inspire confidence.

Good news, I was able to actually find the post here: https://blog.servo.org/2016/06/27/twis-69/

URL has now been fixed, looks like they changed it after the initial posting due to wrong date on it,

[uid313]

I wish there was a browser that could disable advanced JavaScript while retaining basic JavaScript.
So that it is secure and can do simple things like DOM manipulation, but blocks more advanced things like WebGL, WebAudio, WebRtc, WebSockets, WebCrypto, etc.

[M1kkko]

I always find it funny when morons who can't program in C++ think that they will create a new language that will make programming easier so even they can do it. Rust is shit and it's dead on arrival.

In other words, you think C++ is a better language because it's harder to program in it?

[Oppon]

I wish there was a browser that could disable advanced JavaScript while retaining basic JavaScript.
So that it is secure and can do simple things like DOM manipulation, but blocks more advanced things like WebGL, WebAudio, WebRtc, WebSockets, WebCrypto, etc.

i.e. Firefox with certain changes in about:config and a few extensions?

[jrch2k8]

In other words, you think C++ is a better language because it's harder to program in it?

Nope, actually is harder because it is better and C is harder than C++ because it is even better and so on.

To elaborate a bit, lower level languages are exponentially closer to what the actual hardware speak, hence they become less intuitive because they are farther away from how our brain process information. this is also the reason is very hard to even close in performance to ASM/C/C++ when you go up in the chain.

Because of this there is no perfect language, you either compromise for performance make it in harder or compromise performance to make it easier.

One of the strongest/weakest point in C/C++ is the very flexible way you are allowed to handle memory and polymorphism, when properly used you are able to skyrocket performance/scalability or completely destroy it/tank it at the same time because it all depends on the hardware, with higher level languages you get a middle point(at best) because the runtime is the one trying to translate what you meant into hardware efficiently but it cannot go as deep as you can.

Some simplistic example to illustrate my point, let's say you have 3 systems

1.) ARM based many cores system(let's say 256 cores to have some reference)
2.) Wow much FPS very OC core i7-6700(you dev machine)
3.) 4 socket 44 core xeon e5/7

and you wish to multiplicate very big Integer matrix like data as fast as possible(let's say it comes from an usb 3.1 port to keep it simplistic), even real time if doable(kinda common in industrial fields).

C#/vala/rust/whatever(i'll continue with C# but means any high level language, i'm a lazy typer) would be very simple(let's assume for now good code without 3rd party tools) maybe let's say 1.5k LoCs, and add maybe 0.5k more for a cool GUI , this is very likely what you will get after running it.(based on my experience)

1.) arm is reasonable bang for a buck and take few mins but only 70% of the cores are used
2.) completely freaking kill the arm server(you probably think this is right because is an i7 lol, ARM is for Phones )
3.) mmm is barely faster than the i7(here you start scratching your head, since it is the same platform as your i7 but with lots of cores, so WTH??)

in C++, this could easily take 5k+ LoC and probably you will let someone else write the GUI but you get something like this(let's say standard flags, -02, native whatever)

1.) is 3x faster than C#
2.) is actually slower than the ARM system but 30% faster than C# code
3.) is 10x faster than C# and actually way faster than the i7

some C++ guru team comes to help, after a couple of weeks and 15k+ LoC later, you get this.(the flags look like a rap song at this point)

1.) is 15x faster than the previous C++ code and thrash the I7 to hell
2.) is around 2x faster than previous C++ code
3.) is 20x faster than the previous C++ code and thrash the I7 to hell and blow the arm by 50%

Why? WTH? dafuq???

simple in the second example the compiler have a lot more time to do optimization passes than a runtime solution is allowed to have, so it produces better code, plus compilers have lot more time fixing those problems and have the advantage on raw experience.

In the third example the gurus made a library(or inside the executable or whatever) that replaces the standard by default new(as new var) memory allocator for a compile time allocator specific to the platform.

simply put,
1.) in this case you have small per core non coherent caches and bigger but slow per socket cache and even slower but kinda massive per node cache, medium IPC and fast memory access to core mapped RAM but ultra slow to non core locale RAM, so the gurus bypassed the default scheduler and created a virtual linear ram emulated page system that pre allocates X MB chunks at once and each core in the node receive and equal to cache size chunks per core making sure every thread have assigned a physical core for SIMD operations(let's say latest NEON), etc, etc, etc.

2.) the I7 have a big coherent preemptive multi level cache and is very fast mapping linear memory chunks but more importantly every core have fast access to the memory and strong SIMD/IPC, so some simple SIMD/multithreading scheduling fine tune helps a lot to reach near perfect theoretical performance but is slower as hardware than 1 and 3

3.) This system have all the advantages of the I7 but the non locale numa mapping introduces massive latency/cache trashing, so an adaptation here to schedule memory mapping per node locality (or socket if you prefer) as a virtual linear mapping is a real performance booster and the xeon can truly shows its IPC muscle

Sorry for the long post, but that is some general idea example for memory, ofc there are other 3 bazillion optimizations you could do, there are books for that and i'm to lazy to keep writing this

[liam]

I've been keeping up with this project, but haven't had a lot of luck actually browsing with the results.
Typically it's very slow to show pages (not sure what part of process is actually slow), and, more often that not, there are serious issues with layout.
I've not rebuilt servo for a week, or so, and I'm doing so now, so...I hope it's in better shape than it has been.

[liam]

Nope, actually is harder because it is better and C is harder than C++ because it is even better and so on.

To elaborate a bit, lower level languages are exponentially closer to what the actual hardware speak, hence they become less intuitive because they are farther away from how our brain process information. this is also the reason is very hard to even close in performance to ASM/C/C++ when you go up in the chain.

Because of this there is no perfect language, you either compromise for performance make it in harder or compromise performance to make it easier.

One of the strongest/weakest point in C/C++ is the very flexible way you are allowed to handle memory and polymorphism, when properly used you are able to skyrocket performance/scalability or completely destroy it/tank it at the same time because it all depends on the hardware, with higher level languages you get a middle point(at best) because the runtime is the one trying to translate what you meant into hardware efficiently but it cannot go as deep as you can.

Some simplistic example to illustrate my point, let's say you have 3 systems

1.) ARM based many cores system(let's say 256 cores to have some reference)
2.) Wow much FPS very OC core i7-6700(you dev machine)
3.) 4 socket 44 core xeon e5/7

and you wish to multiplicate very big Integer matrix like data as fast as possible(let's say it comes from an usb 3.1 port to keep it simplistic), even real time if doable(kinda common in industrial fields).

C#/vala/rust/whatever(i'll continue with C# but means any high level language, i'm a lazy typer) would be very simple(let's assume for now good code without 3rd party tools) maybe let's say 1.5k LoCs, and add maybe 0.5k more for a cool GUI , this is very likely what you will get after running it.(based on my experience)

1.) arm is reasonable bang for a buck and take few mins but only 70% of the cores are used
2.) completely freaking kill the arm server(you probably think this is right because is an i7 lol, ARM is for Phones )
3.) mmm is barely faster than the i7(here you start scratching your head, since it is the same platform as your i7 but with lots of cores, so WTH??)

in C++, this could easily take 5k+ LoC and probably you will let someone else write the GUI but you get something like this(let's say standard flags, -02, native whatever)

1.) is 3x faster than C#
2.) is actually slower than the ARM system but 30% faster than C# code
3.) is 10x faster than C# and actually way faster than the i7

some C++ guru team comes to help, after a couple of weeks and 15k+ LoC later, you get this.(the flags look like a rap song at this point)

1.) is 15x faster than the previous C++ code and thrash the I7 to hell
2.) is around 2x faster than previous C++ code
3.) is 20x faster than the previous C++ code and thrash the I7 to hell and blow the arm by 50%

Why? WTH? dafuq???

simple in the second example the compiler have a lot more time to do optimization passes than a runtime solution is allowed to have, so it produces better code, plus compilers have lot more time fixing those problems and have the advantage on raw experience.

In the third example the gurus made a library(or inside the executable or whatever) that replaces the standard by default new(as new var) memory allocator for a compile time allocator specific to the platform.

simply put,
1.) in this case you have small per core non coherent caches and bigger but slow per socket cache and even slower but kinda massive per node cache, medium IPC and fast memory access to core mapped RAM but ultra slow to non core locale RAM, so the gurus bypassed the default scheduler and created a virtual linear ram emulated page system that pre allocates X MB chunks at once and each core in the node receive and equal to cache size chunks per core making sure every thread have assigned a physical core for SIMD operations(let's say latest NEON), etc, etc, etc.

2.) the I7 have a big coherent preemptive multi level cache and is very fast mapping linear memory chunks but more importantly every core have fast access to the memory and strong SIMD/IPC, so some simple SIMD/multithreading scheduling fine tune helps a lot to reach near perfect theoretical performance but is slower as hardware than 1 and 3

3.) This system have all the advantages of the I7 but the non locale numa mapping introduces massive latency/cache trashing, so an adaptation here to schedule memory mapping per node locality (or socket if you prefer) as a virtual linear mapping is a real performance booster and the xeon can truly shows its IPC muscle

Sorry for the long post, but that is some general idea example for memory, ofc there are other 3 bazillion optimizations you could do, there are books for that and i'm to lazy to keep writing this

I wouldn't call rust "high-level".
You CAN write rust to be as fast as C++ (lots of unsafe bailouts), but, at that point, you'd be writing code that was nearly as problematic as C++.

[jrch2k8]

I wouldn't call rust "high-level".
You CAN write rust to be as fast as C++ (lots of unsafe bailouts), but, at that point, you'd be writing code that was nearly as problematic as C++.

true you are right, i'm no rust expert but from what i've seen is more akin to D than to full C++, so it's a bit higher level(i can be wrong TM), but yeah i guess the point is every language fill a need in a very complex and dynamic market, so developers should find the right tools for the job in question, in fact no one says you cannot use several languages in a project as long as they are used properly