Posted by
timothy
on from the count-to-ten-very-slowly dept.
An anonymous reader writes "TCCBOOT is the first boot loader able to compile and boot a Linux kernel directly from its source code. It can compile and start booting a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4. TCCBOOT uses the latest version of the TinyCC C compiler."
Why would anyone *possibly* want their bootloader be able to compile the kernel?
Re:usefulness?
by
Walkiry
·
· Score: 4, Interesting
Two words: ATI drivers. These fuckers have to be compiled in the kernel, and I don't doubt there may be some other dumbasses who make similar drivers for other stuff. If the kernel just compiles like that (as in, is designed to just compile on boot), it'd make messing with the drivers less painful.
Do you know what this means?!
by
AKAImBatman
·
· Score: 5, Interesting
This could allow for platform independent Linux programs! i.e. If programs could be compiled on the fly from source bundles as an acceptable speed, then there would be no need to distribute binaries any longer. One source bundle, and you'll rule them all!
Failing that, one could always fall back on my previous plan. My thought was that if GCC compiled to P-Code instead of the final binary, the target GCC could complete the P-Code conversion at install time.
Load the needed environment for the compiler. Load the source Build the source Boot the source
in 15 seconds, when it takes much longer than that for my already booted system to build a kernel? A P4 isn't THAT much faster than an AMD3200! (And I have done the old "drop to RL1 and build" trick, so it is not an issue of other tasks running).
I want to know a) What kernel options are enabled b) From when are they starting the clock (are they counting the time to load the bootloader and initrd?) and c) is this TRULY a fully functional kernel, or "just enough to get a prompt"?
Well, I'm no kernel hacker, but I guess this could help speed up the debug cycle for the kernel in some instances.
It could also be a trap (it runs well compiled with tcc but fails misteriously when compiled and optimized with gcc).
TCC is a very fast C compiler and it is very nice for development (I used it as a backend to the SmartEiffel Eiffel compiler, it greatly speeds up compiling - waiting for GCC every time was a nuissance) and I guess Fabrice Bellard likes to experiment.
I guess nobody (including Bellard) believes TCC is any good for delivered apps (it doesn't optimize etc.) but it can provide a huge boost to edit-compile-debug cycles.
So yes, TCC is very cool, but not useful for the general public.
Wow. That really is fast.
by
TheRaven64
·
· Score: 5, Interesting
Out of sheer boredom, I just downloaded the demo ISO and ran it inside VirtualPC on a 1.5GHz G4. The emulated system is probably roughly equal to a P2 300. The total time from turning the emulated machine on to a shell was around a minute.
Re:Wow. That really is fast.
by
TheRaven64
·
· Score: 4, Interesting
I just ran the same thing again (exactly the same configuration), with a stopwatch. 46 seconds. 15 seconds on a P4 sounds like they were being a bit pessimistic. Note that this doesn't include launching any daemons, or a
sh-2.05b# ps -x PID TTY STAT TIME COMMAND 1 ? S 0:01/bin/sh/sbin/init auto 2 ? SW 0:00 [keventd] 3 ? SW 0:00 [bdflush] 4 ? SW 0:00 [kupdated] 5 ? SWN 0:00 [ksoftirqd_CPU0] 6 ? SW 0:00 [kswapd] 15 ? S 0:00/bin/sh 17 ? R 0:00 ps -x
Re:I call shenanigans on this
by
Godeke
·
· Score: 3, Interesting
Looking at benchmarks for TCC, combined with the fact this needs kernel patches to work, I don't see this as shenanigans.
15,000 - 16,000 lines per second for GCC vs 134,000 lines per second is a pretty huge speed improvement.
On the other hand, if "make clean" takes longer than 15 seconds on your machine, I have to wonder what you are doing. I'm typing this on a lowly 550 Mhz Pentium with 512 MB of RAM (running a full KDE install) and I can assure you I would be unhappy if running "clean" took that long.
-- Sig under construction since 1998.
Re:Too fast...
by
stratjakt
·
· Score: 3, Interesting
I reboot my machines all the time, because it's easier than ssh'ing in, and figuring out what the problem is.
One is mainly an LDAP server/PDC, and for some reason OpenLDAP just dies once in awhile. Has something to do with BDB settings, I'm supposed to know some magical cache size setting or something to make it stable. I have no time for that. It boots from a RO image, which I rarely need to update.
Same for the firewall/gateway. It's just much easier to tell people "if the internet or vpn isnt working, reset this box and wait a minute".
Linux can have really really long uptimes, but only if you have an admin who can babysit it and solve problems without rebooting.
I'm not an admin, and I don't have time to figure out why "dhcpcd" or "dnsmasq" decided they dont need to spawn anymore. While such problems could probably be easily fixed by deleting some lockfile or clearing some log, rebooting is just easier.
Linux needs to be able to boot fast to move forward, especially in the world of "embedded" or single-function PCs.
--
I don't need no instructions to know how to rock!!!!
Re:Main reason for this?
by
kbahey
·
· Score: 4, Interesting
You are generally right.
But think about it for a bit: this fast C compiler turns the tables, and redefines what we know (paradigm shift anyone?). No longer will C be seen as a compiled language. One can think of it as a scripting language. A construct like this works with tcc:
Just look at this guy's work.. It's amazing what this he can do. If you haven't tried it yet, definately check out QEMU, it's great, and totally free. He also wrote FFMPEG which most definately your linux media player uses..
real 0m0.060s user 0m0.020s sys 0m0.010s cedric@cedric:~$ time gcc fibo.c -O3 -o fibo.gcc
real 0m0.441s user 0m0.150s sys 0m0.030s cedric@cedric:~$ time./fibo.gcc 1
real 0m0.074s user 0m0.000s sys 0m0.000s cedric@cedric:~$ time./fibo.tcc 1
real 0m0.072s user 0m0.000s sys 0m0.000s cedric@cedric:~$ time./fibo.gcc 1
real 0m0.071s user 0m0.000s sys 0m0.000s cedric@cedric:~$ time./fibo.tcc 1
real 0m0.074s user 0m0.000s sys 0m0.000s cedric@cedric:~$ time./fibo.gcc 1
real 0m0.071s user 0m0.000s sys 0m0.010s cedric@cedric:~$ time./fibo.tcc 1
real 0m0.070s user 0m0.000s sys 0m0.000s
I can't believe this is what GCLS uses as a benchmark. The running time is so short it's probably all start-up and shutdown. Anyway, the numbers are pretty fair for a compiler compiling code that was tweaked to get the other compiler to be as fast as possible.
Slashdot Mirror
Why would anyone *possibly* want their bootloader be able to compile the kernel?
This could allow for platform independent Linux programs! i.e. If programs could be compiled on the fly from source bundles as an acceptable speed, then there would be no need to distribute binaries any longer. One source bundle, and you'll rule them all!
Failing that, one could always fall back on my previous plan. My thought was that if GCC compiled to P-Code instead of the final binary, the target GCC could complete the P-Code conversion at install time.
Javascript + Nintendo DSi = DSiCade
How can this thing:
Load the needed environment for the compiler.
Load the source
Build the source
Boot the source
in 15 seconds, when it takes much longer than that for my already booted system to build a kernel? A P4 isn't THAT much faster than an AMD3200! (And I have done the old "drop to RL1 and build" trick, so it is not an issue of other tasks running).
I want to know a) What kernel options are enabled b) From when are they starting the clock (are they counting the time to load the bootloader and initrd?) and c) is this TRULY a fully functional kernel, or "just enough to get a prompt"?
www.eFax.com are spammers
Well, I'm no kernel hacker, but I guess this could help speed up the debug cycle for the kernel in some instances.
It could also be a trap (it runs well compiled with tcc but fails misteriously when compiled and optimized with gcc).
TCC is a very fast C compiler and it is very nice for development (I used it as a backend to the SmartEiffel Eiffel compiler, it greatly speeds up compiling - waiting for GCC every time was a nuissance) and I guess Fabrice Bellard likes to experiment.
I guess nobody (including Bellard) believes TCC is any good for delivered apps (it doesn't optimize etc.) but it can provide a huge boost to edit-compile-debug cycles.
So yes, TCC is very cool, but not useful for the general public.
Out of sheer boredom, I just downloaded the demo ISO and ran it inside VirtualPC on a 1.5GHz G4. The emulated system is probably roughly equal to a P2 300. The total time from turning the emulated machine on to a shell was around a minute.
I am TheRaven on Soylent News
I am TheRaven on Soylent News
Looking at benchmarks for TCC, combined with the fact this needs kernel patches to work, I don't see this as shenanigans.
15,000 - 16,000 lines per second for GCC vs 134,000 lines per second is a pretty huge speed improvement.
On the other hand, if "make clean" takes longer than 15 seconds on your machine, I have to wonder what you are doing. I'm typing this on a lowly 550 Mhz Pentium with 512 MB of RAM (running a full KDE install) and I can assure you I would be unhappy if running "clean" took that long.
Sig under construction since 1998.
I reboot my machines all the time, because it's easier than ssh'ing in, and figuring out what the problem is.
One is mainly an LDAP server/PDC, and for some reason OpenLDAP just dies once in awhile. Has something to do with BDB settings, I'm supposed to know some magical cache size setting or something to make it stable. I have no time for that. It boots from a RO image, which I rarely need to update.
Same for the firewall/gateway. It's just much easier to tell people "if the internet or vpn isnt working, reset this box and wait a minute".
Linux can have really really long uptimes, but only if you have an admin who can babysit it and solve problems without rebooting.
I'm not an admin, and I don't have time to figure out why "dhcpcd" or "dnsmasq" decided they dont need to spawn anymore. While such problems could probably be easily fixed by deleting some lockfile or clearing some log, rebooting is just easier.
Linux needs to be able to boot fast to move forward, especially in the world of "embedded" or single-function PCs.
I don't need no instructions to know how to rock!!!!
You are generally right.
But think about it for a bit: this fast C compiler turns the tables, and redefines what we know (paradigm shift anyone?). No longer will C be seen as a compiled language. One can think of it as a scripting language. A construct like this works with tcc:
Something that was unthinkable under GCC.
As someone else posted, this can mean the proliferation of self contained bundles that are platform independant.
The potential is enormous. Not the boot part, but the compiler and what it can be twisted into doing.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
http://fabrice.bellard.free.fr/
:)
Just look at this guy's work.. It's amazing what this he can do.
If you haven't tried it yet, definately check out QEMU, it's great, and totally free.
He also wrote FFMPEG which most definately your linux media player uses..
I am always wondering what he'll put out next
fibo.c from GCLS:
./fibo.gcc
./fibo.tcc
./fibo.gcc
./fibo.tcc
./fibo.gcc
./fibo.tcc
cedric@cedric:~$ time tcc fibo.c -o fibo.tcc
real 0m0.060s
user 0m0.020s
sys 0m0.010s
cedric@cedric:~$ time gcc fibo.c -O3 -o fibo.gcc
real 0m0.441s
user 0m0.150s
sys 0m0.030s
cedric@cedric:~$ time
1
real 0m0.074s
user 0m0.000s
sys 0m0.000s
cedric@cedric:~$ time
1
real 0m0.072s
user 0m0.000s
sys 0m0.000s
cedric@cedric:~$ time
1
real 0m0.071s
user 0m0.000s
sys 0m0.000s
cedric@cedric:~$ time
1
real 0m0.074s
user 0m0.000s
sys 0m0.000s
cedric@cedric:~$ time
1
real 0m0.071s
user 0m0.000s
sys 0m0.010s
cedric@cedric:~$ time
1
real 0m0.070s
user 0m0.000s
sys 0m0.000s
I can't believe this is what GCLS uses as a benchmark. The running time is so short it's probably all start-up and shutdown. Anyway, the numbers are pretty fair for a compiler compiling code that was tweaked to get the other compiler to be as fast as possible.